[LLVMdev] install-bytecode no longer works

Jeff Cohen jeffc at jolt-lang.org
Thu Nov 11 20:23:00 PST 2004


Oh, I don't have to change any semantics...  FreeBSD has alloca(); it's
just not declared in alloca.h.  It's declared in stdlib.h.  I have to
admit I don't understand why alloca has to be declared in different
fashions on different flavors of Unix even though they use the exact
same gcc.  Anyway, the hack appears to be working...

I haven't run llvm/test yet...  I want to try dejagnu and I haven't
gotten around to setting it up yet.


On Thu, 11 Nov 2004 20:18:19 -0800
Reid Spencer <reid at x10sys.com> wrote:

> This kind of thing is one of the many reasons we broke llvm-test out to
> a separate project. It has multiple purposes. Its a correctness test on
> LLVM, its what we base our compiler benchmarks on, and its also where a
> lot of the research gets done. You've been bitten by the latt(n)er. :)
> 
> At some point I'd like to see us make some distinctions so that there is
> a correctness test suite whose goal is to always  work on all platforms.
> To date the llvm/test/{Regression,Feature} provide that capability in a
> very minimal way. 
> 
> You're probably best to just define alloca as malloc in alloca.h and
> just hope it doesn't break semantics.
> 
> Reid.
> 
> On Thu, 2004-11-11 at 20:06, Jeff Cohen wrote:
> > No, I don't feel strongly about it...  it's just annoying to have things
> > change on me that break habits :)
> > 
> > On the other hand, I do feel strongly about the tests in llvm-test that
> > are now failing on me because they explicitly include alloca.h, a file
> > that does not exist on FreeBSD.  I can supply a patch to take out the
> > include, of course, but the problem then becomes that the tests will
> > then fail on other Unix platforms.  Some way is needed to make the tests
> > platform-independent.  As a workaround for now I guess I can add an
> > empty alloca.h file.
> > 
> > On Thu, 11 Nov 2004 09:43:12 -0800
> > Reid Spencer <reid at x10sys.com> wrote:
> > 
> > > The default prefix is /usr/local but I would recommend that when you
> > > configure LLVm you do so with:
> > > 
> > > configure --prefix=/me/llvm/install/dir ...
> > > 
> > > so that installation occurs in a place you have write access. If you
> > > feel strongly about restoring the install-bytecode target, feel free to
> > > file a bug.
> > > 
> > > Reid.
> > > 
> > > On Thu, 2004-11-11 at 09:12, Jeff Cohen wrote:
> > > > Wow...  it is nearly twice as fast.  But it tried to install stuff in
> > > > /usr/local (and as I wasn't root...) and it didn't do that before.  As I
> > > > don't care about profiling or tracing, I didn't bother to su and do it
> > > > again.
> > > > 
> > > > On Wed, 10 Nov 2004 23:45:35 -0800
> > > > Reid Spencer <reid at x10sys.com> wrote:
> > > > 
> > > > > The entire makefile system was rewritten a couple of weeks ago. This is
> > > > > a good thing, your compiles now go twice as fast. Resistance is futile,
> > > > > just adapt :)
> > > > > 
> > > > > The install target installed the bytecode libs into CFEINSTALL as before
> > > > > and also installs the native libraries to your prefix/lib directory.
> > > > > This is intentional.
> > > > > 
> > > > > Reid
> > > > > 
> > > > > On Wed, 2004-11-10 at 23:32, Jeff Cohen wrote:
> > > > > > But there already was an "install", and it did far more than install the
> > > > > > bytecode files.  That changed too?
> > > > > > 
> > > > > > 
> > > > > > On Wed, 10 Nov 2004 23:28:27 -0800
> > > > > > Reid Spencer <reid at x10sys.com> wrote:
> > > > > > 
> > > > > > > Yeah, its just "install" now.
> > > > > > > 
> > > > > > > I'll fix the documentation.
> > > > > > > 
> > > > > > > Reid.
> > > > > > > 
> > > > > > > On Wed, 2004-11-10 at 23:19, Jeff Cohen wrote:
> > > > > > > > My rebuild from scratch has hit this snag.  The instructions still call
> > > > > > > > for running "gmake -C runtime install-bytecode", but this target no longer exists. 
> > > > > > > > 
> > > > > > > > _______________________________________________
> > > > > > > > LLVM Developers mailing list
> > > > > > > > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > > > > > > > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
> > > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > LLVM Developers mailing list
> > > > > > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > > > > > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > LLVM Developers mailing list
> > > > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > > > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
> > > 
> > 
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
> 




More information about the llvm-dev mailing list