[1_34_0] [python] gcc strict-aliasing warnings in release mode
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.)
At 2:02 AM -0400 4/27/07, Kim Barrett wrote:
There are several occurrences of
"dereferencing type-punned pointer will break strict aliasing rules"
It seems that this problem has been around for a long time (essentially this same set of warnings occur with boost 1.33.1 when built with recent versions of gcc). I've become more sensitive to the strict aliasing issue, having been personally punched in the nose by it twice in the last six months, but hadn't realized the boost version we're using had these warnings. I will certainly be adding a local patch for our use of Boost 1.34.0 if this isn't addressed as part of the release, but given its long history this issue might reasonably be considered non-critical for the general release.
Note that Python 2.5 on this platform builds with gcc's -fno-strict-aliasing option.
A little further digging found that this has been true since Python 2.3.
on Sat Apr 28 2007, Kim Barrett <kab-AT-irobot.com> wrote:
At 2:02 AM -0400 4/27/07, Kim Barrett wrote:
There are several occurrences of
"dereferencing type-punned pointer will break strict aliasing rules"
It seems that this problem has been around for a long time (essentially this same set of warnings occur with boost 1.33.1 when built with recent versions of gcc). I've become more sensitive to the strict aliasing issue, having been personally punched in the nose by it twice in the last six months, but hadn't realized the boost version we're using had these warnings. I will certainly be adding a local patch for our use of Boost 1.34.0 if this isn't addressed as part of the release, but given its long history this issue might reasonably be considered non-critical for the general release.
I guess I have to agree. I would, however, appreciate it very much if you'd put your patch into the SF patch tracker so it can be applied for 1.35 -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
At 7:40 AM -0400 5/1/07, David Abrahams wrote:
on Sat Apr 28 2007, Kim Barrett <kab-AT-irobot.com> wrote:
At 2:02 AM -0400 4/27/07, Kim Barrett wrote:
There are several occurrences of
"dereferencing type-punned pointer will break strict aliasing rules"
I would, however, appreciate it very much if you'd put your patch into the SF patch tracker so it can be applied for 1.35
I don't think you would like my patch, which consists of adding the line flags gcc.compile OPTIONS : -fno-strict-aliasing ; to tools/build/v2/tools/gcc.jam, turning off strict-aliasing globally for all of building boost with any version of gcc. I spent a little bit of time failing to figure out how to narrow the scope of the option to either more limited versions of gcc (I think the option doesn't show up until somewhere around 3.2 / 3.3) or limit it to only boost.python, but since I don't actually need either of those I eventually punted. I did file a bug report, so that you have a reminder that something needs to be done: bug 1710770: gcc strict-aliasing problems with python. And I'm happy to help out with fixing / testing / reviewing, just don't know enough bjam. There may be some documentation changes needed to, though I note that the 1.33.1 documentation regarding building extension modules just refers to using either Boost.Build or looking at the options it would use.
participants (2)
-
David Abrahams -
Kim Barrett