[boost] [Boost-bugs] [ boost-Bugs-1710770 ] gcc strict-aliasing problems with python

From: SourceForge.net (noreply_at_[hidden])
Date: 2007-05-01 15:28:24

Bugs item #1710770, was opened at 2007-05-01 19:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1710770&group_id=7586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kim Barrett (kbarrett)
Assigned to: David Abrahams (david_abrahams)
Summary: gcc strict-aliasing problems with python

Initial Comment:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1710770&group_id=7586

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Boost-bugs mailing list
Boost-bugs_at_[hidden]
https://lists.sourceforge.net/lists/listinfo/boost-bugs