TR : Possible GCC bug on m68k

[Etienne Fortin]

The one that comes with RTEMS-4.6.1.

Etienne


-----Message d'origine-----
De : Joel Sherrill <joel at OARcorp.com> [mailto:joel.sherrill at OARcorp.com]

Envoyé : 2 novembre, 2004 16:26
À : Etienne Fortin
Cc : rtems-users at rtems.com
Objet : Re: RE : TR : Possible GCC bug on m68k


Etienne Fortin wrote:
> Hi Joel,
> Packet->number and comp are defined as unsigned char also.

Sounds like a bug to me.  Can you cut this down to an
extremely small test case that does it?  If you
can do it without the library calls that would be great.
Even if you have to define your own function with
similar prototype.

What gcc is this?

> Etienne
> 
> 
> 
> -----Message d'origine-----
> De : Joel Sherrill <joel at OARcorp.com> 
> [mailto:joel.sherrill at OARcorp.com]
> 
> Envoyé : 2 novembre, 2004 16:08
> À : Etienne Fortin
> Cc : rtems-users at rtems.com
> Objet : Re: TR : Possible GCC bug on m68k
> 
> 
> 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