similar to: Unit Tests CMake configuration

Hi Dean, For me the build is still broken: -- Builtin supported architectures: i386;x86_64;x86_64h CMake Error at projects/compiler-rt/lib/xray/tests/CMakeLists.txt:21 (add_library): add_library cannot create target "RTXRay.test.osx" because another target with the same name already exists. The existing target is a static library created in source directory

Hi Dean, I have fixed the build failure in r329832. In general, do you think it would be possible to perform the task using higher-level functions available from AddCompilerRT.cmake? They were written exactly to avoid such errors. Regards, George > On Apr 11, 2018, at 10:50 AM, George Karpenkov <ekarpenkov at apple.com> wrote: > > Hi Dean, > > For me the build is still

On Sat, 3 Jun 2017 16:04:57 -0700 Tim Northover <t.p.northover at gmail.com> wrote: [snip] > I think you should be able to fix it by changing the > compiler-rt/lib/xray/test/CMakeLists.txt. If you find the > "add_compiler_rt_test" call and move "-lstdc++" to the end, just after > "-lrt" it should work. Thanks, Tim. I don't see "-lrt":

> On 4 Oct 2017, at 04:43, Chris Bieneman <beanz at apple.com> wrote: > > I want to make sure I understand the problem so I can try to reproduce it. > > When you say "make changes to the runtime" you mean code in compiler-rt/lib/xray ? > Yes. > Are you using the mono-repo prototype? If not, where do you have compiler-rt's sources (llvm/projects or

Hi llvm-dev, I have unit tests set up in the XRay implementation (compiler-rt/lib/xray/tests/unit) following the pattern that the TSAN and other sanitiser unit tests. However, I'm running into the following problem: When I make changes to the runtime (in this case, XRay) and do `ninja all check-xray`, it seems that the unit tests don't get re-liked to the new version of the runtime. It

All temporary files are kept in a single directory. At the end of the autotests that one directory is deleted. Signed-off-by: Darryl L. Pierce <dpierce at redhat.com> --- autotest.sh | 20 +++++++++++--------- 1 files changed, 11 insertions(+), 9 deletions(-) diff --git a/autotest.sh b/autotest.sh index c9f8a2d..d658cf3 100755 --- a/autotest.sh +++ b/autotest.sh @@ -40,6 +40,7 @@ # an

I tried the new cmake-based build system to build Opus on Linux and macOS. I'm not familiar with cmake but based on instructions I found online I used it as follows: - mkdir build - cd build - cmake -DCMAKE_INSTALL_PREFIX:PATH=<install-path> .. - make - ctest - make install Although the "make" command completed, it reported that optimizations were disabled:

Aside: would it be useful to execute a build of the libc++/libc++abi with msan normally during release, and change the driver to look for these msan-built C++ libs when "-fsanitize=memory"? That would drastically cut down on the complexity of using msan. On Fri, Aug 31, 2018 at 5:43 AM Dean Michael Berris via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks Vitaly and

Another option is just to run corresponding script from *https://llvm.org/svn/llvm-project/zorg/trunk/zorg/buildbot/builders/sanitizers/ <https://llvm.org/svn/llvm-project/zorg/trunk/zorg/buildbot/builders/sanitizers/>* in empty directory. On Thu, Aug 30, 2018 at 5:00 AM Peter Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Dean, > > I've not done this

Hi, I am trying to build the LLVM suite on a RedHat Enterprise Linux clone (Scientific Linux <https://www.scientificlinux.org/>). In the latest attempt, the build seems to complete without any explicit failures but the `check-all` process fails. Any ideas about what is wrong or suggestions for how to proceed would be much appreciated. This is the current procedure: sudo yum install

Hi Marcus, Thanks for the fixes. I did some more cmake build testing and encountered a few issues: The option -DFORTIFY_SOURCE=2 should be -D_FORTIFY_SOURCE=2, as the macro has a leading underscore. In the autotools build it defines this if it is not already defined (m4/ax_add_fortify_source.m4). When custom modes are not enabled, the cmake build is nevertheless installing the include file

On Tue, Mar 14, 2017 at 5:34 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > On 13 Mar 2017, at 15:39, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Sun, Mar 12, 2017, 4:10 PM Dean Michael Berris <dean.berris at gmail.com> > wrote: > > > > On 9 Mar 2017, at 09:32, David Blaikie via llvm-dev < > llvm-dev at

Hi llvm-dev, I'm trying to reproduce an msan failure in one of the bots, but I can't seem to get the right incantation of building LLVM with msan. Here's what I've been doing: 1) Build the toolchain in one build directory, including `compiler-rt`. 2) Build the toolchain again with the just built toolchain in step 1, but this time with `-DLLVM_USE_SANITIZER=MemoryWithOrigins`. I

On Mon, Jan 7, 2019 at 3:21 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > On Mon, Jan 7, 2019 at 8:43 PM Dangeti Tharun kumar > <cs15mtech11002 at iith.ac.in> wrote: > > > > Hi Dean, > > > > I have tried with -instr-map-1 and -instr-map-2, it didn't work. > > > > Yeah, I'm looking through the code and it looks like

Hi, The following three patches, when applied cleanly to LLVM+Clang+compiler-rt will now allow for building and running binaries with a very simple version of XRay included: http://reviews.llvm.org/D21612 (compiler-rt) http://reviews.llvm.org/D20352 (clang) http://reviews.llvm.org/D19904 (llvm) To use this on x86_64-unknown-linux-gnu you'd need to set the flags '-fxray-instrument'

On Mon, Jun 27, 2016 at 2:53 PM Xinliang David Li <davidxl at google.com> wrote: > There is some misunderstanding about the intention of this flag. The > purpose of the flag is not to turn on profile instrumentation (which > already has -fprofile-instr-generate or -fprofile-generate for it), but to > select which instrumentors to use for PGO (IR or FE). I prefer fewer flags

On Wed, Nov 22, 2017 at 10:37 AM, Dean Michael Berris <dean.berris at gmail.com> wrote: > > On 22 Nov 2017, at 02:32, comic fans <comicfans44 at gmail.com> wrote: > > with some dirty hack , I've made xray runtime 'built' on windows , > > > \o/ with more test, I've found that trampoline didn't got built for windows :/ currently cmake didn't

Hi llvm-dev, I'm currently looking for alternatives to the synthetic references that XRay uses to keep some side-tables live, to avoid linker garbage collection from deleting those sections. Before going any further, let me give a backgrounder on what XRay does today. Background ========== XRay has two side tables we use at runtime to identify the location of the sleds for the functions

Hi Kenneth, If the LLVM project is switching to CMake, then CTest might be the framework of choice to use rather than scripting up something in Bash. --Sam --- On Wed, 7/30/08, Kenneth Boyd <zaimoni at zaimoni.com> wrote: > From: Kenneth Boyd <zaimoni at zaimoni.com> > Subject: Re: [LLVMdev] Is there room for another build system? > To: "LLVM Developers Mailing

Hi Kostya, Evgenii, and David, Recently I've been making some incremental changes to the XRay runtime implementation in compiler-rt to reduce the reliance on the C++ standard library components that might have external linkage dependencies. This involves not using containers from the STL and not using non-trivially destructible C++11 thread_local objects. I was wondering whether the