Re: gcc 2.95.3/ARM problems comparing with negative

[Toralf Lund <toralf at procaptura dot com>]

Richard Earnshaw wrote:

> On Mon, 2004-11-01 at 09:52, Toralf Lund wrote:
>  
>
> > I'm having a rather strange problem with an ARM code built with gcc 
> > 2.95.3. Maybe I'm missing something obvious, but it looks like the wrong 
> > branch is taken after a comparison with a negative constant.
> >
> > I have the following test
> >
> >    if(position<-ZSTP_MAX_POS)
> >
> >
> > where ZSTP_MAX_POS is #defined as 250000, and "position" is an argument 
> > to the function containing the test. The problem is simply that if I 
> > pass e.g. 1 for the position argument, the test evaluates to "true" - 
> > according to the debugger, anyway - but surely 1 is not smaller than 
> > -250000? Also, the following code is generated for the test:
> >
> > 8013458:    e51b3014     ldr    r3, [fp, -#20]
> > 801345c:    e3e02a3d     mvn    r2, #249856    ; 0x3d000
> > 8013460:    e2422090     sub    r2, r2, #144    ; 0x90
> > 8013464:    e1530002     cmp    r3, r2
> > 8013468:    8a000017     bhi    80134cc <_SetZoomPos+0xc4>
> >
> > This is followed by the "test true" code, i.e. as far as I can tell, the 
> > branch is supposed to be taken when the test is not true. But will it? I 
> > would expect "bgt" instead of "bhi" for the branch instruction, I think.
> >
> > All this with gcc 2.95.3. Maybe I could upgrade, but it seems to me that 
> > newer versions will actually generate less efficient code...
> >    
>
> bhi is a branch used for an unsigned comparison.
My point exactly...

>  So I suspect your
> problem is the type of one of your arguments, most likely the
> declaration of position itself.
>  
No, position is all right. But now that you mention it, ZSTP_MAX_POS is 
actually set up via an indirect definition involving "sizeof", following 
a recent update. I guess that makes ZSTP_MAX_POS an unsigned, and if I 
use an "int" typecast, I do get the correct code. I still don't quite 
get it, though. Shouldn't -ZSTP_MAX_POS implicitly be treated as a 
signed in any case? I would at least expect either fully signed or fully 
unsigned operation; the actual code here seems to be a mixture of bot.

- Toralf



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com