search for: findatlanti

...ks like my LLVM build script only built debug versions of the tools, not release versions. I'm investigating, I didn't change anything that should have caused that. [s] On Apr 28, 2009, at 4:56 PM, Bill Wendling wrote: > On Tue, Apr 28, 2009 at 4:43 PM, Sarah Thompson <sarah at findatlantis.com > > wrote: >> OK, that got much further, but I'm now seeing another problem which >> may (or may not) be related. Building my own code (my model checker), >> it builds libraries fine, then within tools (I'm using a fairly >> standard LLVM build environmen...

...[s] On Apr 28, 2009, at 5:19 PM, Bill Wendling wrote: > We build debug by default. You will have to add ENABLE_OPTIMIZED=1 on > the "make" command line or --enable-optimized during configuration. > > -bw > > On Tue, Apr 28, 2009 at 5:12 PM, Sarah Thompson <sarah at findatlantis.com > > wrote: >> Hmm... looks like my LLVM build script only built debug versions of >> the tools, not release versions. I'm investigating, I didn't change >> anything that should have caused that. >> >> [s] >> >> On Apr 28, 2009, at 4:56 P...

We build debug by default. You will have to add ENABLE_OPTIMIZED=1 on the "make" command line or --enable-optimized during configuration. -bw On Tue, Apr 28, 2009 at 5:12 PM, Sarah Thompson <sarah at findatlantis.com> wrote: > Hmm... looks like my LLVM build script only built debug versions of > the tools, not release versions. I'm investigating, I didn't change > anything that should have caused that. > > [s] > > On Apr 28, 2009, at 4:56 PM, Bill Wendling wrote: > >&g...

...19 PM, Bill Wendling wrote: > >> We build debug by default. You will have to add ENABLE_OPTIMIZED=1 on >> the "make" command line or --enable-optimized during configuration. >> >> -bw >> >> On Tue, Apr 28, 2009 at 5:12 PM, Sarah Thompson <sarah at findatlantis.com >>> wrote: >>> Hmm... looks like my LLVM build script only built debug versions of >>> the tools, not release versions. I'm investigating, I didn't change >>> anything that should have caused that. >>> >>> [s] >>> >>&...

On Tue, Apr 28, 2009 at 4:43 PM, Sarah Thompson <sarah at findatlantis.com> wrote: > OK, that got much further, but I'm now seeing another problem which > may (or may not) be related. Building my own code (my model checker), > it builds libraries fine, then within tools (I'm using a fairly > standard LLVM build environment here), I am seeing th...

On Wed, Apr 29, 2009 at 6:04 PM, Sarah Thompson <sarah at findatlantis.com> wrote: > Hi folks, > > I had some code that used to work fine in earlier versions of LLVM, > but is now failing. I have some code that expands DbgStopPointInst > instructions to my own entry points in an opt pass, but it's currently > failing to get the file name and...

Hi folks, I had some code that used to work fine in earlier versions of LLVM, but is now failing. I have some code that expands DbgStopPointInst instructions to my own entry points in an opt pass, but it's currently failing to get the file name and path back, though it is still correctly getting line numbers. If you happen to have a code fragment that is known to work, it would be

OK, that got much further, but I'm now seeing another problem which may (or may not) be related. Building my own code (my model checker), it builds libraries fine, then within tools (I'm using a fairly standard LLVM build environment here), I am seeing the error *** llvm-config doesn't exist - rebuilding it followed by a make: Entering an unknown directory which is

Hi folks, I'm currently extending my model checker to collect coverage information, and as part of this I'm finding a need to get a more friendly version of munged C++ identifiers than the name used by the linker. For example, though internally, something like '_Z7thread1Pv' is fine as an identifier, I'd like to be able to give the user something more readable. Since

...ntPtrConstantExpr... so how can I get at that constant i8 array without casting to a GetElementPtrInst, and with GetElementPtrConstantExpr being inaccessible to user code? [s] On Apr 29, 2009, at 6:29 PM, Bill Wendling wrote: > On Wed, Apr 29, 2009 at 6:04 PM, Sarah Thompson <sarah at findatlantis.com > > wrote: >> Hi folks, >> >> I had some code that used to work fine in earlier versions of LLVM, >> but is now failing. I have some code that expands DbgStopPointInst >> failing to get the file name and path back, though it is still >> correctly gett...

Just a quick question... I've been attempting to trap floating point badness by setting up a SIGFPE handler. However, I'm not seeing it trigger, even for simple test code that forces division by zero. I'm generating bitcode with llvm-gcc and then executing it with a (modified) version of the jitter, for reference. Is there any arcane magic necessary to turn on SIGFPE

Hi folks, I am very sorry, but I'll not be able to attend the developer's meeting. I came down with a nasty stomach bug yesterday, and am frankly in no fit state to do anything much. Many apologies, Sarah Thompson

> How are you compiling this? I get the following sort of output: > > llvm-gcc incdec.cpp -o incdec I am currently using LLVM 1.8 -- I was basically holding off porting until LLVM 2.0 stabilises because I want to be able to move to 64 bit Intel and don't want to have to hit a moving target. > void %inc(int* %p) { > entry: > %tmp = volatile load int* %p

Sarah Thompson wrote: > Chris Lattner wrote: > >> On Tue, 17 Jul 2007, Sarah Thompson wrote: >> >> >> >>> Do I understand correctly that there is nothing that the current gcc >>> front end generates that wouldn't fit an old-style GenericValue? I'm >>> wondering if this might be an interim approach that would avoid me

Hi Folks, I'm having some difficulties getting LLVM to build and work correctly on CENTOS 5.3. This is basically tracked down easily enough to CENTOS using GCC 4.1.x by default, which is known-buggy and known not to work with LLVM -- I was getting the well-known problem with aborts due to a non-empty symbol table. I have installed the gcc43 package via yum (I'm trying to stick