Re: [Boost-bugs] [Boost C++ Libraries] #910: gcc strict-aliasing problems with python

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #910: gcc strict-aliasing problems with python
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2007-07-03 14:30:47

#910: gcc strict-aliasing problems with python
-----------------------+----------------------------------------------------
  Reporter:  kbarrett  |       Owner:  dave       
      Type:  Bugs      |      Status:  new        
 Milestone:            |   Component:  Python     
   Version:  None      |    Severity:  Showstopper
Resolution:  None      |    Keywords:             
-----------------------+----------------------------------------------------
Changes (by dave):

  * owner:  david_abrahams => dave
  * status:  assigned => new
  * severity:  => Showstopper

Old description:

> {{{
> 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.
>
> }}}

New description:

 {{{
 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.

 }}}

-- 
Ticket URL: <http://svn.boost.org/trac/boost/ticket/910#comment:1>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.