Hi,
On Tue, Aug 2, 2011 at 6:32 PM, Richard Henderson 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 ACCUMULATE_OUTGOING_
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
On Sat, Sep 10, 2011 at 4:01 AM, Eric Botcazou 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 HAVE_GAS_CFI_DIRECTIVE
> 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-arr
On Fri, Sep 9, 2011 at 11:15 AM, Eric Botcazou 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 no problems
> 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
> 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
--with-ld=/home/eric/build/bin
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
> 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 B
On Tue, Aug 23, 2011 at 6:07 PM, Gerald Pfeifer 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 the latest
binuti
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 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
On 08/21/2011 02:51 PM, Eric Botcazou wrote:
>> 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!
> 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
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 diff
On Wed, Aug 3, 2011 at 7:31 AM, H.J. Lu wrote:
> On Tue, Aug 2, 2011 at 3:32 PM, Richard Henderson 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
Richard Henderson wrote on 08/03/2011 04:15:26 PM:
> On 08/03/2011 07:07 AM, Ulrich Weigand wrote:
> > Was this assert intended to impose requirements on target's
> > restore_stack_block implemtations? What exactly are those
> > supposed to be?
>
> The assert was not intended to impose requiremen
-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
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 ma
Richard Henderson wrote:
> On 08/03/2011 07:07 AM, Georg-Johann Lay wrote:
>> #include
>>
>> 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
>>
On 08/03/2011 07:07 AM, Ulrich Weigand wrote:
> Was this assert intended to impose requirements on target's
> restore_stack_block implemtations? What exactly are those
> supposed to be?
The assert was not intended to impose requirements, but to figure
out if I needed to do anything special here.
On 08/03/2011 07:07 AM, Georg-Johann Lay wrote:
> #include
>
> 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 fun
On Tue, Aug 2, 2011 at 3:32 PM, Richard Henderson 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 ACCUMULATE_OUTGOING_ARGS
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
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? */
> + las
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-
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~
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 previousl
2011/8/1 Richard Henderson :
> 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 that bette
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...
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 smal
31 matches
Mail list logo
