Bad and/or stupid code for DImode compares with gcc 4.6.1

[Alan Lehotsky <alehotsky at me dot com>]

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...)