similar to: Removing LLVM testing tools from the install distribution

A new one was just added recently - Clang's diagtool. So if you're looking at how to reduce install size, might want to double check that the motivation for adding that is consistent with/not contradictory with your goals/motivations for removing these. (also since several of these are clang binaries/tools - maybe check with the cfe-dev list too) On Mon, May 14, 2018 at 2:27 PM Vedant

Please keep llvm-symbolizer in the install distribution. If a user's program crashes then I like to print out a backtrace with file name/line number if compiled with debug. Forking off llvm-symbolizer is the easiest way for me to obtain the debug information. Thanks. On Mon, May 14, 2018 at 5:27 PM, Vedant Kumar via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Should the

Dear llvm developpers, I followed the tutorial to build llvm and clang provided here: https://clang.llvm.org/get_started.html The sources are in sync with subversion repository, and I ended up with more than 30GB of binaries in llvm/bin as shown at the end of this message. I assume I did something wrong, but I did not find any entry in the doc that helps me understand how to reduce the size of

On Fri, Apr 27, 2018 at 6:21 PM, Manuel Yguel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Dear llvm developpers, > I followed the tutorial to build llvm and clang provided here: > https://clang.llvm.org/get_started.html > > The sources are in sync with subversion repository, and I ended up with more > than 30GB of binaries in llvm/bin as shown at the end of this

I am pleased to announce that LLVM 7 is now available. Get it here: https://llvm.org/releases/download.html#7.0.0 The release contains the work on trunk up to SVN revision 338536 plus work on the release branch. It is the result of the community's work over the past six months, including: function multiversioning in Clang with the 'target' attribute for ELF-based x86/x86_64 targets,

I am pleased to announce that LLVM 7 is now available. Get it here: https://llvm.org/releases/download.html#7.0.0 The release contains the work on trunk up to SVN revision 338536 plus work on the release branch. It is the result of the community's work over the past six months, including: function multiversioning in Clang with the 'target' attribute for ELF-based x86/x86_64 targets,

Alex, I have built ubuntu binaries for the last couple of releases. I apologize -- I haven't built those new binaries yet, I only have uploaded the SLES ones. I have an ubuntu 14 tarball that I'll upload today. I will work on getting ubuntu 16 or 17 next. The dpkg/APT repos might be a good substitute, though. Hans, apologies -- I should've asked to hold the 7.0.0 release for

Ubuntu 16: a2a2768b04e1d561e6f9a1a2d525eda7aae18624 clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz On Thu, Sep 20, 2018 at 7:12 PM Brian Cain <brian.cain at gmail.com> wrote: > Uploaded ubuntu 14: > > dec5ca53043c80c1c6e90c0473df84f0182d80af > clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz > > > On Wed, Sep 19, 2018 at 12:58 PM Brian Cain <brian.cain

Hi Hans, we have uploaded tarballs for ARM and AArch64 targets: a20ea3fe482e754a61ccb37c67456ad1 clang+llvm-6.0.1-aarch64-linux-gnu.tar.xz f37b132c3dfb3b776524980be5af3a76 clang+llvm-6.0.1-armv7a-linux-gnueabihf.tar.xz and 47a9a9bb02d41581e6804b98918188f6 clang+llvm-7.0.0-aarch64-linux-gnu.tar.xz e639d8f5dc58be5cf44d017fd5eefd6c clang+llvm-7.0.0-armv7a-linux-gnueabihf.tar.xz Yvan On Mon,

I need to track down all pointers anywhere in a module that could be pointing to functions (because some of the optimizations I want to do, require either identifying every use of a function, or conservatively identifying when such cannot be done). A starting point is to look at all the global variables: for (auto &G : M.globals()) for (auto &V : G.operands()) if (auto F =

I'm trying to customize llvm by adding a header file of my own and tweaking things accordingly. While building, things go well until a certain point where it stops seeing the includes of my file. I'm working on Ubuntu 12.04 with llvm-3.1 on a custom target (mips-like), gcc-4.6 and clang-3.2 (i've tried 3.1 too). >From what i've understood, when it builds the first binaries of

Hello, I want to ask if incorrect serialization of a constant's use-list order is considered as a bug. While compiling some programs with clang -c -emit-llvm -O2 -g I noticed that for many of the bitcode files the verify-uselistorder tool terminates with output *** verify-uselistorder *** verify bitcode LLVM ERROR: use-list order changed where the mismatch is always for the constant i64

Hi all, I’ve most recently been grappling with a difficult to reproduce bug. I’ve traced the source of the difficulty in reproduction to the IVUsers analysis pass that is used by Loop Strength Reduction. Specifically, the IVUsers pass’s output is very sensitive to both the use list ordering of the instructions that it is looking at and the ordering of the Phi nodes in the header block of the loop

Pete Cooper and I have been looking at memory profiles of running llc on verify-uselistorder.lto.opt.bc (ld -save-temps dump just before CodeGen of building verify-uselistorder with -flto -g). I've attached leak-backend.patch, which we're using to make Intrustruments more accurate (instead of effectively leaking things onto BumpPtrAllocators, really leak them with malloc()). (I've

On Mon, Aug 31, 2015 at 10:12 AM, Rafael Espíndola <llvm-dev at lists.llvm.org> wrote: > > > Not sure I follow? Generally LTO inputs are going to be "user provided" > (in the sense that they're not produced immediately prior by the same > process - or you'd have just produced a single Module in the first place, I > would imagine) so changing the default

> I think your best bet for controlling code bloat is to compile with > -fsanitize=undefined -fsanitize-trap=undefined. Also you may not need all of UBSan's checks at the same time -- so pick and choose among its checks using the finer-grained flags. If you're really stuck against a hard limit on code size, try applying UBSan to a subset of files in your project at a time. John

A while back I finished up some work [1] that Chad started to preserve use-list-order in bitcode [2], hidden behind an "experimental" option called `-preserve-bc-use-list-order`. I then added a similar `-preserve-ll-use-list-order` option for LLVM assembly [3]. [1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-July/074604.html [2]: https://llvm.org/bugs/show_bug.cgi?id=5680 [3]:

First error: head file related. Strangely, this code has been there a while, which makes me think that the HAVE_ARC4RANDOM is somehow now showing up as set whereas perhaps it didn't used to be. tfiala at tfiala2:~/lldb/svn/lgs/build$ make make[1]: Entering directory `/mnt/ssd/work/svn/lgs/build/lib/Support' llvm[1]: Compiling Process.cpp for Debug+Asserts build In file included from

A few weeks back I had tried to install CentOS on my old AMD 5x6x (equiv to P75 performance) with plans to use it as my firewall and router. Because there were some problems relating to RPM compile architecture (apparently), I posted and Bryan suggested IPCop, even at peril to his life on these lists ;-) according to him. ;-) ;-) Just wanted to tell him thanks, it's worked out well. Had

Vedant, Thanks for building the packages before. Could you detail what's required to build these binaries on macOS so that someone else could replicate it? Thanks, Tobias On Mon, Oct 14, 2019 at 8:29 PM Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Gio, > > I prepared the macOS packages for the past few releases, but have less time to keep up with