similar to: [LLVMdev] Building LLVM 2.5 on CENTOS 5.3

On Apr 28, 2009, at 3:45 PMPDT, Sarah Thompson wrote: > 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

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

Just to give closure here, I eventually gave up, built an Ubuntu 9 VMWare image which uses gcc 4.3.2 by default, installed Eclipse Ganymede and various other tools, then built LLVM 2.5 and my own code. It all ran fine. There is clearly something broken in the CentOS gcc43 package. Definitely one to avoid. [s] On Apr 28, 2009, at 5:40 PM, Sarah Thompson wrote: > (My script does both

(My script does both of those -- the debug build worked (I think), but the release build fails) [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

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: > 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

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

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 the error > >        ***

Dale, Thanks. It's not changed, but I've enclosed a fresh patch against today's trunk. However, I'm seeing 28 unexpected failing tests in llvm/test on x86 Linux 64 today. But it's the same on an unmodified tree, so I guess I'm still okay. It passed at one point for me with these changes. -John On Wed, Sep 1, 2010 at 5:04 PM, Dale Johannesen <dalej at apple.com>

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

Actually the 2.8 fork is coming up tomorrow and I'm thinking maybe we should wait until after that. Is this something you really want to get in 2.8? On Sep 1, 2010, at 6:29 PMPDT, John Thompson wrote: > Dale, > > Thanks. It's not changed, but I've enclosed a fresh patch against > today's trunk. > However, I'm seeing 28 unexpected failing tests in

Howdy, We believe we've found a bug in the libgcc or libstdc++ library (not sure which one) packaged with the gcc43 port in fbsd7 on an Intel x86-64. A program linked against those libraries aborts when an exception is thrown. It does not abort if -lpthread is added to the link line, even though the program does not use threads. I believe the problem is related to the pthread stubs in

Dale, Sorry, I see you did say I should run the gcc tests. I apologize for forgetting this. I'll work on getting them to run here. Chris et. all, I have a fix for the assertion failure in the enclosed llvmmultalt8.patch file. I didn't realize the input constraints could have different numbers of alternatives from the outputs, which now makes sense. The pr20314-2.c file now compiles

I'm close to confirming that I get the equivalent results from the test-suite with my changes, compared to a fresh tree, on a Linux x86 64 bit box. When that is the case, may I check in my current changes for the LLVM side? My preference is to develop the mult-alt support incrementally, rather than one big check-in, as I get nervous sitting on a lot of changes for a long time. I feel this

On Sep 21, 2010, at 2:45 PMPDT, John Thompson wrote: > fatal error: error in backend: Ran out of registers during register allocation! > Please check your inline asm statement for invalid constraints: > INLINEASM <es:>, 0, 10, %reg16396<def>, 10, %reg16397<def>, 10, %reg16398<def>, 10, %reg16399<def>, 10, %reg16400<def>, 10, %reg16401<def>,10,

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

On Sep 1, 2010, at 11:03 AMPDT, John Thompson wrote: > I'm close to confirming that I get the equivalent results from the > test-suite with my changes, compared to a fresh tree, on a Linux x86 > 64 bit box. > > When that is the case, may I check in my current changes for the > LLVM side? In principle, yes, I'd like to rereview if it's changed. > My

Dale, I took a closer look at the first llc failure, initp1. Looking at the initp1.llc file in gdb, it appears that the statically constructed objects without the init_priority attribute are being constructed before those with it, though the test seems to expect the opposite. The initp1.llc.s file seems to have the .ctors table in the right order, but the _init code is reading the table in

On Sep 20, 2010, at 9:40 PMPDT, John Thompson wrote: > Thanks, Stuart. Sorry, I had some left-over editing cruft in my email. From Googling runtest, I had found dejagnu, which I'd heard some folks were using over there, so I used the local package manager to install it. But from what you said I went ahead and got the dejagnu sources and built it, but had problems in running make

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 path back, though it is

Thanks, Stuart. Sorry, I had some left-over editing cruft in my email. >From Googling runtest, I had found dejagnu, which I'd heard some folks were using over there, so I used the local package manager to install it. But from what you said I went ahead and got the dejagnu sources and built it, but had problems in running make install, which is trying to put it /usr/local/bin rather than