Crash in Clang 3.3

Hi all,

I'm newish to the Clang world, I have recently upgraded from the latest
Apple Clang (3.3svn) to the final 3.3 release. When I compile code (that
compiles fine under Apple) under 3.4 head I got this exception, and have now
found it happens with 3.3final as well. Any assistance on the next steps to
diagnose this would be appreciated. I have built LLVM with homebrew under
OSX.

One thing I just noticed: I was using -emit-llvm to compile the .cpp code,
removing that causes it to compile OK. However, compiling with -emit-llvm
under Apple LLVM 3.3 still works OK.

The -emit-llvm was there is an attempt to get profiling working (my next
question :).

Please file a bug with Apple with the source code and command line that reproduces your problem. (You don’t need to reproduce it in Xcode; just the source code and a command that we can run that duplicates the crash would be great.)

Thanks!

John.

Hi fil,

Most of the activity here happens via the mailing lists rather than
that "nabble.com", and your error message in particular hasn't shown
up here:

fil$ clang++-3.3 -stdlib=libc++ -lboost_iostreams -lboost_date_time
-lboost_system -lboost_filesystem -g -O0 Col.o Decimal.o Dim.o NTime.o
Stream.o String.o main.o ops.o tick.o -o stat -v

clang version 3.3 (tags/RELEASE_33/final)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
"/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min
10.8.0 -o stat -lboost_iostreams -lboost_date_time -lboost_system
-lboost_filesystem Col.o Decimal.o Dim.o NTime.o Stream.o String.o
main.o ops.o tick.o -lc++ -lSystem
/usr/local/Cellar/llvm33/3.3/lib/llvm-3.3/bin/../lib/clang/3.3/lib/darwin/libclang_rt.osx.a
Stack dump:
0. Running pass 'Function Pass Manager' on module 'ld-temp.o'.
1. Running pass 'X86 AT&T-Style Assembly Printer' on function '@_GLOBAL__I_a'
clang: error: unable to execute command: Segmentation fault: 11
clang: error: linker command failed due to signal (use -v to see invocation)

One thing I just noticed: I was using -emit-llvm to compile the .cpp code,
removing that causes it to compile OK. However, compiling with -emit-llvm
under Apple LLVM 3.3 still works OK.

The error comes from ld, and indicates that LTO is being tried. That
fits with you passing -emit-llvm. It also means you're trying to do
the actual compilation of some LLVM IR produced by Clang 3.4trunk
using the backends and so on (libLTO.dylib) from Apple's Clang 3.3
branch. That's not going to end well.

One (unsupported, I believe) option is to point ld at a libLTO that
was built alongside your clang by setting the environment variable
DYLD_LIBRARY_PATH=/path/where/libLTO/lives.

Cheers.

Tim.

Hi fil,

Most of the activity here happens via the mailing lists rather than
that "nabble.com", and your error message in particular hasn't shown
up here:

Apologies.. was just a handy way to do historical searches etc.

/usr/local/Cellar/llvm33/3.3/lib/llvm-3.3/bin/../lib/clang/3.3/lib/darwin/libclang_rt.osx.a

Stack dump:
0. Running pass 'Function Pass Manager' on module 'ld-temp.o'.
1. Running pass 'X86 AT&T-Style Assembly Printer' on function
'@_GLOBAL__I_a'
clang: error: unable to execute command: Segmentation fault: 11
clang: error: linker command failed due to signal (use -v to see
invocation)

> One thing I just noticed: I was using -emit-llvm to compile the .cpp
code,
> removing that causes it to compile OK. However, compiling with
-emit-llvm
> under Apple LLVM 3.3 still works OK.

The error comes from ld, and indicates that LTO is being tried. That
fits with you passing -emit-llvm. It also means you're trying to do
the actual compilation of some LLVM IR produced by Clang 3.4trunk
using the backends and so on (libLTO.dylib) from Apple's Clang 3.3
branch. That's not going to end well.

One (unsupported, I believe) option is to point ld at a libLTO that
was built alongside your clang by setting the environment variable
DYLD_LIBRARY_PATH=/path/where/libLTO/lives.

You were spot on.

For the reference of others, to fix this issue I copied /usr/bin/ld to
/usr/local/bin/ld; I have a brew'd llvm which targets /usr/local. This
works since the reference from ld to the dylib (using otool)
was @executable_path/../lib/libLTO.dylib. I didn't want to mess with
anything in /usr/lib.

Is there any down side in using LTO (ie. using -emit-llvm on compile)? I'm
guessing not, but...

Now onto the next issue: profiling..

Regards, Fil.

Is there any down side in using LTO (ie. using -emit-llvm on compile)? I'm
guessing not, but...

Well, the official way to use LTO is with "-flto". -emit-llvm is more
of a debugging flag that just happens to send code through the LTO
path by coincidence.

Anyway, for disadvantages: LTO compiles will probably take longer and
use more memory (possibly lots). Problems could be harder to track
down. But it does give rather impressive speedups from what I've
heard.

Cheers.

Tim.

Thanks for the clarification. So it sounds like -flto could be a good
release build flag? This would be on the clang++ compile command, not
needed on the link?