[boost] [1_34_0] [python] gcc strict-aliasing warnings in release mode

From: Kim Barrett (kab_at_[hidden])
Date: 2007-04-27 02:02:38

I'm trying out the boost 1.34.0 beta, and there are some warnings of interest.

I'm using gcc 4.1 x86/32 (on SuSE 10.1), building boost with
"variant=release".

There are several occurrences of

     "dereferencing type-punned pointer will break strict aliasing rules"

with locations listed below.

libs/iostreams/src/zlib.cpp:108
libs/iostreams/src/zlib.cpp:109

libs/python/src/list.cpp:16
libs/python/src/long.cpp:12
libs/python/src/long.cpp:19
libs/python/src/long.cpp:26
libs/python/src/dict.cpp:32
libs/python/src/tuple.cpp:12
libs/python/src/str.cpp:13
libs/python/src/class.cpp:571
libs/python/src/class.cpp:581

This build of boost is being compiled against Python 2.5. Note that
Python 2.5 on this platform builds with gcc's -fno-strict-aliasing
option. My personal experiences with strict-aliasing problems with
gcc, as well as anectdotal information, leads me to strongly suggest
that Boost.Python should also be built with that compiler flag (at
least when building in release mode), and that possibly any client
wrapper code should do so as well. This is because the Python headers
that Boost.Python (and client code) depend on may not be
strict-aliasing correct. The result of not being strict-aliasing
correct when gcc's strict-aliasing option is enabled (which it is by
default for gcc versions starting with 4.0?) is that the compiler may
generate code which is (often quite subtly) broken. (A couple of weeks
ago I ran afoul of this problem with a different library, where gcc's
warnings were a false negative (i.e. no warning) and just silently
generated non-working code if strict-aliasing was enabled. I'm
presently looking at diffs in the generated assembly code (not fun)
because I haven't been able to find the problem by looking at the
source.)