GCC 4.4: Stricter aliasing requirements

Cristian Ionescu-Idbohrn cristian.ionescu-idbohrn at axis.com
Sun Sep 5 14:59:15 UTC 2010


On Sun, 5 Sep 2010, Denys Vlasenko wrote:

> On Sun, Sep 5, 2010 at 12:50 PM, Cristian Ionescu-Idbohrn
> <cristian.ionescu-idbohrn at axis.com> wrote:
> > After the latest debian gcc upgrade:
> >
> > Using built-in specs.
> > Target: i486-linux-gnu
> > Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.4-13'
> > --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
> > --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
> > --program-suffix=-4.4 --enable-shared --enable-multiarch
> > --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
> > --without-included-gettext --enable-threads=posix
> > --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
> > --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
> > --enable-targets=all --with-arch-32=i586 --with-tune=generic
> > --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
> > --target=i486-linux-gnu
> > Thread model: posix
> > gcc version 4.4.5 20100902 (prerelease) (Debian 4.4.4-13)
> >
> > I see a masive (183) number of warnings similar to this one:
> >
> > procps/fuser.c:45: warning: dereferencing type-punned pointer will break
> > strict-aliasing rules
> >
> > Explained here (GCC 4.4 Release Series - Porting to the New Tools):
> >
> >        http://gcc.gnu.org/gcc-4.4/porting_to.html
>
> What do you propose to do?

Up to the maintainer ;) But this is the advise:

	This can be temporarily worked around by using
	-fno-strict-aliasing or by ignoring this class of warning via
	-Wno-strict-aliasing. To fix, access the structure from pointers
	of an equivalent type, use a union, use memcpy, or (if using C++)
	use placement new. See the section titled "Casting does not work
	as expected when optimization is turned on" on bug reporting
	documentation page for more information.

and points to another page:

	http://gcc.gnu.org/bugs/

and an article:

	http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html

I would vote for fixing the code generating 183+ warnings, but I realize
that takes some effort.  On the other side, if the maintainer trusts the
code is doing TRT, then a compiler option shutting the compiler up may be
the another option.  What do people think?


Cheers,

-- 
Cristian


More information about the busybox mailing list