similar to: [LLVMdev] Fwd: Re: Bootstrap Failure

Here's the .bc file -------------- next part -------------- A non-text attachment was scrubbed... Name: testcase.bc Type: application/octet-stream Size: 1328 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091112/79af2e36/attachment.obj> -------------- next part -------------- -bw On Nov 12, 2009, at 1:52 PM, David Greene wrote: > Forgot to

On Thursday 12 November 2009 17:06, Bill Wendling wrote: > Here's the .bc file I don't see the bootstrap failure so it must be a Darwin thing. -Dave

On Nov 12, 2009, at 3:42 PM, David Greene wrote: > On Thursday 12 November 2009 17:06, Bill Wendling wrote: >> Here's the .bc file > > I don't see the bootstrap failure so it must be a Darwin thing. > The .bc file I sent shows the error. Could you revert your patches until you have a fix, please? :-) -bw

I'm getting the following when building llvm-gcc with an optimized set of LLVM libraries: /ptmp/dag/build.llvm-gcc-4.2.trunk.official.opt/x86_64-unknown-linux-gnu/./gcc/xgcc -B/ptmp/dag/build.llvm-gcc-4.2.trunk.official.opt/x86_64-unknown-linux-gnu/./gcc/ -B/cray/iss/compiler/cost/tools/llvm-tools/llvm/install.trunk.official.opt/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/bin/

David Greene wrote: > I'm getting the following when building llvm-gcc with an optimized set of > LLVM libraries: > > /ptmp/dag/build.llvm-gcc-4.2.trunk.official.opt/x86_64-unknown-linux-gnu/./gcc/xgcc > -B/ptmp/dag/build.llvm-gcc-4.2.trunk.official.opt/x86_64-unknown-linux-gnu/./gcc/ >

Yes. On Mon, Nov 10, 2008 at 4:45 PM, David Greene <dag at cray.com> wrote: > On Monday 10 November 2008 15:28, Bill Wendling wrote: >> Hi Daniel, >> >> I see that you're doing a Debug build. Could you do a "Release" or >> "Release-Asserts" build instead? This will catch errors which >> developers won't normally see. > > I

On Monday 10 November 2008 15:28, Bill Wendling wrote: > Hi Daniel, > > I see that you're doing a Debug build. Could you do a "Release" or > "Release-Asserts" build instead? This will catch errors which > developers won't normally see. I never knew about buildbot until just now. This could really help with the validation proposal I just posted. Can

On Apr 30, 2012, at 1:00 PM, dag at cray.com wrote: > Bill Wendling <wendling at apple.com> writes: > >> Link-Time Optimization has a problem. We need to preserve some of the >> flags with which the modules were compiled so that the semantics of >> the resulting program are correct. For example, a module compiled with >> `-msoft-float' should use library

On Apr 30, 2012, at 4:12 PM, Bill Wendling wrote: > On Apr 30, 2012, at 1:00 PM, dag at cray.com wrote: > >> Bill Wendling <wendling at apple.com> writes: >> >>> Link-Time Optimization has a problem. We need to preserve some of the >>> flags with which the modules were compiled so that the semantics of >>> the resulting program are correct. For

On Tuesday 25 September 2007 13:40, Bill Wendling wrote: > I thought about doing this, but there's the potential for naming > conflicts that won't be caught until a release build is done. :-( I I considered this and figured that it was extremely unlikely in our code. Certainly it's not a bullet-proof solution. > wonder, though. Would it make sense to put the stream decls in

Hi all, There's been a recent bootstrap failure that might be covered up because of another failure. I just wanted to point this out so that people can take a look: -bw Here's the failure from our buildbot: Assertion failed: (DestReg == VirtReg && "Unknown load situation!"), function RewriteMBB, file /Volumes/Sandbox/Buildbot/llvm/build.llvm-

On Tue, Nov 20, 2007 at 07:01:25PM -0800, Bill Wendling wrote: > I think that it's a hold-over to how things used to be done. IIRC, > you had to have the && at the end of the RUN line if you had another > RUN line that needed to be executed. That's no longer the case, of > course. Thanks. I'll remove the && from the one test that still has it then.

On Thu, Jul 16, 2009 at 1:55 PM, David Greene<dag at cray.com> wrote: > On Thursday 16 July 2009 14:04, Daniel Dunbar wrote: >> 2009/7/15 Török Edwin <edwintorok at gmail.com>: >> > I'm not too keen about seeing buildbots play with trunk ;) >> > >> > How about starting simple, and just auto-tagging builds that work? >> > Could be done

Hi Dave, > We ran into a similar problem in our custom code here. To work around > it I modified Debug.h like this: > > #ifdef NDEBUG > static llvm::OStream NullStream(0); > #define DOUT llvm::NullStream > #else > #define DOUT llvm::getErrorOutputStream(DEBUG_TYPE) > #endif > I thought about doing this, but there's the potential for naming conflicts that

Actually, take a look at the current TOT for llvm-gcc4. Jim & I put a patch in there yesterday that should make things work with llvm_ostreams. -bw On 11/30/06, Bill Wendling <isanbard at gmail.com> wrote: > On 11/30/06, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > On 11/30/06, Andrew Lenharth <andrewl at lenharth.org> wrote: > > > The

I get this failure when I go to compile the latest LLVM CVS source: if g++ -I/Users/wendling/llvm/llvm/lib/Target/Alpha -I/Users/wendling/llvm/llvm/lib/Target/Alpha -I/Users/wendling/llvm/llvm/include -I/Users/wendling/llvm/llvm/include -I/Users/wendling/llvm/llvm/include -I/Users/wendling/llvm/llvm/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -Wall -W -Wwrite-strings -Wno-unused -g -D_DEBUG -c

On 11/30/06, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 11/30/06, Andrew Lenharth <andrewl at lenharth.org> wrote: > > The llvm_ostreams, which you take the address of go out of scope very > > quickly, and are only stored by address in the bytecode writer, thus > > the writers have a pointer to a stack allocated object they are to > > write

On Monday 10 November 2008 16:50, Daniel Berlin wrote: > Yes. Cool. I'd like to look at installing something here. You offered to walk us through how to do this. I'll see if I can install buildbot here and then mail you back when I'm ready to go. -Dave > On Mon, Nov 10, 2008 at 4:45 PM, David Greene <dag at

Back during the LLVM developer's meeting, I talked with some of you about a proposal to "validate" llvm. Now that 2.4 is almost out the door, it seems a good time to start that discussion. I've written up a detailed proposal and attached it to this message. The goal is to ease LLVM use by third parties. We've got consideral experience with LLVM and the community

Hi,     I get the following error where the "make"(building) stops.   /MinGW/llvm/arm_objects/./gcc/xgcc -B/MinGW/llvm/arm_objects/./gcc/ -B/MinGW/llv m/arm_objects/../install/arm-linux/bin/ -B/MinGW/llvm/arm_objects/../install/arm -linux/lib/ -isystem /MinGW/llvm/arm_objects/../install/arm-linux/include -isyst em /MinGW/llvm/arm_objects/../install/arm-linux/sys-include  -O2 -O2 -g -O2