Hi,
On Tue, Aug 2, 2011 at 6:32 PM, Richard Henderson r...@redhat.com wrote:
I got Jeff Law to review the reload change on IRC
and committed the composite patch.
Tested on x86_64, i586, avr, and h8300. Most other
tier1 targets ought not be affected, as this patch
only applies to
I have no problems with binutils in CVS today. That
may be another --with-as/--with-ld issue similar to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
No, this was a pilot error on my side. Now I have HAVE_GAS_CFI_DIRECTIVE to 1
but the bootstrap still fails if --disable-initfini-array
On Sat, Sep 10, 2011 at 4:01 AM, Eric Botcazou ebotca...@adacore.com wrote:
I have no problems with binutils in CVS today. That
may be another --with-as/--with-ld issue similar to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
No, this was a pilot error on my side. Now I have
On Sat, 10 Sep 2011, H.J. Lu wrote:
Our assembler supports CFI, but objdump may be too old to dump
DW_CFA_advance_loc and this feature is mis-detected.
Should this be autoconf-ed, then? As a test for objdump?
(FWIW my bootstrap comparison failure, cf. http://gcc.gnu.org/PR50010 ,
also seems
Which version of binutils are you using, Eric?
Binutils CVS from this morning:
Target: i586-suse-linux
Configured
with: /home/eric/svn/gcc/configure --build=i586-suse-linux
--prefix=/home/eric/install/gcc
--with-as=/home/eric/build/binutils/native32/gas/as-new
Binutils CVS from this morning:
OK, I see. For some reasons, this build has:
#define HAVE_GAS_CFI_DIRECTIVE 0
and another build with binutils 2.20 succeeds, but it has:
#define HAVE_GAS_CFI_DIRECTIVE 1
So bootstrap is broken without CFI directives.
--
Eric Botcazou
On Fri, Sep 9, 2011 at 11:15 AM, Eric Botcazou ebotca...@adacore.com wrote:
Binutils CVS from this morning:
OK, I see. For some reasons, this build has:
#define HAVE_GAS_CFI_DIRECTIVE 0
and another build with binutils 2.20 succeeds, but it has:
#define HAVE_GAS_CFI_DIRECTIVE 1
I have
On Wed, 24 Aug 2011, Eric Botcazou wrote:
I've been trying for 2 days to replicate this with various
configurations and none have failed.
I configure for i586 with --enable-checking=yes,rtl. And I also have a
comparison failure on x86-64 with the same configure options:
Which version of
I've been trying for 2 days to replicate this with various
configurations and none have failed.
I configure for i586 with --enable-checking=yes,rtl. And I also have a
comparison failure on x86-64 with the same configure options:
Bootstrap comparison failure!
libcpp/lex.o differs
--
Eric
On 08/23/2011 03:42 PM, Gerald Pfeifer wrote:
On Tue, 23 Aug 2011, Richard Henderson wrote:
I've been trying for 2 days to replicate this with various
configurations and none have failed.
Thanks for investigating, and sorry that this proves a worthy opponent!
On my testers, the system
Hmm, does a copy of my build tree (including logs in nohup.out) help?
I put up one at http://people.freebsd.org/~gerald/objtree.tar.xz .
Gerald
On Tue, Aug 23, 2011 at 6:07 PM, Gerald Pfeifer ger...@pfeifer.com wrote:
Hmm, does a copy of my build tree (including logs in nohup.out) help?
I put up one at http://people.freebsd.org/~gerald/objtree.tar.xz .
I couldn't reproduce the bootstrap failure n Linux/ia32 either. Have
you tried
I'm afraid this patch casues i386 bootstraps to fail:
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
libiberty/pic/cplus-dem.o differs
I'm afraid this patch casues i386 bootstraps to fail:
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
libiberty/pic/cplus-dem.o differs
libiberty/pic/crc32.o
Richard Henderson wrote:
On 08/01/2011 11:42 AM, Georg-Johann Lay wrote:
Is there a specific reason not to define
ACCUMULATE_OUTGOING_ARGS on AVR?
Yes. So that you can use PUSH. But as I said in PR49881,
you probably want to provide -maccumulate-outgoing-args.
I have a follow-up patch
Richard Henderson wrote:
emit_stack_restore (SAVE_BLOCK, old_stack_level);
stack_pointer_delta = old_stack_pointer_delta;
+
+ /* ??? Is this assert warrented, given emit_stack_restore?
+ or should we just mark the last insn no matter what? */
+ last =
Georg-Johann Lay wrote:
Richard Henderson wrote:
On 08/01/2011 11:42 AM, Georg-Johann Lay wrote:
Is there a specific reason not to define
ACCUMULATE_OUTGOING_ARGS on AVR?
Yes. So that you can use PUSH. But as I said in PR49881,
you probably want to provide -maccumulate-outgoing-args.
I
On Tue, Aug 2, 2011 at 3:32 PM, Richard Henderson r...@redhat.com wrote:
I got Jeff Law to review the reload change on IRC
and committed the composite patch.
Tested on x86_64, i586, avr, and h8300. Most other
tier1 targets ought not be affected, as this patch
only applies to
On 08/03/2011 07:07 AM, Georg-Johann Lay wrote:
#include stdio.h
void foo ()
{
printf (%d %d %d, 1, 2, 3);
printf (%d %d %d, 3, 4, 5);
printf (%d %d %d, 1, 4, 5);
}
Attached the output: The compiler happily pushes onto the stack
but pops only at the end of the function. So
On 08/03/2011 08:47 AM, Georg-Johann Lay wrote:
With ACCUMULATE_OUTGOING_ARGS it looks much better: there is just
one such block in the prologue/epilogue.
I think ACCUMULATE_OUTGOING_ARGS would be a win definitely.
That's what I thought too, but with the test case in PR49881
I couldn't make
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/03/11 08:07, Georg-Johann Lay wrote:
Georg-Johann Lay wrote:
Richard Henderson wrote:
On 08/01/2011 11:42 AM, Georg-Johann Lay wrote:
Is there a specific reason not to define
ACCUMULATE_OUTGOING_ARGS on AVR?
Yes. So that you can use
I got Jeff Law to review the reload change on IRC
and committed the composite patch.
Tested on x86_64, i586, avr, and h8300. Most other
tier1 targets ought not be affected, as this patch
only applies to ACCUMULATE_OUTGOING_ARGS == 0 targets.
r~
Richard Henderson schrieb:
This is related primarily to PR49864 but also to PR49879.
The fundamental problem in the first test case is that the
AVR target cannot perform
(set (stack-pointer-rtx)
(plus (stack-pointer-rtx) (const_int large)))
where large is in fact really quite
On 08/01/2011 11:42 AM, Georg-Johann Lay wrote:
Is there a specific reason not to define
ACCUMULATE_OUTGOING_ARGS on AVR?
Yes. So that you can use PUSH. But as I said in PR49881,
you probably want to provide -maccumulate-outgoing-args.
I have a follow-up patch to the last one in that PR...
2011/8/1 Richard Henderson r...@redhat.com:
On 08/01/2011 11:42 AM, Georg-Johann Lay wrote:
Is there a specific reason not to define
ACCUMULATE_OUTGOING_ARGS on AVR?
I havn't define ACCUMULATE_OUTGOING_ARGS because AVR have a very small
displacement for memory addressing (63 bytes) and I think
Testing on h8300, newlib/libm/math/ef_j0.c revealed a crash.
The problem is that PREV turned out to be unlinked when we came to
fixup_args_size_notes (prev, PREV_INSN (next),
INTVAL (XEXP (p, 0)));
I'm not sure how this didn't
26 matches
Mail list logo
