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