gcc 2.95.3/ARM problems comparing with negative

Toralf Lund toralf@procaptura.com
Mon Nov 1 11:47:00 GMT 2004


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



More information about the crossgcc mailing list