similar to: Struggling with a PGO build of clang -- llvm-profdata was built without zlib support?

Yes, that was it! Now that I took a closer look, the guide also states that I should use the stage2 build. Silly me. Thanks! On Tue, 3 Sep 2019 at 19:31, David Blaikie <dblaikie at gmail.com> wrote: > I /guess/ you actually want /path/to/release_build/llvm-profdata because > the profiles are generated from binaries compiled with the release build, > so it's the release build

> 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

Hello All, I build source code of Ocelot[http://code.google.com/p/gpuocelot/]. It using LLVM dependency of Ocelot. llvm-config get cppflags represent as below in order to build with Ocelot. ./llvm-config --cppflags -I/home/chatsiri/workspacecpp/llvm/include -I/home/chatsiri/workspacecpp/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS

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

A polite ping, could someone please share a thought about this? On Sat, 8 Jun 2019 at 21:21, Kristóf Umann <dkszelethus at gmail.com> wrote: > A polite ping on this matter :) > > On Tue, 4 Jun 2019 at 01:51, Kristóf Umann <dkszelethus at gmail.com> wrote: > >> Hi! >> >> As the title suggests, I'd like to generalize llvm::IDFCalculator to be >>

Hi Jakub! On Mon, 17 Jun 2019 at 17:01, Jakub (Kuba) Kuderski <kubakuderski at gmail.com> wrote: > Hi Kristóf, > > >> 1. I read the article IDFCalculator is based on[1], but I found no >> references to IDFCalculator::setLiveInBlocks, and the file header seems to >> confirm that it's an implementation specific thing. Could I get away >> restricting the

This patch makes Unicode the default build for windows. You can override the default by setting a WXRUBY_NO_UNICODE environment variable. Roy _______________________________________________ wxruby-users mailing list wxruby-users@rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users

Hi! As the title suggests, I'd like to generalize llvm::IDFCalculator to be able to calculate control dependencies on clang's CFG. The issue is however, that many data structures it uses are "hardcoded" to use llvm::BasicBlock, and requires a lot of code to turn it into template arguments. I managed to pull this off by hammering the code until it compiled, and it works

I've started looking at the state of code coverage recently; we figured LLVM itself would be a good test to figure out how mature it is, so I gave it a shot. My experience: 1. You have to specify -DLLVM_USE_LINKER=gold (or maybe lld works; I didn't try). If you link with binutils ld, the program will generate broken profile information. Apparently, the linked binary is missing the

Hello LLVM developers, Following some hints on this mailing list earlier this year on how to make clang faster than stock llvm.org builds I have implemented a script that builds a PGO optimized version of clang by following the guide here: http://llvm.org/docs/HowToBuildWithPGO.html This works great on macOS and Linux - we gained almost 15% in our project with this technique. I am now looking at

Hello, sorry for posting this here but I'm kind of stuck. I'm trying to introduce LLVM tooling step by step at the company I'm working for. So far I'm using clang-format for automated formatting. Since I'm also working on the coding guideline I wanted to use clang-tidy for enforcing the naming convention. The problem is that we're using a plain old MAKE project, so I

Thank you. > On Jul 3, 2019, at 4:04 AM, Justin Clift <justin at postgresql.org> wrote: > > On 2019-07-01 00:22, Marty Itzkowitz via llvm-dev wrote: >> I also tried spack install llvm at develop on a POWER9 (ppc641e) >> machine, but I can not find a compiler that >> will compile it. gcc 4.8.5 is reported as too old, and gcc 7.3.0 and >> 8.1.0 both fail in

I recently had a problem creating LLVMHello. I used this CMake file #!/bin/sh # clangcmake.sh cmake -G "Eclipse CDT4 - Unix Makefiles" -DLLVM_TARGETS_TO_BUILD="X86" -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_BUILD_TYPE="Debug" -DCMAKE_ECLIPSE_VERSION=4.5 -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang ../llvm then I ran make LLVMHello and the build failed

On 6/18/2017 3:51 PM, Vedant Kumar wrote: >> My experience: >> >> 1. You have to specify -DLLVM_USE_LINKER=gold (or maybe lld works; I >> didn't try). If you link with binutils ld, the program will generate >> broken profile information. Apparently, the linked binary is missing >> the __llvm_prf_names section. This took me half a day to figure out.

Hi, I have a dynamically loaded llvm pass built in-tree with ninja (generated with cmake, basically a copy of the hallo pass plugin, linux, llvm/clang version 6.0.1). It uses the ExecutionEngine. Building it without linking against LLVMExecutionEngine library results in an undefined symbol to the vtable of the EngineBuilder when loaded to opt. Linking the plugin with LLVMExecutionEngine results in

Hi all I wanted to do a quick build of a clean branch yesterday and noticed something surprising in the configure log: > -- No build type selected, default to Debug It appears that llvm's configuration forces Debug builds if the user does not specify the build type. https://github.com/llvm/llvm-project/blob/9218ff50f93085d0a16a974db28ca8f14bc66f64/llvm/CMakeLists.txt#L57-L60

cmake -G Ninja -DLLVM_ENABLE_PROJECTS="debuginfo-tests" -DLLVM_USE_LINKER=lld -DCMAKE_BUILD_TYPE="Release" -DLLVM_TARGETS_TO_BUILD=X86 -Wno-dev ../llvm &> ../../cmake.log in cmake.log -- Targeting X86 CMake Error at /home/nnelson/Documents/llvm-project/debuginfo-tests/CMakeLists.txt:30 (message):   Cannot run debuginfo-tests without python 3 installed python3

It seems to be down again for me, anyone experiencing the same? https://bugs.llvm.org/show_bug.cgi?id=18159 On Tue, 23 Jun 2020 at 14:54, Aaron Ballman via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Tue, Jun 23, 2020 at 8:28 AM Xing GUO via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hi folks, > > > > It seems that bugzilla is

Hi Nelson, Thanks for your reply. The “build/Debug/lib” and "build/Release/lib” directories is where all the libraries go. Similarly, the executables go to “build/Debug/bin” and “build/Release/bin” before they are moved to the install directory. This is expected and normal. However, the problem is that a small number of libraries (exactly 20 in total) are not created at all for the LLVM

Hi, I tried to build LLVM 4.0.1 on a Slackware Linux box with 3 GB of RAM using gcc-7.1.0. Near the end of the build process, I hit the following error: [ 89%] Linking CXX shared library ../../lib/libLTO.so collect2: fatal error: ld terminated with signal 9 [Killed] compilation terminated. tools/lto/CMakeFiles/LTO.dir/build.make:269: recipe for target 'lib/libLTO.so.4.0.1' failed