TR : Possible GCC bug on m68k

Thomas Doerfler Thomas.Doerfler at imd-systems.de
Tue Nov 2 22:34:39 UTC 2004


Hi,

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?

wkr, and good night :-)
Thomas.


> Yes, it seems to match what I'm getting.
> 
> 
> -----Message d'origine-----
> De : Joel Sherrill <joel at OARcorp.com> [mailto:joel.sherrill at OARcorp.com]
> 
> Envoyé : 2 novembre, 2004 17:01
> À : Etienne Fortin
> Cc : rtems-users at rtems.com
> Objet : Re: RE : RE : TR : Possible GCC bug on m68k
> 
> 
> Etienne Fortin wrote:
> > The one that comes with RTEMS-4.6.1.
> > 
> 
> That would have been a gcc 3.2 series.  I now have an
> example which is pretty simple:
> 
> typedef struct {
>    unsigned char number;
> } pkt;
> 
> unsigned int f( int i );
> int g( pkt *packet )
> {
>    unsigned char comp;
> 
>    packet->number = (unsigned char)f(1);
>    comp = (unsigned char)f(2);
>    if (packet->number != ~comp)
>       return 1;
>    return 0;
> }
> /* packet->number = 0 and comp = 0xFF. */
> 
> 
> I tried it with the latest 4.6.2 tools and my current
> gcc 3.3.5 tools for 4.7 and it shows the same disassembly
> at both -02 and -O4.
> 
> /opt/rtems-4.7/bin/m68k-rtems4.7-gcc -S -O4 m68k1.c
> /opt/rtems-4.6/bin/m68k-rtems-gcc -S -O2 m68k1.c
> 
> Does this example match what you think is happening?
> 
> --joel
> 

--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler           Herbststrasse 8
D-82178 Puchheim          Germany
email:    Thomas.Doerfler at imd-systems.de
PGP public key available at: http://www.imd-
systems.de/pgp_keys.htm




More information about the users mailing list