similar to: Use of host/target compiler when building compiler-rt

On Wed, Mar 8, 2017 at 2:03 PM Sterling Augustine <saugustine at google.com> wrote: > Yes, this is a aspect of the larger problem that clang bootstrap doesn't > work for a cross-compiler. The build (mostly?) assumes that host==target > during the build of clang itself, and then if you want another architecture > also, you run a second build of the target libraries, and

On 03/08/2017 04:55 PM, Chris Bieneman via llvm-dev wrote: > David, > > This is an area that has had a lot of development over the last two years. > > There are two supported ways in the LLVM build system to build > compiler-rt with the just-built compiler. > > 1) The legacy way is for if compiler-rt is under LLVM/projects. You > can specify

On Wed, Mar 8, 2017 at 2:55 PM Chris Bieneman <beanz at apple.com> wrote: > David, > > This is an area that has had a lot of development over the last two years. > > There are two supported ways in the LLVM build system to build compiler-rt > with the just-built compiler. > > 1) The legacy way is for if compiler-rt is under LLVM/projects. You can > specify

On Wed, Mar 8, 2017 at 3:23 PM Chris Bieneman <beanz at apple.com> wrote: > On Mar 8, 2017, at 3:16 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Mar 8, 2017 at 2:55 PM Chris Bieneman <beanz at apple.com> wrote: > > David, > > This is an area that has had a lot of development over the last two years. > > There are two supported

On Thu, Mar 9, 2017 at 11:25 AM Chris Bieneman <beanz at apple.com> wrote: > On Mar 8, 2017, at 4:42 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Mar 8, 2017 at 3:23 PM Chris Bieneman <beanz at apple.com> wrote: > > On Mar 8, 2017, at 3:16 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Mar 8, 2017 at

On Thu, Mar 9, 2017 at 3:00 PM Chris Bieneman <beanz at apple.com> wrote: > I'll try and reproduce later today. Is this Linux? Can you give me your > CMake command line? > Excuse the delay, been busy setting up a new machine - also an opportunity to try clean cmake setups rather than my aging configurations that have a bunch of old stuff baked in and manual variables changed,

Hi, I'm building compiler-rt in a ppc64le machine and it is generating the sanitizers fine but it is not generating the builtin library. I tried to compile it in a x86_64 machine and I got the builtin library generated (libclang_rt.builtins-x86_64.a). Taking a look in a cmake config file from compiler-rt, I saw that ppc64 is not in the supported architecture list to generate the builtin

So I stumbled across an issue that I think is a bit fundamental: The xray runtime uses the C++ standard library. This seems like a problem because whatever C++ standard library is used to compile the XRay runtime may not be the same as the C++ standard library (if any) that is used to build the target application and link XRay into. Does this make sense? Is this a problem? Talking to Chandler

> On Mar 8, 2017, at 3:14 PM, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Mar 8, 2017, at 3:08 PM, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote: >> >> >> On 03/08/2017 04:55 PM, Chris Bieneman via llvm-dev wrote: >>> David, >>> >>> This is an area that has had a lot

Evgeniy, I'm getting this error while building on ARM: clang (LLVM option parsing): Unknown command line argument '-asan-instrument-assembly'. Try: 'clang (LLVM option parsing) -help' clang (LLVM option parsing): Did you mean '-asan-instrument-atomics'? [6/32] Generating ASAN_INST_TEST_OBJECTS.asan_asm_test.cc.arm-inline.o This doesn't happen on x86_64, so

I am trying to build compiler-rt on a x86_64 machine using clang. Command used: CC=clang CXX=clang++ cmake <path to compiler-rt> -DLLVM_CONFIG_PATH=<Path to llvm toolchain>/bin/llvm-config -DCOMPILER_RT_INSTALL_PATH=<Path to llvm toolchain>/lib/clang/3.7.0 after this command on console it prints, -- Compiler-RT supported architectures: x86_64 Instead if I use gcc in above

Hi Evgeniy, I just created a new buildbot that compiles and tests compiler-rt together with LLVM/Clang using the CMake build: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/0 There are a few ASan failures and I'd like to check with you which of them are real failures that we need to fix and which are just unsupported / noise. These tests are running on an ARMv7

On Sun, May 26, 2013 at 12:17 AM, Evgeniy Stepanov < eugeni.stepanov at gmail.com> wrote: > On Sat, May 25, 2013 at 4:12 AM, Greg Fitzgerald <garious at gmail.com> > wrote: > > When I build compiler-rt with clang 3.2, all lsan tests pass. The only > > failing tests I see are in ubsan: > > > > Failing Tests (6): > > UndefinedBehaviorSanitizer ::

UBsan tests work for me when I run "check-ubsan" in both build trees (the one with gcc 4.6.3 as a host compiler, and the one with fresh Clang). It's pretty convenient for us to use fresh Clang to configure LLVM and compiler-rt. One major reason is that autoconf/make build system always builds compiler-rt with just-built Clang. There are other benefits, like keeping sanitizers code

> Android runtime is special, we build it in a separate build tree configured with > -DCMAKE_TOOLCHAIN_FILE=$LLVM_CHECKOUT/cmake/platforms/Android.cmake This worked great, thanks! Would you mind tweaking Android.cmake so that I can override the location of the C compiler? The current version forces me to use the just-built-clang and that the new build directory be in a sibling directory.

On Sat, May 25, 2013 at 4:12 AM, Greg Fitzgerald <garious at gmail.com> wrote: > When I build compiler-rt with clang 3.2, all lsan tests pass. The only > failing tests I see are in ubsan: > > Failing Tests (6): > UndefinedBehaviorSanitizer :: Float/cast-overflow.cpp > UndefinedBehaviorSanitizer :: Integer/add-overflow.cpp > UndefinedBehaviorSanitizer ::

On Wed, May 29, 2013 at 5:40 PM, Greg Fitzgerald <garious at gmail.com> wrote: > For me, UBsan fails with clang 3.2 and passes with clang 3.3. > Cool, can you use clang 3.3 then? :) I think that the reason selected UBSan tests fail under clang 3.2 is a bug in Clang, which was fixed (Richard may correct me if I'm wrong). I don't really want to mark these tests as "failing

For me, UBsan fails with clang 3.2 and passes with clang 3.3. Using a fixed version allows you to build all clang/llvm/compiler-rt with one compiler. It simplifies the build process quite a bit. Also better for isolating regressions in compiler-rt, especially if you use git-bisect. Greg On May 29, 2013, at 12:30 AM, Alexey Samsonov <samsonov at google.com> wrote: > UBsan tests work

On Wed, Mar 8, 2017 at 2:28 PM Tim Shen <timshen at google.com> wrote: > On Wed, Mar 8, 2017 at 1:49 PM David Blaikie <dblaikie at gmail.com> wrote: > > So I stumbled across an issue that I think is a bit fundamental: > > The xray runtime uses the C++ standard library. > > This seems like a problem because whatever C++ standard library is used to > compile the

On Thu, May 30, 2013 at 3:40 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > Cool, can you use clang 3.3 then? :) > > I can, but digging deeper I see that the compiler-rt sanitizer tests > depend on just-built-clang for its object instrumentation. The next time > the instrumentation changes, I'd expect those tests to break. If the lit > tests that require