similar to: [LLVMdev] r204593 breaks Asan tests on FreeBSD

On Tue, Apr 1, 2014 at 1:23 PM, Ivan A. Kosarev <ivan at ivan-labs.com> wrote: > Hi Alexey, > > > On 03/31/2014 09:58 PM, Alexey Samsonov wrote: > > On FreeBSD 9.2 I add a couple custom options to CMAKE_CXX_FLAGS in order > to let clang know which header set it should use, like that: > >> >>> CC=clang CXX=clang++ cmake \ >>>

Submitted r204593. On Sun, Mar 23, 2014 at 10:03 PM, Alexey Samsonov <samsonov at google.com>wrote: > Hi Dmitri, > > On Sat, Mar 22, 2014 at 11:50 PM, Dmitri Gribenko <gribozavr at gmail.com>wrote: > >> Hello, >> >> It looks like compiler-rt CMake scripts don't take CMAKE_CXX_FLAGS >> into account. This is because clang_compile and

Hello, It looks like compiler-rt CMake scripts don't take CMAKE_CXX_FLAGS into account. This is because clang_compile and clang_link_shared functions call the newly-built compiler directly, and they don't add those flags. Using CMAKE_CXX_FLAGS is necessary on systems where the C++11-enabled libstdc++ is installed not in the default location. For example, the CentOS buildbot uses:

Hello Alexey, I just worked out the config for the FreeBSD 9.2 buildbot (follows below). One important thing about this config is that the C++11 headers are set up at the /usr/include/c++/v1 directory--it's where clang expects them to be on FreeBSD, so no need for the "-I" options in the CMAKE_CXX_FLAGS variable. Unfortunately, clang (both v3.3 used to be the default compiler

This is just for compiler-rt. The reason for having -fno-omit-frame-pointer is that tools like https://perf.wiki.kernel.org/index.php/Main_Page would work on ASAN binaries. Adrian On Mon, Jul 20, 2015, at 02:23 PM, adek at adek.io wrote: > Hey, > > Thanks for ideas. I tried them on, but none of them succeeded. > > If I remove this line: >

I regularly use '-DCMAKE_CXX_FLAGS' when configuring CLang/LLVM to distinguish my builds (Alpha/Beta/Final) or to build custom versions, usually by adding additional '-D' flags, but I discovered I had to add the ':STRING' qualifier to it when invoking 'cmake'. With 'gmake' this is equivalent to '--with-extra-options="whatever flags":

Hey Pete, I also tried CMAKE_CXX_FLAGS_RELEASE with the same effect. On Mon, Jul 20, 2015, at 09:34 AM, Pete Cooper wrote: > Hi Adrian > > I’m not sure if the CMAKE_CXX_FLAGS is used in LLVM. We have our own > flags for different configurations. I don’t remember if our ones inherit > from CMAKE_CXX_FLAGS or override it completely. Anyway, they are: > - CMAKE_CXX_FLAGS_DEBUG

On Thu, Apr 3, 2014 at 5:04 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > we would still want to use compiler-rt test-suite in a standalone mode, > to test fully built/installed toolchains, > and even GCC. > > Sounds good. > > > > Clang driver links the static xsan runtimes from a hardcoded > > paths in Clang resource directory, and doesn't

On Thu, Apr 3, 2014 at 9:23 PM, Greg Fitzgerald <garious at gmail.com> wrote: > > I don't think it's a good idea to let user hijack > > the driver and stuff in custom version of > > ASan runtime instead the one installed/built > > with compiler :) > > I'm okay with it. This is open source. If someone wants to put the > sanitizers on a shorter

Hi Greg, On Wed, Apr 2, 2014 at 2:50 AM, Greg Fitzgerald <garious at gmail.com> wrote: > Alexey, Evgeniy, > > I propose the following steps to unify multi-arch support in compiler-rt: > > 1) The compiler-rt test suite adds "-L${CMAKE_CURRENT_BINARY_DIR}/lib" > to its 'clang' variables. This way we can test the sanitizers without > installing any libs

Alexey, >> Some good news, the drivers (both gcc and clang) allow us to put the >> '-L' parameters after the '-l' parameters. I made these changes locally and it went really well. The patch to clang is quite small and only one unit-test needed updating. In compiler-rt, I updated the flags passed to clang to include a '-L${COMPILER_RT_BINARY_DIR}/lib' and

> First of all, sorry for the late response (I'm in the process of moving to California). Welcome! > We need to verify that simple command "clang -fsanitize=address foo.cc" works Agreed. The test suite is useful in many different scenarios: 1) Verifying the integrated clang. 2) Verifying the integrated gcc. 3) Verifying the libraries during development. I'm working

llvm/cmake/modules/HandleLLVMStdlib.cmake specifies "-stdlib=libc++" for CMAKE_CXX_FLAGS when LLVM_ENABLE_LIBCXX and CXX_SUPPORTS_STDLIB. From what I can see this is a flag intended for the linker and not the compiler. I'd like to submit a change to delete CMAKE_CXX_FLAGS from this append() but I wanted to check in with the list to see if that makes sense or if there are other

On Tue, Feb 5, 2013 at 12:38 PM, Kostya Serebryany <kcc at google.com> wrote: > +samsonov, glider > > > On Tue, Feb 5, 2013 at 12:16 PM, Chandler Carruth <chandlerc at google.com>wrote: > >> On Mon, Feb 4, 2013 at 6:21 AM, Erik Verbruggen <erik.verbruggen at me.com>wrote: >> >>> Hi Chandler, >>> >>> If I remember correctly,

On Mon, Feb 4, 2013 at 6:21 AM, Erik Verbruggen <erik.verbruggen at me.com>wrote: > Hi Chandler, > > If I remember correctly, you are the de-facto maintainer for the > CMake-built-mainainer, so..: > Sure, but I'm often busy. You're better off using the development mailing list for questions such as this, and I've moved the conversation there. > I have a

Hi Timo: You need to find LLVMConfig.cmake in the binary or install directory tree, not the source tree. Although I don't embed clang/llvm, my config might help you figure it -- clang/llvm installed under (could have used build directory) ~/usr : $ cd /Users/dhinton/projects/cover/build/ && rm -rf * && CC=~/usr/bin/clang CXX=~/usr/bin/clang++ LLVM_DIR=~/usr/lib/cmake/llvm

'-DCMAKE_CXX_FLAGS=-fno-omit-frame-pointer -Wno-maybe-uninitialized -fPIC -fPIE' -- The C compiler identification is GNU 4.8.1 -- The CXX compiler identification is GNU 4.8.1 -- Check for working C compiler: /home/engshare/third-party2/gcc/4.8.1/centos6-native/cc6c9dc/bin/gcc -- Check for working C compiler: /home/engshare/third-party2/gcc/4.8.1/centos6-native/cc6c9dc/bin/gcc -- works --

It does sound like Android is better suited for "honest" cross-compilation, rather than "build compiler-rt for all targets we can find" model. I'm still not convinced that we must require the "ninja install" step. Could we just "ninja clang" and then build the second stage against the first stage build directory? Will this "find_package" thing

+samsonov, glider On Tue, Feb 5, 2013 at 12:16 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Mon, Feb 4, 2013 at 6:21 AM, Erik Verbruggen <erik.verbruggen at me.com>wrote: > >> Hi Chandler, >> >> If I remember correctly, you are the de-facto maintainer for the >> CMake-built-mainainer, so..: >> > > Sure, but I'm often busy.

Sorry my example wasn't helpful. I did take a quick look at rust -- though I didn't download or try to build it -- and they seem to allow you to use an installed or prebuilt version in addition to building it in-tree. However, even when they build it in-tree, they build the whole thing -- see mk/llvm.mk. Good luck... On Mon, Oct 10, 2016 at 1:33 AM, Timo Janssen via llvm-dev <