TR : Possible GCC bug on m68k
etienne.fortin at sensio.tv
etienne.fortin at sensio.tv
Wed Nov 3 02:48:31 UTC 2004
Hi Chris,
I may be mystaken, but your example is not valid since char and short
varargs are promoted to int. This is from the opengroup web site on
varargs.h:
"
C language converts type char and short arguments to int and converts type
float arguments to double before passing them to a function.
"
So the promotion to int, in your example, is not from the ~ operator but
from the fact that varargs are promoted to int.
Etienne Fortin
Sensio
> Thomas Doerfler wrote:
>>
>> I tried Joels test with a gcc-2.8.1. It also generated code with
>> a "long" (32 bit) compare. My idea about that: Wouldn't the "~"
>> operator generate an "int" result, forcing the comparision to be
>> done with "int" (=32 bit) size? This does not make sense in that
>> situation, but this is an issue for the programmer (Etienne) not
>> the compiler. Am I totally wrogn with this?
>>
>
> I think you are correct. Here is another example that shows this:
>
> /* m68k-rtems-gcc -g -c -o comp.o comp.c */
> #include <stdio.h>
> int main ()
> {
> unsigned char v = 0;
> printf ("v = %i (0x%08x)\n", ~v, ~v);
> return 0;
> }
>
> The code is:
>
> #include <stdio.h>
> int main ()
> {
> unsigned char v = 0;
> 0: 4e56 fffc linkw %fp,#-4
> comp.c:6
> printf ("v = %i (0x%08x)\n", ~v, ~v);
> 4: 422e ffff clrb %fp@(-1) <--- correct size
> comp.c:7
> return 0;
> 8: 4280 clrl %d0 <--- changed type
> a: 102e ffff moveb %fp@(-1),%d0 <--- geting the value
> e: 4680 notl %d0
> 10: 2f00 movel %d0,%sp at -
> 12: 4280 clrl %d0
> 14: 102e ffff moveb %fp@(-1),%d0
> 18: 4680 notl %d0
> 1a: 2f00 movel %d0,%sp at -
> 1c: 4879 0000 0000 pea 0 <main>
> 22: 61ff 0000 0000 bsrl 24 <main+0x24>
> 28: 4fef 000c lea %sp@(12),%sp
> comp.c:8
> }
> 2c: 4280 clrl %d0
> comp.c:9
> 2e: 4e5e unlk %fp
> 30: 4e75 rts
>
> I compiled the code on Linux and the result is:
>
> $ ./comp
> v = -1 (0xffffffff)
>
> --
> Chris Johns
>
More information about the users
mailing list