search for: libltos

On Fri, Sep 04, 2015 at 03:11:39PM -0700, Mehdi Amini wrote: > > > On Sep 4, 2015, at 11:38 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > > On Fri, Sep 04, 2015 at 11:13:43AM -0700, Mehdi Amini wrote: > >> > >>> On Sep 4, 2015, at 11:03 AM, Eric Christopher <echristo at gmail.com> wrote: > >>> > >>> >

On Fri, Sep 04, 2015 at 11:13:43AM -0700, Mehdi Amini wrote: > > > On Sep 4, 2015, at 11:03 AM, Eric Christopher <echristo at gmail.com> wrote: > > > > > > > > On Fri, Sep 4, 2015 at 12:48 AM Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Sep 4, 2015, at 12:22 AM, Eric Christopher <echristo

Hello, Is there any CMake variable available to build LLVM libs as static libraries. I found one -DLIBCLANG_BUILD_STATIC=ON but what if I want libLTO.a instead of libLTO.dylib ? *Vivek Pandya* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151214/1e03efc9/attachment.html>

Hi all, libLTO is exposing a very “stable” (in the sense of immutable) C API to be used by linkers (and binutils tools) that manipulate bitcode (like when performing LTO). I’m looking into relaxing the stability concern and design a policy for this API that would allow to deprecate and remove some the APIs exposed here. The MacOS linker (ld64) is one the users of libLTO, but there are others

Shantonu Sen wrote: > Are you building llvm-gcc yourself? If so, what version? > > Xcode releases include an older llvm-gcc and libLTO.dylib, which may not understand bitcode generated by newer self-built compilers. > Thanks. A bitcode format mismatch was the problem. I'm not sure if the problem stems from the fact that the bitcode was generated for the wrong architecture

Are you building llvm-gcc yourself? If so, what version? Xcode releases include an older llvm-gcc and libLTO.dylib, which may not understand bitcode generated by newer self-built compilers. If you are only using llvm-gcc from the Xcode tools release, use the driver from: /Developer/usr/bin/llvm-gcc-4.2 If you are building llvm-gcc yourself, try, in this order: 1) sudo ln -s

On Fri, Sep 4, 2015 at 12:48 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > On Sep 4, 2015, at 12:22 AM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Thu, Sep 3, 2015 at 11:45 PM Mehdi Amini <mehdi.amini at apple.com> wrote: > >> Hi, >> >> > On Sep 2, 2015, at 7:31 PM, Peter Collingbourne via llvm-dev < >>

Hello, I trying TSAN on Darwin on LLVM itself (sanitizing multi-threaded ThinLTO link). However I see two main issues on my debug build: 1) Statistics: the pre/post increment is not safe, it seems to be acknowledge in the code itself: // FIXME: This function and all those that follow carefully use an // atomic operation to update the value safely in the presence of // concurrent

For dogfooding the compiler I normally use is a LTO bootstrap of clang. On linux that is simple to do that since clang passes the correct plugin to the linker. On OS X ld64 uses libLTO.so it finds via DYLD_LIBRARY_PATH. Should clang set that before running the linker? Is there a better way for clang to tell the linker which libLTO.so to use? Cheers, Rafael

AFAIK, ld does not use DYLD_LIBRARY_PATH to lookup libLTO.dylib but contains a reference to @executable_path/../lib/libLTO.dylib. The only way I managed to load a different LTO library than the default one is to create a symlink pointing to the actual ld binary (as returned by 'xcrun -find ld') and making sure the library I want to load is placed at ../lib/libLTO.dylib relatively to this

Hello all, I'm a research assistant at the University of Wisconsin and we're trying to come up with a general way to run our whole program analysis over programs that may use different methods to perform the build. I saw some discussion that liblto could be used for this (and safecode successfully did it) for llvm 2.6 - 3.0, but that doesn't seem to be working the same way with llvm

I'm confused. libLTO takes bitcode files as input and creates a native object file as output. Why would libLTO create bitcode as output? If so, you're changing the existing API contract. Or are you creating an out-of-band bitcode file, in which case the linker would never see it. ld doesn't have bitcode support, it has libLTO support, and libLTO is what processes the bitcode.

On Thu, Sep 3, 2015 at 11:45 PM Mehdi Amini <mehdi.amini at apple.com> wrote: > Hi, > > > On Sep 2, 2015, at 7:31 PM, Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Thu, Sep 03, 2015 at 01:10:42AM +0000, Eric Christopher wrote: > >> On Tue, Sep 1, 2015 at 10:43 AM Duncan P. N. Exon Smith < > >>

On Thu, Sep 03, 2015 at 01:10:42AM +0000, Eric Christopher wrote: > On Tue, Sep 1, 2015 at 10:43 AM Duncan P. N. Exon Smith < > dexonsmith at apple.com> wrote: > > > > > > On 2015-Aug-31, at 18:09, Eric Christopher <echristo at gmail.com> wrote: > > > > > > > > > > > > On Mon, Aug 31, 2015 at 5:50 PM Duncan P. N. Exon Smith

...S=macos RC_ARCHS="i386" TARGETS="i386 x86_64" SRCROOT=`pwd` OBJROOT=`pwd`/build/obj DSTROOT=`pwd`/build/dst SYMROOT=`pwd`/build/sym 3. Replace old llvm-gcc with new one # rm -rf /Developer/usr/llvm-gcc-4.2 # ditto build/dst / ------ rest only once ------- 4. Fix libLTOs # rm /Developer/usr/lib/libLTO.dylib # ln -sf /Developer/usr/local/lib/libLTO.dylib /Developer/usr/lib/ libLTO.dylib # rm /usr/lib/libLTO.dylib # ln -sf /Developer/usr/local/lib/libLTO.dylib /usr/lib/ libLTO.dylib 5. Fix /Developer/SDKs/MacOSX10.5.sdk/Developer/usr # cd...

Dear LLVMers, I'm currently working on creating an alternate libLTO.so that will run some whole-program analysis and transforms of mine during the final linking of an executable. The idea is for it to link all of the bitcode files together, run the regular LTO passes, and then run my passes. For Linux, I should be able to get the Gold linker to load my libLTO.so instead of the standard

> On 2015-Aug-31, at 18:09, Eric Christopher <echristo at gmail.com> wrote: > > > > On Mon, Aug 31, 2015 at 5:50 PM Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > > On 2015-Aug-31, at 12:21, Eric Christopher <echristo at gmail.com> wrote: > > Yep. This is where I was going :) > > Glad I found consensus, but I want to

On Dec 4, 2009, at 2:49 PM, John Criswell wrote: >> If you are building llvm-gcc yourself, try, in this order: >> 1) sudo ln -s ../../Developer/usr/lib/libLTO.dylib /usr/lib/ >> libLTO.dylib >> >> 2) If you still get errors, try installing the libLTO.dylib from >> your LLVM build into /Developer/usr/lib. Make sure that if you're >> on a 64-bit

Dear John, Thanks for your reply. I want to do whole program analysis, all what I need are just the separate .bc files. What instructions should I follow? I run the configure on apache in this way: CC=clang CFLAGS=-emit-llvm ./configure while I get the error message like: checking for gcc... clang checking for C compiler default output file name... configure: error: C compiler cannot

Wink zhang wrote: > Dear John, > > Thanks for your reply. I want to do whole program analysis, all what I > need are just the separate .bc files. What instructions should I follow? > I'm a little confused. Whole-program analysis requires that you link all of the individual bitcode files from different compilation unit (i.e., individual .c files) together into a single