similar to: [LLVMdev] C++0x Bug in CMake?

Which version of CMake? On Tue, Jan 21, 2014 at 10:06 AM, Chandler Carruth <chandlerc at gmail.com>wrote: > Maybe, I'll have to debug. It does seem quite bizarre. > > > On Tue, Jan 21, 2014 at 10:03 AM, Renato Golin <renato.golin at linaro.org>wrote: > >> Chandler, >> >> I may be doing this wrong, but I'm getting a weird error in building

On Tue, Jan 21, 2014 at 10:20 AM, Dmitri Gribenko <gribozavr at gmail.com>wrote: > On Tue, Jan 21, 2014 at 8:03 PM, Renato Golin <renato.golin at linaro.org> > wrote: > > Chandler, > > > > I may be doing this wrong, but I'm getting a weird error in building LLVM > > with Clang via CMake. > > I have been debugging a similar issue that I isolated

Should be fixed in r199756. Let me know. On Tue, Jan 21, 2014 at 10:08 AM, Chandler Carruth <chandlerc at gmail.com>wrote: > Never mind, I see the bug. Working on a fix. > > > On Tue, Jan 21, 2014 at 10:07 AM, Chandler Carruth <chandlerc at gmail.com>wrote: > >> Which version of CMake? >> >> >> On Tue, Jan 21, 2014 at 10:06 AM, Chandler Carruth

George Karpenkov <ekarpenkov at apple.com> writes: > OK so with Kuba’s help I’ve found the error: with optimization, dead > stripping of produced libraries is enabled, > which removes coverage instrumentation. > > However, this has nothing to do with the move to compiler-rt, so I’m > quite skeptical on whether it has worked > beforehand. > > A trivial fix is to do:

(kcc, george: sorry for the re-send, the first was from a non-list email address) My configuration for building the fuzzers in the LLVM tree doesn't seem to work any more (possibly as of moving libFuzzer to compiler-rt, but there have been a few other changes in the last week or so that may be related). I'm building with a fresh top-of-tree clang and setting -DLLVM_USE_SANITIZER=Address

> On Aug 24, 2017, at 2:55 PM, Kostya Serebryany <kcc at google.com> wrote: > > Interesting. > This is a relatively new addition (fsanitize-coverage=pc-tables, which is now a part of -fsanitize=fuzzer). > The tests worked (did they? On Mac?) so I thought everything is ok. For tests we never compile the tested target with -O3 (and that wouldn’t be sufficient), and for

I think the simplest fix is something like this: diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp index c6f0d17f8fe..e81957ab80a 100644 --- a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp +++ b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp @@ -256,6 +256,7 @@ SanitizerCoverageModule::CreateSecStartEnd(Module

On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Aug 24, 2017 at 3:20 PM, Justin Bogner <mail at justinbogner.com> > wrote: > >> I think the simplest fix is something like this: >> >> diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp >>

On Thu, Mar 17, 2016 at 11:45 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote: > On Thu, Mar 17, 2016 at 10:05 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote: >> On Mon, Mar 14, 2016 at 5:30 PM, Chris Bieneman <cbieneman at apple.com> wrote: >> [ brutal-snip ] >> ... >>> [ TODO#S: Before doing a 2nd build (and in a 3rd run using more >>>

Hey, So in Fedora rawhide we are now building llvm 3.7.1 into the lots of little shared libraries format. However I'm running into a major problem with the fact that sometimes dlclose isn't dropping all the LLVM libraries from the address space of the process. We have a sequence like this: a) X server asks mesa gbm library to init, it loads the kms_swrast_dri.so with

No, it has the wrong value. I tried it with cmake 2.8.9 and 2.8.12.2. Both of them set the variable to “.so”. On Feb 12, 2014, at 5:29 PM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Juergen, > > Thanks to let me know. I guess r200762 (and r200763) might affect. > > Although I won't check this on darwin box, I suspect the line in > HandleLLVMOptions.cmake;

Hi Takumi, I am not sure if it this change, but recently we started to build LLVMHello.so and BugpointPasses.so on OS X. A few bugpoint tests are failing, because they are looking for a dylib that doesn’t exist. Could you please take a look? Thanks -Juergen On Feb 10, 2014, at 2:34 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Steve, excuse me to respond you partially. >

On Thu, Aug 24, 2017 at 3:38 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Thu, Aug 24, 2017 at 3:35 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>> On Thu, Aug 24, 2017 at 3:20

Hi, I have a dynamically loaded llvm pass built in-tree with ninja (generated with cmake, basically a copy of the hallo pass plugin, linux, llvm/clang version 6.0.1). It uses the ExecutionEngine. Building it without linking against LLVMExecutionEngine library results in an undefined symbol to the vtable of the EngineBuilder when loaded to opt. Linking the plugin with LLVMExecutionEngine results in

On Thu, Aug 24, 2017 at 6:30 PM, Justin Bogner <mail at justinbogner.com> wrote: > Peter Collingbourne <peter at pcc.me.uk> writes: > > On Thu, Aug 24, 2017 at 3:38 PM, Kostya Serebryany <kcc at google.com> > wrote: > > > >> > >> > >> On Thu, Aug 24, 2017 at 3:35 PM, Peter Collingbourne <peter at pcc.me.uk> > >> wrote:

I'm getting this link failure when running ninja check on Linux. I'm configuring with shared libraries enabled, so I'm not sure why asan is looking for .a archives. $ cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DLLVM_BUILD_TESTS=ON -DCLANG_INCLUDE_DOCS=ON -DBUILD_SHARED_LIBS=ON ../llvm $ ninja check-all FAILED: cd [..]bld/projects/compiler-rt/lib/asan/tests &&

Kostya Serebryany <kcc at google.com> writes: > Justin, > Calling appendToUsed has horrible complexity and if we call it in > every function clang consumes tons of memory (6Gb when compiling one > of the clang's source files). This killed my machine today :) > > The solution is to call appendToUsed once per module, instead of once > per function. Oh right,

AFAICT we traditionally only support building llvm/clang with the 2 most recent releases of Visual Studio. With the release of VS2019, what do people think of retiring VS2015 support before the next major llvm/clang release? As well as simplifying C++14 migration (admittedly only a little), this should also let us remove a number of hacks (e.g. the alignas/AlignedCharArray hack in

Hi, I have a debug build with shared libraries (to reduce compilation time), but since yesterday, it's failing with an ExecutionEngine error: FAILED: : && /usr/lib/ccache/bin/c++ -fPIC -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wno-comment -std=c++11

*System:* Debian Linux Sid/Unstable amd64 *LLVM/Clang:* Trunk *Scenario:* In the past couple of days I've been compiling against trunk I get two separate and spurious hang ups with CMake. *Note:* I build against more than just X86 follow along the progress of other platforms, though just building for X86 produces the same results below. *Assumption:* Configure cmake with prior built