GCC build failed for powerpc-eabisim with your patch on 2002-06-13T18:40:10Z.

[law@redhat.com]

In message <Pine.LNX.4.33.0206141507310.26780-100000@www.eyesopen.com>, Roger S
ayle writes:
 > On Fri, 14 Jun 2002 law@redhat.com wrote:
 > 
 > >  > There were also 9 new regression test failures, and 15
 > >  > failures that existed before and after that patch; 0 failures
 > >  > have been fixed.
 > >  >
 > >  > The new failures are:
 > >  > mips-elf g++.sum g++.other/reload1.C
 > >  > mips-elf gcc.sum gcc.c-torture/compile/20020106-1.c,
 > >  > mips-elf gcc.sum gcc.c-torture/compile/950612-1.c,
 > >  > mips-elf gcc.sum gcc.c-torture/execute/20011126-1.c
 > >  > mips-elf gcc.sum gcc.c-torture/execute/20020506-1.c
 > >  > mips-elf gcc.sum gcc.c-torture/execute/950607-2.c
 > >  > mips-elf gcc.sum gcc.c-torture/execute/950704-1.c
 > >  > mips-elf gcc.sum gcc.c-torture/execute/tstdi-1.c
 > >  > mips-elf gcc.sum gcc.c-torture/unsorted/cc.c,
 > > Wow.  At least some of these are due to Roger's change, not my shared
 > > RTL changes.
 > >
 > > For at least the 950612, the code appears to still be valid, but it trips
 > > an assembler warning.  I'm in the process of verifying whether or not the
 > > other regressions are of a similar nature.
 > 
 > I'll try building a mips-elf simulator and bootstraping an IRIX 6.5
 > system to see if I can figure out whats going on.  This is a bit
 > odd though, my 2002-06-13 cleanups shouldn't have affected any
 > behaviour (unless the MIPS backend explicitly disables if-conversion,
 > or cleanup_cfg isn't idempotent, i.e. running it more than once has
 > an observable effect on MIPS).
The "trick" is that the code now cleans up the CFG even if we're not
optimizing.

Optimizing the CFG inverts a conditional branch (which allows it to eliminate
a jump).

The conditional branch has a value that is trivially computed at compile time,
but because we're not optimizing we don't eliminate it.

Worse yet, when you emit the branch as it was rewritten by the CFG optimization
code, the assembler realizes the branch is a compile-time constant.  And lamely
the assembler decides to warn you that you just emitted a branch that is
either always taken or always not taken (I don't recall which).

Fixing this may be as simple as making the call to cleanup_cfg be conditional
on optimization being enabled.  Of course, someone should fix the lame-o
assembler from issuing this kind of silly warning.

Anyway, in the mean time I'm verifying that this problem is indeed what is
causing the various MIPS failures from the regression tester.


jeff