[cfe-dev] Crash in Clang 3.3

[Fil Mackay]

On Wed, Sep 25, 2013 at 9:10 PM, Tim Northover-2 [via Clang Developers] <
ml-node+s42468n4034663h96 at n3.nabble.com> wrote:

> 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)
>
> On 25 September 2013 01:14, fil <[hidden email]<http://user/SendEmail.jtp?type=node&node=4034663&i=0>>
> wrote:
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130927/4fd91bc1/attachment.html>