search for: handlellvmoptions

...ripping 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: > > diff --git a/cmake/modules/HandleLLVMOptions.cmake b/cmake/modules/HandleLLVMOptions.cmake > index 04596a6ff63..5465d8d95ba 100644 > --- a/cmake/modules/HandleLLVMOptions.cmake > +++ b/cmake/modules/HandleLLVMOptions.cmake > @@ -665,6 +665,9 @@ if(LLVM_USE_SANITIZER) > endif() > if (LLVM_USE_SANITIZE_COVERAGE) >...

(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

...; > 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: > > > > diff --git a/cmake/modules/HandleLLVMOptions.cmake b/cmake/modules/HandleLLVMOptions.cmake > > index 04596a6ff63..5465d8d95ba 100644 > > --- a/cmake/modules/HandleLLVMOptions.cmake > > +++ b/cmake/modules/HandleLLVMOptions.cmake > > @@ -665,6 +665,9 @@ if(LLVM_USE_SANITIZER) > > endif() > > if (LLVM_U...

...>>> > 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: >>> > >>> > diff --git a/cmake/modules/HandleLLVMOptions.cmake >>> b/cmake/modules/HandleLLVMOptions.cmake >>> > index 04596a6ff63..5465d8d95ba 100644 >>> > --- a/cmake/modules/HandleLLVMOptions.cmake >>> > +++ b/cmake/modules/HandleLLVMOptions.cmake >>> > @@ -665,6 +665,9 @@ if(LLVM_USE_SANITIZER)...

...KE_BUILD_TYPE=Release >> -DCMAKE_INSTALL_PREFIX=../install -DCMAKE_C_FLAGS=-mcpu=cortex-a15 >> -DCMAKE_CXX_FLAGS=-mcpu=cortex-a15 -DLLVM_TARGETS_TO_BUILD=ARM >> -DLLVM_BUILD_TESTS=True -DLLVM_ENABLE_ASSERTIONS=True >> >> Warning: >> CMake Warning at cmake/modules/HandleLLVMOptions.cmake:117 (message): >> -fPIC is not supported. >> Call Stack (most recent call first): >> cmake/modules/HandleLLVMOptions.cmake:150 (add_flag_or_print_warning) >> CMakeLists.txt:286 (include) >> >> Error log: >> Run Build Command:/usr/local/bin/ninja...

...h the move to compiler-rt, so I’m >> >>> > quite skeptical on whether it has worked >> >>> > beforehand. >> >>> > >> >>> > A trivial fix is to do: >> >>> > >> >>> > diff --git a/cmake/modules/HandleLLVMOptions.cmake >> >>> b/cmake/modules/HandleLLVMOptions.cmake >> >>> > index 04596a6ff63..5465d8d95ba 100644 >> >>> > --- a/cmake/modules/HandleLLVMOptions.cmake >> >>> > +++ b/cmake/modules/HandleLLVMOptions.cmake >> >>> &g...

...ere not used by the project: > > LLVM_ENABLE_LTO > > > -- Build files have been written to: > /home/wearefam/src/llvm-toolchain/llvm-build > > Do you need more input? > > Thanks! > I found in "http://llvmweekly.org/issue/110" [ llvm.src/cmake/modules/HandleLLVMOptions.cmake ] option(LLVM_ENABLE_LTO "Enable link-time optimization" OFF) append_if(LLVM_ENABLE_LTO "-flto" CMAKE_CXX_FLAGS CMAKE_C_FLAGS CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS) Searching for... $ grep LLVM_ENABLE_LTO llvm/cmake/modules/HandleLLVMOptions.cmake [ OUTPUT EM...

...: $ CC=clang CXX=clang++ cmake -G Ninja ../src/ -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=../install -DCMAKE_C_FLAGS=-mcpu=cortex-a15 -DCMAKE_CXX_FLAGS=-mcpu=cortex-a15 -DLLVM_TARGETS_TO_BUILD=ARM -DLLVM_BUILD_TESTS=True -DLLVM_ENABLE_ASSERTIONS=True Warning: CMake Warning at cmake/modules/HandleLLVMOptions.cmake:117 (message): -fPIC is not supported. Call Stack (most recent call first): cmake/modules/HandleLLVMOptions.cmake:150 (add_flag_or_print_warning) CMakeLists.txt:286 (include) Error log: Run Build Command:/usr/local/bin/ninja cmTryCompileExec3815591925 [1/2] Building C object CMakeFiles...

...h 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; > > set(LLVM_PLUGIN_EXT ${CMAKE_SHARED_MODULE_SUFFIX}) > > Does it have expected value? > > 2014-02-13 10:11 GMT+09:00 Juergen Ributzka <juergen at apple.com>: >> Hi Takumi, >> >> I am not sure if it this change, but recently we started to build...

...t; >>> > quite skeptical on whether it has worked >>>> >>> > beforehand. >>>> >>> > >>>> >>> > A trivial fix is to do: >>>> >>> > >>>> >>> > diff --git a/cmake/modules/HandleLLVMOptions.cmake >>>> >>> b/cmake/modules/HandleLLVMOptions.cmake >>>> >>> > index 04596a6ff63..5465d8d95ba 100644 >>>> >>> > --- a/cmake/modules/HandleLLVMOptions.cmake >>>> >>> > +++ b/cmake/modules/HandleLLVMOption...

...() >> endif() >> >> >> CMake provides CMAKE_SHARED_MODULE_SUFFIX and CMAKE_IMPORT_LIBRARY_SUFFIX. >> Can you set those at directory scope instead of setting the target property >> in the macro? > > Reasonable. They could be put into common configurator, HandleLLVMOptions. > For now in r201072, I simply gather common logics around there. > I'd be happy if llvm_add_library became simpler, and I will work on. > >> Anyway, just a note to consider moving instead in a direction of fewer >> wrappers, rather than more. I'm not familiar enough...

...er it has worked > >>>>> >>> > beforehand. > >>>>> >>> > > >>>>> >>> > A trivial fix is to do: > >>>>> >>> > > >>>>> >>> > diff --git a/cmake/modules/HandleLLVMOptions.cmake > >>>>> >>> b/cmake/modules/HandleLLVMOptions.cmake > >>>>> >>> > index 04596a6ff63..5465d8d95ba 100644 > >>>>> >>> > --- a/cmake/modules/HandleLLVMOptions.cmake > >>>>> >>> >...

...t;>> >>> > beforehand. >>> >>>>> >>> > >>> >>>>> >>> > A trivial fix is to do: >>> >>>>> >>> > >>> >>>>> >>> > diff --git a/cmake/modules/HandleLLVMOptions.cmake >>> >>>>> >>> b/cmake/modules/HandleLLVMOptions.cmake >>> >>>>> >>> > index 04596a6ff63..5465d8d95ba 100644 >>> >>>>> >>> > --- a/cmake/modules/HandleLLVMOptions.cmake >>> >&gt...

...e 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 AlignOf.h), as well as re-enabling a number of warnings in HandleLLVMOptions.cmake. I haven't noticed any build bots still referring to VS2015 (at least not by name). Simon.

...s.llvm.org> wrote: Hi, since recently I'm getting linker failures in debug builds. The root cause is that -fvisibility-inlines-hidden causes inline functions in explicit template instantiations to become hidden in certain cases. The following hunk works around this... --- a/cmake/modules/HandleLLVMOptions.cmake +++ b/cmake/modules/HandleLLVMOptions.cmake @@ -159,7 +159,13 @@ endif() if(NOT WIN32 AND NOT CYGWIN) # MinGW warns if -fvisibility-inlines-hidden is used. check_cxx_compiler_flag("-fvisibility-inlines-hidden" SUPPORTS_FVISIBILITY_INLINES_HIDDEN_FLAG) - append_if(SUPPORTS_FV...

...sed-parameter -Wwrite-strings -pedantic -Wno-long-long -Wcovered-switch-default -fno-exceptions -o CMakeFiles/LLVMSupport.dir/regcomp.c.o -c /Users/jabbey/src/llvmCommit/lib/Support/regcomp.c cc1: error: unrecognized command line option "-Wcovered-switch-default" The problem stems from HandleLLVMOptions.cmake where a single check of the warning option is performed using check_cxx_compiler_flag, and then upon success add_llvm_definitions appends to the flag to a list consumed by both C and CXX compilers. Attached is a patch which updates HandleLLVMOptions.cmake to: - Test C and CXX compiler sepa...

...1 deletion(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index bb70f15..e327427 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -249,7 +249,7 @@ set(LLVM_DEFAULT_TARGET_TRIPLE "${LLVM_HOST_TRIPLE}" CACHE STRING set(TARGET_TRIPLE "${LLVM_DEFAULT_TARGET_TRIPLE}") include(HandleLLVMOptions) - +set(Python_ADDITIONAL_VERSIONS 2.7 2.6 2.5 2.4) # Verify that we can find a Python interpreter, include(FindPythonInterp) if( NOT PYTHONINTERP_FOUND ) -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo

...install >>>> -DCMAKE_C_FLAGS=-mcpu=cortex-a15 -DCMAKE_CXX_FLAGS=-mcpu=cortex-a15 >>>> -DLLVM_TARGETS_TO_BUILD=ARM -DLLVM_BUILD_TESTS=True >>>> -DLLVM_ENABLE_ASSERTIONS=True >>>> >>>> Warning: >>>> CMake Warning at cmake/modules/HandleLLVMOptions.cmake:117 (message): >>>> -fPIC is not supported. >>>> Call Stack (most recent call first): >>>> cmake/modules/HandleLLVMOptions.cmake:150 (add_flag_or_print_warning) >>>> CMakeLists.txt:286 (include) >>>> >>>> Error log:...

...I was having troubles building LLVM with Polly in-tree using CMake with LLVM_BUILD_32_BITS on. Turns out CMake considers LLVMPolly a module, not a shared library, and LLVM_BUILD_32_BITS only makes provisions for the EXE and SHARED linker flags. Possible fixes (pick one): 1. Change cmake/modules/HandleLLVMOptions.cmake to append -m32 to CMAKE_MODULE_LINKER_FLAGS as well if LLVM_BUILD_32_BITS is set. 2. Change $POLLY/CMakeLists.txt not to use MODULE in add_polly_library. Should I make an entry in Bugzilla about this or is a post to the mailing list sufficient? I confess I'm not very familiar with the or...

...rings -pedantic -Wno-long-long -Wcovered-switch-default > -fno-exceptions -o CMakeFiles/LLVMSupport.dir/regcomp.c.o -c > /Users/jabbey/src/llvmCommit/lib/Support/regcomp.c > cc1: error: unrecognized command line option "-Wcovered-switch-default" > > The problem stems from HandleLLVMOptions.cmake where a single check of the > warning option is performed using check_cxx_compiler_flag, and then upon > success add_llvm_definitions appends to the flag to a list consumed by both > C and CXX compilers. > > Attached is a patch which updates HandleLLVMOptions.cmake to: > -...