This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: help interpreting gcc 4.1.1 optimisation bug
andrew@walrond.org writes:
> On Mon, Jun 12, 2006 at 02:21:21PM +0200, Richard Guenther wrote:
> > On 6/12/06, andrew@walrond.org <andrew@walrond.org> wrote:
> > >On Mon, Jun 12, 2006 at 01:01:47PM +0100, Andrew Haley wrote:
> > >>
> > >> I'm starting to be a little suspicious about host2little(). I wonder
> > >> if that's well-defined.
> > >>
> > >> I'm just guessing here becasue I can't see the code. Is it possible
> > >
> > > template<typename T> T swap_endian(T x)
> > > {
> > > char* a = reinterpret_cast<char*>(&x);
> > > char* b = a + sizeof(T) - 1;
> > > while (a<b) {
> > > char tmp = *a;
> > > *a++ = *b;
> > > *b-- = tmp;
> > > }
> > > return x;
> > > }
> > >
> > > template<typename T> T host2little(T x)
> > > {
> > > unsigned u = 1; return (*reinterpret_cast<char*>(&u) ? x :
> > > swap_endian(x));
> > > }
> >
> > You are violating aliasing rules. Try -fno-strict-aliasing, which
> > should make the code
> > work, or fix it.
>
> Hmmm - don't grok; I'll do some googling. Compiling now with
> -fno-strict-aliasing, but the manual says -O2 includes
> -strict-aliasing, so what gives?
-fno-strict-aliasing is a kludge that causes gcc to ignore type
information when generating memory accesses. This means that gcc
assumes that an object pointed to by a pointer potentially refers to
any object in your program; this has the effect of preventing many
optimizations.
If -fno-strict-aliasing fixes your problem, then you have a bug in
your code somewhere. This option is provided for compatibility with
ancient code.
Andrew.