TR : Possible GCC bug on m68k

[Joel Sherrill <joel@OARcorp.com>]

Etienne Fortin wrote:
> Hi everyone,
> I know I should put this on the GCC forum, but I want to be sure that
> I'm not mystaken with the behavior I'll describe.
> 
> I have the following code:
>     packet->number = (unsigned char)fgetc(sender);
>     comp = (unsigned char)fgetc(sender);
>     if(packet->number != ~comp)
>         return EIO;
> 
> packet->number = 0 and comp = 0xFF.

You do not show types of the various elements in the above fragment
so I can't say.  What are packet->number and comp?

I suspect they are 32-bit unsigned integers and with that the behavior
you are describing seems correct.  The (unsigned char) is truncating
the return from fgetc() but the "=" is promoting it to the unsigned
32-bit integer.  When you ~comp, you flip the upper 24-bits and
there you have it.

> We would presume that return EIO will NOT be taken. But in fact, it is.
> 
> I dissaembled the code and found out that the compiler generated a
> comparison between d0 and d1 register, and that d0=0x00000000 and
> d1=0xFFFFFF00!!! It seems that the code generated by GCC assumes words
> when bytes are compared. The compiler should generate code that make
> sure only the byte of the register is significant in the comparison. But
> it does not.
> 
> Is it a bug? a known behavior? A newbie thing? :)
> 
> And by the way, modifying the above code like this makes it work:
> 
>     packet->number = (unsigned char)fgetc(sender);
>     comp = (unsigned char)fgetc(sender);
>     if(packet->number != (~comp & 0xFF))
>         return EIO;
> 
> 
> Etienne Fortin
> Sensio
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985