gcc strict-aliasing problems with python

[kbarrett]

With the Boost 1.34.0 beta release candidate, and also with Boost 1.33.1, and probably before that too, building Boost.Python in release mode with a recent version of gcc (4.x) generates several occurrences of warnings:

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

Beginning with Python 2.3 and at least through Python 2.5, when building Python with gcc, the gcc option -fno-strict-aliasing is used. So clearly the Python developers don't consider Python to be strict-aliasing correct (or else don't trust gcc's strict-aliasing analysis).

The result of not being strict-aliasing correct when gcc's strict aliasing option is enabled (which I think is the default for gcc 4.0 onward, at least at high optimization levels) is that the compiler may generate non-working code.

I don't have any specific evidence that the warnings from compiling Boost.Python indicate actual problems. These warnings may appear without there being any actual code generation differences. Unfortunately, that may vary from one version of gcc to another. Even worse, gcc may fail to generate warnings in cases where it does indeed generate non-working code. The best method I know of for finding instances of code broken by strict-aliasing based optimizations is to compile with and without that option, compare the generated code, and carefully examine the places that are different, with some differences being seemingly harmless. In other words, a very difficult and error-prone process.

I recommend that building Boost.Python with recent versions of gcc similarly supply the -fno-strict-aliasing option, and that it should also be used when compiling code that uses Boost.Python.

[Dave Abrahams]

If we could find a way to do this everywhere except Py3K, it would be ideal.