On Sun, 5 Sep 2010, Denys Vlasenko wrote:
> On Sun, Sep 5, 2010 at 12:50 PM, Cristian Ionescu-Idbohrn
> <[email protected]> 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
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
