similar to: [LLVMdev] CVS Mirror

Yeah, that's fine. I'll change it soon. Reid. On Thu, 2005-04-21 at 18:32 +0200, Markus F.X.J. Oberhumer wrote: > Reid Spencer wrote: > > On Thu, 2005-04-21 at 17:56 +0200, Markus F.X.J. Oberhumer wrote: > > > >>Reid Spencer wrote: > >>> If a specific value for these is > >>> needed on a given platform, then we need to implement

Michael, I've implemented a LOADABLE_MODULE feature in the makefiles: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050110/023147.html The approach taken is almost what you described below. However, I want to retain the distinction between a "regular" shared library and one that can be dlopened. So, if you specify SHARED_LIBRARY=1 you get a regular shared library

Yep, it sounds like a good solution, and it works for me - thanks! -mike On Mon, 10 Jan 2005 20:40:34 -0800, Reid Spencer <reid at x10sys.com> wrote: > Michael, > > I've implemented a LOADABLE_MODULE feature in the makefiles: > > http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050110/023147.html > > The approach taken is almost what you described

Why not put all this into a pre-commit filter in CVS and be done with it? We'd never be bothered with it again as it would never be committed again. Reid. On Thu, 2005-04-21 at 15:11 -0500, Misha Brukman wrote: > Dear LLVMers, > > If you live on the bleeding edge (i.e. CVS version), please read! > > On Wed, Apr 20, 2005 at 12:12:54PM +0200, Markus F.X.J. Oberhumer wrote:

On Mon, 11 Oct 2004 08:08:56 -0700 Reid Spencer <reid at x10sys.com> wrote: > FWIW, I agree that the current situation with llvm-gcc is not ideal, but > most of us just build llvm-gcc once and forget about it. The real > solution here is to endow LLVM with its own C/C++ compiler and bootstap, > but that's a longer strategy. > > Reid. While I agree this would be the

Folks, I have recently committed several lib/System changes. As with previous commits, the changes work on Linux but for other platforms I'm only "guessing" at the implementation based on available documentation. Your mileage might vary. If this breaks compilation on your platform, please correct the implementation and check it in or submit patches to me and I'll check it in.

On Thu, 2005-04-21 at 17:56 +0200, Markus F.X.J. Oberhumer wrote: > Reid Spencer wrote: > > If a specific value for these is > > needed on a given platform, then we need to implement something like > > "getDefaultUserId" and "getDefaultGroupId" functions in lib/System and > > use those in lib/Bytecode/Archive. > > That's probably the

John, The point I was trying to make (and obviously didn't) was that because automake can make the mechanics of building/testing/packaging a release so much easier (one command), it is possible for this to be automated regularly (e.g. nightly test). Consequently, the problems only seen when building a distribution would be available much sooner than the week before the release. Distribution

On Tue, 12 Oct 2004, Jeff Cohen wrote: > On Mon, 11 Oct 2004 08:08:56 -0700 > Reid Spencer <reid at x10sys.com> wrote: > > > FWIW, I agree that the current situation with llvm-gcc is not ideal, but > > most of us just build llvm-gcc once and forget about it. The real > > solution here is to endow LLVM with its own C/C++ compiler and bootstap, > > but

Markus, This patch can't be applied. Not all platforms have getgid() and getuid () functions. Placing non-portable code outside of lib/System is deprecated. We set the values to 1000 by default because in general the uid/gid doesn't matter in an archive and the 1000 value gets you to a safe (non-root, non-system) value. If a specific value for these is needed on a given platform, then we

On Wed, Apr 20, 2005 at 12:12:54PM +0200, Markus F.X.J. Oberhumer wrote: > Misha Brukman wrote: > >On Tue, Apr 19, 2005 at 07:01:40AM +0200, Markus F.X.J. Oberhumer > >wrote: Have you considered using bugpoint for your codegen debugging > >needs? http://llvm.cs.uiuc.edu/docs/Bugpoint.html#codegendebug > > Well, the (critical) bug in question was >

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

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

On Thu, 21 Apr 2005, Reid Spencer wrote: > Why not put all this into a pre-commit filter in CVS and be done with > it? We'd never be bothered with it again as it would never be committed > again. I'd rather not have CVS commit scripts mucking with the code. If you want to have the nightly tester whine about source code with spaces at the end of lines (like it whines about

And, one more weird thing in this function. The FILESize static variable is never initialized so its likely initial value is 0 due to zero fill on many MMUs. The value is never written and used as a divisor. Why hasn't this function caused an arithmetic violation? Because the IOBBase point, also a static variable is initialized to zero and never modified and used in a conditional that thwarts

LLVMers, I've hacked Brian's BitterMelon demo to include Stacker and bytecode analysis information. You can try it out on the mirror at: http://llvm.x10sys.com/demo/index.cgi A new language radio buttons below the text input area permits Stacker input to be compiled and there is an extra option for generating bc data with llvm-bcanalyzer. If you're new to LLVM, try pasting the

On Thu, 19 May 2005, Reid Spencer wrote: > I forgot to remove some crud from the configure script and it caused > some of the nightly testers to fail last night. The problem has already > been fixed. Part of the problem was that it took 2 hours to get a commit > through to CVS last night and the nightly tester had already started by > that time. Something needs to be done about the

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

I'll wait for the research. We should try, as much as possible, to make it work with just what the compiler provides and without third party packages. Thanks, reid. On Fri, 2004-09-24 at 07:46, Jeff Cohen wrote: > I added the include of cstudio and it fails with plain VC7.1; the file > does not exist. > > Add it for now. If it is impossible to build with VC7.1 and without

I mis-stated what I think should be deleted. The block of code from "GlobalVariable *IOB = 0;" to the end of the loop should be delted because the only effect the loop has is on the IOB variable and that variable is never used after the loop. Reid. On Tue, 2004-05-11 at 18:14, Reid Spencer wrote: > Hi, > > I'm working on bug 122, consolidating the interface to the