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 >
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20041111/bc4835ad/attachment.sig>
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 >
> 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.The test could always be marked XFAIL for FreeBSD. This can easily be done with the dejagnu support. Other ideas are that certain directories in the test suite could only be run on certain platforms (also easily done with dejagnu). -Tanya
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/