[Bug c++/53455] New: g++ builds segfault in boost::python

["j.wielicki at sotecware dot net" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455

             Bug #: 53455
           Summary: g++ builds segfault in boost::python
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: j.wielicki@sotecware.net
              Host: linux x86_64 (fedora 17)
            Target: linux x86_64 (fedora 17)


With the upgrade to fedora 17, I upgraded to g++ 4.7, which builds a segfault
in my current project. 

I did a lot of research before submitting this bug, while discussing the
problem with Niall Douglas on the c++sig mailing list of python. So here is
what I found.

First the problem itself. In inheritance.cpp:405 (the .ii file of the
compilation is attached), compiled with:
g++  -ftemplate-depth-128 -O0 -finline-functions -Wno-inline -Wall -std=c++11
-pthread  -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_USE_LIB=1 -DNDEBUG  -I.
-I/usr/include/python2.7 -c libs/python/src/object/inheritance.cpp -save-temps

the value of p gets somehow lost. This is what gdb has to say to this:
#0  0x0000000000405af7 in
boost::python::objects::polymorphic_id_generator<Foo>::execute
(p_=0x40a268) at /usr/include/boost/python/object/inheritance.hpp:43
#1  0x00007ffff7dcb684 in boost::(anonymous namespace)::convert_type (p=
    0x666db0, src_t=..., dst_t=..., polymorphic=true)
    at
/usr/src/debug/boost_1_48_0/libs/python/src/object/inheritance.cpp:405

Inspecting the code we find that p_ in execute should actually be the same as
p, as it is passed literally in convert_type. However, its value magically
changes. Here are the characteristics of the problem.

It reoccurs with inlining force-disabled.
It reoccurs with optimization and without (tried for both, the testing program
and for compiling libboost_python).
It does _not_ reoccur without -std=c++11 in the testing program. 
I am not using precompiled headers.

I tried boost as delivered with fedora 17, a home-compiled version with
-std=c++11 and a home-compiled version without c++11. The c++11 flag on the
_library_ does not seem to influence the problem, although the value change is
inside the library. However, when turning off c++11 for the testing program
(going to attach the .ii too), it works fine.

This behaviour did not occur with g++ 4.6.3 and -std=c++0x.

Please do not hesitate to ask back if you need any more information, I'm glad
if I can help. I also hope that I read the guidelines for bug reporting
correctly. If you nevertheless want my testing program source attached, I will
also attach that.

The crashtest.ii was compiled with:
g++ -Wall -g -std=c++0x -I/usr/include/python2.7 -fno-inline -save-temps 
/home/tester/libboost_python.so.1.48.0 -lpython2.7  crashtest.cpp   -o
crashtest

g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC)