I'm looking at code generated for a new port of gcc using 4.6.1 and failing
execute/950607-2.c with -O0 only
The target chip has only 32 bit instructions, so it's using
do_jump_by_parts_<relop>_rtx() to expand the compare.
I've set up my .md to use the CCmode.
I see one case that seems really stupid, and one that's just wrong. I'm
thinking that either I have something really flawed with my port's handing of
DImode or that there was a bug in 4.6.1. The port is only failing about 2100
dejagnu tests (passing 64000+) and a good chunk of the failures are due to the
ridiculously small data-memory size of the chip.
For
long long int x;
if ( x < 0 ) return 0 else return 2;
I see code that compares MSBs and branches on < (less than) as expected. But
then it goes and checks the MSBs for != , and finally it checks the LSBS and
emits a conditional branch to the ELSE, followed by an unconditional branch to
the ELSE, so that I end up with code that looks like
mov $r1,x
mov $r2,x+4
cmpi $r2,0
jlt .L5
cmpi $r2,0 <=== totally redundant for "x < 0" comparisons
jne .L2
cmpi $r1,0
jmp .L4
.L5 : movi $r1, 0
jump .L4
.L2 : movi $r1, 2
.L4:
ret
This is a simplification of 950607-2.c, which fails at -O0, but passes at
higher optimization levels (go figure...)
