dragonegg segfaults while compiling llvm/clang on Gentoo

[llvmbot]

Bugzilla Link	11144
Resolution	INVALID
Resolved on	Oct 17, 2011 05:31
Version	trunk
OS	Linux
Attachments	llvm buildlog
Reporter	LLVM Bugzilla Contributor

Extended Description

When compiling LLVM or Clang from svn on gentoo (sys-devel/llvm-9999; sys-devel/clang-9999) with gcc-4.5.3 and the dragonegg plugin, there is a segfault when trying to compile PrintModulePass.cpp (in both cases).

Without the plugin, both compile fine.

[llvmbot]

32 bit or 64 bit machine?

[llvmbot]

I am unable to reproduce this on 64 bit debian.

[llvmbot]

This is on 64bit, with CXXFLAGS="-march=amdfam10 -O2 -fplugin=/usr/local/lib/dragonegg.so"

[llvmbot]

I still can't reproduce, so can you please do the following: build with
make VERBOSE=1
When the build fails, you should have the failing make line on your screen.
This is something complicated, but in it is the actual compilation part
starting with g++. If you run that g++ line, you should be able to reproduce
the failure directly. Please run that g++ line but adding -save-temps to the
command line options. This should produce a file PrintModulePass.ii which you
should attach to this bug report. Also, try the g++ line but adding -S -flto
to the command line options. If that succeeds (doesn't crash) please also attach
the resulting PrintModulePass.s file to this bug report.

[llvmbot]

I tried to reproduce, but failed. This seems to be a problem only arising when building with emerge. When building with ./configure, make, things compile fine, so I guess this bug is in some way triggered by the ebuild.

[llvmbot]

Maybe you can tweak the LLVM configure script to dump the environment, in
case emerge set some funky stuff in there. Another possibility is that
emerge applies a memory limit, and the compiler is using too much memory.

[llvmbot]

emerge --info
This is what emerge --info says about the environment. Maybe this helps.

[llvmbot]

Try a more recent version of gcc-4.5. I think this might be due to a GCC bug
that was fixed in gcc 4.5.4. Alternatively, use gcc-4.6 (any version).

[llvmbot]

config.log for gcc-4.6.1-r1

=sys-devel/gcc-4.5.4 is not available in portage.
=sys-devel/gcc-4.6 is hard masked. 4.6.1 and 4.6.1-r1 are available though. I've unmasked 4.6.1-r1 and recompiled llvm and dragonegg.
Now I don't even get past ./configure:
checking for C compiler default output file name... configure: error: C compiler cannot create executables

[llvmbot]

Created an attachment (id=7465) [details]
config.log for gcc-4.6.1-r1

=sys-devel/gcc-4.5.4 is not available in portage.
=sys-devel/gcc-4.6 is hard masked. 4.6.1 and 4.6.1-r1 are available though. I've unmasked 4.6.1-r1 and recompiled llvm and dragonegg.
Now I don't even get past ./configure:
checking for C compiler default output file name... configure: error: C
compiler cannot create executables

However, this is probabely an entirely different bug.

[llvmbot]

The configure script is running this line:
gcc -O2 -march=amdfam10 -fplugin=/usr/local/lib/dragonegg.so conftest.c
which is failing because of a version mismatch between gcc and dragonegg.so.
Either gcc is gcc-4.5 but dragonegg was built against gcc 4.6, or gcc is gcc-4.6
but dragonegg was built against gcc 4.5.

[llvmbot]

you were right, this seems to have been related to version mismatch, which is weird though, since I was pretty sure I had recompiled dragonegg with gcc-4.6.1 before. I'm recompling llvm with dragonegg and gcc-4.6.1 now.

[llvmbot]

This was a gcc-4.5 bug manifesting itself. The bug was fixed in gcc 4.5.4 and
was never present in gcc-4.6.