similar to: [LLVMdev] BuildMode

Hi David, On Mon, 2007-06-25 at 17:43 -0500, David A. Greene wrote: > I'm continuing my quest to integrate _GLIBCXX_DEBUG into the config system. > I now have things at a point where I can configure llvm to build with > -D_GLIBCXX_DEBUG and the llvm-gcc will pick up the correct CPPFLAGS > automatically. Okay. > > One thing I noticed in the llvm Makefile.rules is this:

On Tuesday 26 June 2007 14:05, Reid Spencer wrote: > I think you mis-interpreted something. That's not surprising. :) > If you build with -disable-assertions you are telling whatever build > mode (Debug or Release) to not include assertions. Consequently you get > either Release-Asserts (Release minus asserts) or Debug-Asserts (Debug > minus Asserts). I was wondering if

Hello John, John Criswell <criswell at illinois.edu> writes: [snip] > By the way, it looks like you don't have a build with assertions > enabled. I recommend compiling with > > gmake ENABLE_OPTIMIZED=0 DISABLE_ASSERTIONS=1 Shouldn't the above be DISABLE_ASSERTIONS=0 ? (which means DISABLE_ASSERTIONS=No, introducing the dreaded double negation which causes so much

Good summer, all! This patch enables ENABLE_SHARED=1 to build DLL based LLVM toolchain. I have checked this on Cygwin-1.5, Cygwin-1.7, mingw(msysgit) and mingw-cross-fedora12. I can separate this patch into some parts; cleanups, adding definitions and adding rules. Any feedbacks are welcome. Have fun! ...Takumi * Pros - reduction of linking time of toolchain. - capability of -load

On 11/3/2011 4:55 AM, Arshak Nazaryan wrote: > Dear sir or madam, > > I am a 4-th year student at Yerevan State University, Armenia; and I > am studying LLVM in order to write my Bachelor thesis. Hi Arshak. > I am trying to write an llvm pass that just removes all "Add" commands > and gives some statstics. > Nevertheless, I get this segmentation fault: The

Hi John, That worked for me. I am using llvm 3.2 only and following http://safecode.cs.illinois.edu/docs/Install.html So for I am able to make inside llvm/projects/poolalloc by doing such cosmetic changes. Now, when I tried to make inside llvm/projects/safecode, I see another error. kpawar at KPAWAR-LT ~/SAFECode/LLVM_SRC/llvm/projects/safecode $ /usr/bin/clang -cc1 -triple

I just made a patch to our local llvm build here to pass -D_GLIBCXX_DEBUG when building llvm. This switch turns on debug code in libstdc++ that checks for various violations. We've already discovered several llvm bugs with it. Should I commit a change back to the official sources? It will almost certainly cause tests to fail, but that's a GOOD thing.

----- Original Message ----- > From: "Jim Grosbach" <grosbach at apple.com> > To: "Daniel Berlin" <dberlin at dberlin.org> > Cc: llvmdev at cs.uiuc.edu > Sent: Wednesday, April 17, 2013 2:46:49 PM > Subject: Re: [LLVMdev] make check rebuilds the project? > > > > > > > > > > > cmake+ninja is a non-option for

On Nov 22, 2009, at 2:08 PM, Pekka Jääskeläinen wrote: > Hi, > > Chris Lattner wrote: >> This is fine to me in principle, but please make sure this doesn't >> impact compile time or memory usage of llc somehow. > > OK. Any recommended way to do this? Is there some nice way to benchmark > speed + memory consumption of llc in LLVM testing infra at the > moment

Hi, Trying to build AOT version of vmkit java, building for that classpath glibj.zip: $ cd vmkit/tools/vmjc/libvmjc $ make ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1 REQUIRES_FRAME_POINTER=1 has eventually, after 50 minutes, brought: <<< llvm[0]: Compiling glibj.zip to llvm llvm[0]: Optimizing glibj.zip llvm[0]: Compiling glibj.zip.bc to native UNREACHABLE executed! 0 llc

I needed the following patch to be able to use gprof with profiled build. regards, Benoit --- a/Makefile.rules (revision 37946) +++ b/Makefile.rules (working copy) @@ -212,6 +212,7 @@ CXX.Flags := $(OPTIMIZE_OPTION) -pg -g C.Flags := $(OPTIMIZE_OPTION) -pg -g LD.Flags := $(OPTIMIZE_OPTION) -pg -g + KEEP_SYMBOLS := 1 else ifeq ($(ENABLE_OPTIMIZED),1) BuildMode := Release

On Wed, Apr 17, 2013 at 1:05 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Jim Grosbach" <grosbach at apple.com> >> To: "Daniel Berlin" <dberlin at dberlin.org> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Wednesday, April 17, 2013 2:46:49 PM >> Subject: Re: [LLVMdev] make check rebuilds the

>> >> >> cmake+ninja is a non-option for many developers. > > > By the way, i'm curious what this means. It can be interpreted in a > number of ways, but it would be good to know what problems you are > specifically saying making it a non-option for many developers Hi Danny, Sorry for being unclear. My fault for posting when I’m in a hurry. I don’t

Reid, I think it is the first time it is run that the errors occcur !? Not sure but that would seem logical. Aaron

Hi Takumi, > Any feedbacks are welcome. > Have fun! This seems to be pretty useful addition to LLVM on windows! And it seems the only painless way to make plugins working, yay! For me the patch looks pretty good. One minor thing: could you please rename SharedDir => SharedLibDir Thanks! -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg

Anton, Thanks for your comment. 2nd patch attached. - s/SharedDir/SharedLibDir/g - move prefix=cyg sunk into if(cygwin or mingw) arigato gozaimasu...Takumi * Additional issues - You may build LLVMHello.dll but I don't modify lib/Transforms/Makefile. Because making LLVMHello.dll requires the library LLVM.dll, but it oughta be on the way to making libs at building

On Thu, 7 Jun 2007, David A. Greene wrote: > I just made a patch to our local llvm build here to pass -D_GLIBCXX_DEBUG when > building llvm. This switch turns on debug code in libstdc++ that checks for > various violations. We've already discovered several llvm bugs with it. > Should I commit a change back to the official sources? It will almost > certainly cause tests to

On May 8, 2009, at 11:49 AM, Chris Lattner wrote: > On May 7, 2009, at 6:24 PM, Mike Stump wrote: >> I'm toying with building with -mdynamic-no-pic, but for this to work, >> the shared library bits in llvm can't be built with that flag. > > Hi Mike, > > If you're doing this for Clang's benefit, No, not really, I'm doing it for the general benefit of

--- autoconf/configure.ac | 4 +++- cmake/modules/LLVMConfig.cmake.in | 3 ++- configure | 4 +++- tools/llvm-config/Makefile | 6 ++++++ tools/llvm-config/llvm-config.in.in | 3 ++- 5 files changed, 16 insertions(+), 4 deletions(-) diff --git a/autoconf/configure.ac b/autoconf/configure.ac index f3e94e8..cd943cc 100644 ---

The patch below adds dsa and some of poolalloc to opt. It should be simple enough to extend to all of poolalloc by adding more classes to LinkDSA.h. Andrew Index: tools/opt/opt.cpp =================================================================== --- tools/opt/opt.cpp (revision 97995) +++ tools/opt/opt.cpp (working copy) @@ -38,6 +38,12 @@ #include "llvm/LinkAllVMCore.h"