On Thu, 11 Nov 2004, Reid Spencer 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.
llvm-test has many purposes, but it's is there foremost as end-to-end
tests for LLVM. The best way to do this, IMO is to take random programs
off the shelf and plunk them in there.
The problem with this, of course, is that these programs are often crufty,
maybe buggy, and often have portability problems.
I don't really see a solution to this: if we only accepted non-crufty,
non-buggy, portable programs, we would have an empty set of tests :)
The solution to this is just to hack on the programs where necessary.
I've fixed countless bugs in the programs in llvm-test and portability is
no different. As long as the spirit of the program stays alive (i.e. no
functionality changes) that is no problem.
Perhaps the right way to handle this particular problem is to add the
appropriate autoconf check to the llvm-test configure, then have the
programs that need alloca use the detected value?
-Chris
> 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
>
-Chris
--
http://llvm.org/
http://nondot.org/sabre/