TR : Possible GCC bug on m68k

[Chris Johns]

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