similar to: [LLVMdev] [patch] [llvm-gcc4] fix bootstrap failure

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 to. This crashes. Andrew On 11/30/06, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > The attached patch fixes a bootstrap failure introduced by the use of >

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 to. This crashes. The attached version leaks :-) It is a work around. If I understand correctly,

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

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

>> Sorry for the delay, please try this tarball: >> http://nondot.org/sabre/2006-03-02-llvm-gcc-4.tar.gz > > There's some confusion with --enable-llvm configure parameter. I've built > LLVM to a separate build dir. The source is ~ghost/Work/llvm-cvs and build > dir is /space/p2/ghost/build/llvm-cvs ... > So, it seems like, at the same time: > > 1. buildir

Chris Lattner wrote: > On Thu, 2 Mar 2006, Vladimir Prus wrote: >>>> The instructions seem to have one path wrong. It says to get: >>> >>> I'll put together a tarball today. That will be easier than dealing >>> with a patch, and it will include a bunch of bugfixes since the previous >>> email. >> Further into process, I get this error:

I just looked over your diff and it would seem to me that additional changes would be needed to be done to some of the LLVM-IR -> DAG stuff to make things fully functional (this could be a bit of supposition on my part since I do not fully understand all of the code). --- On Sun, 8/2/09, Andrew Lenharth <andrewl at lenharth.org> wrote: > From: Andrew Lenharth <andrewl at

Attached is the target independent llvm.atomic.barrier support, as well as alpha and x86 (sse2) support. This matches Chandler's definitions, and the LangRef patch will just restore that. Non-sse2 barrier will be needed, I think it is "lock; mov %esp, %esp", but I'm not sure. Any objections? I'll take a hack at the front end support for __sync_synchronize after this

On 2/15/08, Andrew Lenharth <andrewl at lenharth.org> wrote: > I'll take a hack at the front end support for > __sync_synchronize after this goes in. This is the gcc side of the patch. Index: gcc/llvm-convert.cpp =================================================================== --- gcc/llvm-convert.cpp (revision 46956) +++ gcc/llvm-convert.cpp (working copy) @@

On Sun, Aug 2, 2009 at 6:09 PM, Carter Cheng<carter_cheng at yahoo.com> wrote: > I just looked over your diff and it would seem to me that additional changes would be needed to be done to some of the LLVM-IR -> DAG stuff to make things fully functional (this could be a bit of supposition on my part since I do not fully understand all of the code). Code generation actually was

On Wed, Jul 14, 2010 at 10:54 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Jul 14, 2010 at 8:33 AM, Andrew Lenharth <andrewl at lenharth.org> wrote: >> On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com> wrote: >>> On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel >>> <torvald at se.inf.tu-dresden.de> wrote:

does that mean .o generated with gcc (.c -> .s and .s -> .o) will not contain llvm ir? i meant, final kernel bitcode ir arch independent and can be JIT with any arch-specific backend. Is it not the case? thanks, ashish On Sat, Sep 27, 2008 at 10:43 PM, Andrew Lenharth <andrewl at lenharth.org> wrote: > On Sat, Sep 27, 2008 at 8:08 PM, Ashish Bijlani > <ashish.bijlani at

On 7/9/07, Andrew Lenharth <andrewl at lenharth.org> wrote: > Poor alpha, no code examples or entries in your tables. But that said, it uses a load-locked, store-conditional and has various memory barriers which are sufficient to implement all your proposal. Andrew > On 7/9/07, Chandler Carruth <chandlerc at gmail.com> wrote: > > Hello, > > > > After a fair

Its good to see that a feature of this nature would be useful to a whole range of people, I wasn't aware of that. On 9 June 2010 22:40, Andrew Lenharth <andrewl at lenharth.org> wrote: > My argument amounts to express side tables as side tables in the IR > rather than as an ordering on globals.  I think that would simplify > the backend (a side table is something you discover

I updated the latest "poolalloc" code and the problem seems to have been fixed. However, I am still having problem of running "poolalloc". After compilation finished, there are several dynamic libraries created (libpoolalloc_rt.so, libpoolalloc_fl_rt.so and LLVMDataStructure.so). I was not sure which one I should use so I just tried all of them with "opt -load".

On 21 September 2010 18:39, Andrew Lenharth <andrewl at lenharth.org> wrote: > Type names don't have meaning.  If you want this not to happen, you > can generate a different opaque type for each type in your language to > prevent merging. Hi Andrew, Why create opaque types to avoid something that should be taken from granted (in a said "type-safe" representation)? I

On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel > <torvald at se.inf.tu-dresden.de> wrote: >> On Tuesday 13 July 2010 19:48:25 you wrote: >>> On Tue, Jul 13, 2010 at 10:09 AM, Torvald Riegel >>> > I thought that the layout of structs was supposed to be preserved (wrong

DSA should be current against head, but poolalloc isn't. I've changed DSA a bit so it may not compile with poolalloc as is. I haven't had time to tackle updating poolalloc (either to head or to the dsa changes). If you want the version from the paper, try checking out llvm 1.8 or 1.9 and a dsa from around then. The dsa as used on the linux kernel and in the OS work is in a branch

On Thu, 2 Mar 2006, Vladimir Prus wrote: >>> The instructions seem to have one path wrong. It says to get: >> >> I'll put together a tarball today. That will be easier than dealing with >> a patch, and it will include a bunch of bugfixes since the previous email. > Further into process, I get this error: > In file included from

On Wednesday 14 July 2010 17:57:26 Andrew Lenharth wrote: > On Wed, Jul 14, 2010 at 10:54 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > > On Wed, Jul 14, 2010 at 8:33 AM, Andrew Lenharth <andrewl at lenharth.org> wrote: > >> On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > >> Is alignment on a field