similar to: [cfe-dev] [3.8 Release] We have branched

Hi, The test-suite expects to be built standalone but it looks like you have it in the same tree as LLVM. You'll need to remove it. From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Peter Teoh via llvm-dev Sent: 28 February 2016 14:31 To: llvm-dev at lists.llvm.org Subject: [llvm-dev] [cfe-dev] [3.8 Release] We have branched With reference to the following thread:

I think we've just forgotten to update that part of the instructions. Having the test-suite at projects/test-suite was harmless to the old autoconf and LLVM 3.7.x's cmake builds because it didn't actually cause the test-suite to be built. The CMakeLists.txt that have been added to the test-suite now cause it to be built by LLVM's build system which introduces the build failure. We

Hi everyone, (Sorry if I'm asking at the wrong mail listing, but compiler-rt page tells I'd better write on llvm-dev rather than cfe-dev/cfe-users.) I've just built LLVM/Clang+Compiler-rt (Compiler-rt is put inside llvm/projects folder) and tried the -fsanitize option. But strangely the link failed since it cannot find *libclang_rt.san-x86_64.a*. The error message is as

Trying to run a self host "ninja check-clang" with ASan enabled I hit a /lot/ of errors like this (strangely I hit none of these in check-llvm, only in check-clang): Any ideas? ==10525==ERROR: AddressSanitizer failed to deallocate 0x10800 (67584) bytes at address 0x631000014800 ==10525==AddressSanitizer CHECK failed:

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 > optimized binaries) ] > > How do I anable LTO via CMAKE? > > > LLVM_ENALBLE_LTO=On > [ v4 of my build-script attached ] Hi Chris, thanks for the response! That seems to work (see below). $ cd

I wish there was something like the line in config.log that would show the CMake command, but instead I can at least show you the CMakeCache files for my release build and asan build (attached to this email). No lld, so far as I know - believe I'm using gold at the moment for both builds. Did just reproduce this with a clean release build and a clean asanified build from that. Same errors. I

X32 support patch for compiler-rt. Applies against current trunk. --- projects/compiler-rt/make/platform/clang_linux.mk~ 2013-08-21 06:27:38.000000000 +0000 +++ projects/compiler-rt/make/platform/clang_linux.mk 2013-08-21 11:16:55.891621025 +0000 @@ -41,7 +41,18 @@ SupportedArches += x86_64 endif else - SupportedArches := x86_64 + # x86-64 arch has two ABIs 64 bit x86-64 and 32 bit

Clang patch for X32 support. Applies against current trunk. --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6 backward compatibility">; def m3dnowa : Flag<["-"], "m3dnowa">,

Hi, All I have tried to compile and install LLVM on windows 8 using Visual Studio Express 2013 for Windows Desktop. The compiling is fine. However, the installing gives the following errors: 62> CMake Error at projects/compiler-rt/lib/asan/cmake_install.cmake:34 (FILE): 62> file INSTALL cannot find 62>

Hello, when I build llvm from git source, some errors occured. 80>asan_new_delete.obj : error LNK2019: unresolved external symbol "void * __cdecl MemalignFromLocalPool(unsigned __int64,unsigned __int64)" (?MemalignFromLocalPool@@YAPEAX_K0 at Z)， "void * __cdecl operator new(unsigned __int64)" (??2 at YAPEAX_K@Z)

Hi, I'm working on bringing up complete coverage for a Gentoo x32 "desktop" system. I've been cooking up quite a few patches for various packages to push upstream, but right now, the biggest blocker is the lack of support for building with/codegen targeting x32 in llvm/clang. Since the x32 patches were sent last year, I see support code has landed in LLVM, and basic handling of

I assume you are using Visual Studio as your build tool? The LLVM project set turns into a bunch of Visual Studio project files, and my experience has been that they do not always coordinate correctly. Often just running the build again will solve a problem like this. I'm not really familiar with the sanitizers so I don't have any ideas about the specific error, if re-running the build

I used to build llvm/clang on windows a lot, and never had any issues. But I never built asan on windows, maybe asan just doesn't build on windows? On Tue, Mar 12, 2019 at 7:14 PM mirchd via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I am using Visual Studio 2017, > I re-running cmake and rebuild the project but it still has the unresolved link error. > > thanks

Hi, Currently the first stage ("run sanitizer tests in gcc build") of the sanitizer-ppc64-linux1 buildbot is only failing because of: + cd clang_build + make -j16 check-lsan make: *** No rule to make target `check-lsan'. Stop. + echo @@@STEP_FAILURE@@@ @@@STEP_FAILURE@@@ + cd clang_build + make -j16 check-msan make: *** No rule to make target `check-msan'. Stop. + echo

How about tweaking the compiler-rt cmakefiles so that if lsan is not supported, the target check-lsan still exists but does nothing? I've attached a patch that does this. (I don't know much about cmake so there might be a better way of doing it.) Alternatively, can I change the zorg build script so that "run sanitizer tests in gcc build" doesn't try to run check-lsan etc

On 06/06/2014 02:33, Alexey Samsonov wrote: > Hi Alp, > > This warning should be fixed by r210301. However, consider > investigating why the frame size appears to be that large. I believe > we build this code with GCC as well and have seen no complaints > from its implementation of -Wframe-larger-than. CC'ing in llvmdev. Like Chandler said it could just be due to lack of

Hi, The actual location is in C:/llvm/build/Release/lib/clang/3.5.0/lib/windows/Release/clang_rt.asan-i386.lib which just replaces $(Configuration) as Release. Thanks On Wed, Mar 5, 2014 at 11:56 PM, Alexey Samsonov <samsonov at google.com>wrote: > +Brad > Brad, do you think we should fix add_compiler_rt_static_runtime for > multi-configuration generators > in the same way

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 &&

On Thu, Feb 6, 2014 at 7:57 PM, Jean-Daniel Dupas <devlists at shadowlab.org>wrote: > > Le 6 févr. 2014 à 16:20, Brad King <brad.king at kitware.com> a écrit : > > > On 02/06/2014 08:12 AM, Alexey Samsonov wrote: > >> Please note that it makes a lot of sense to built compiler-rt (and > sanitizers) with just-built > >> Clang. In fact, even though we