similar to: [LLVMdev] LLVM namespace

Whoops, I forgot to cc the list. Sorry. ----- Forwarded message from "Brian R. Gaeke" <gaeke at uiuc.edu> ----- Date: Thu, 13 Nov 2003 15:35:34 -0600 From: "Brian R. Gaeke" <gaeke at uiuc.edu> To: Reid Spencer <reid at x10sys.com> Subject: Re: [LLVMdev] Headers & Libraries Hi Reid, Sorry I can't go into as much detail as your question did right

I just found "entry". Its the name I gave a basic block at the start of the function (name was hard coded in the compiler, not the source). The issue here is probably that the block doesn't have a terminating instruction. However, that fact used to be caught well by the validator. Furthermore, the output from the byte code reader is a little confusing given the source of the

I'm forwarding this bug resolution because it has a pretty wide impact on LLVM developers. This bug (451) has been resolved (well, works for me anyway). If you have reconfigured your build tree since October 4th, you need to reconfigure again. The bug produced shared objects that don't have a .so extension. Reconfiguring will fix this problem. The notes below show what was needed to

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

Reid Spencer wrote: > John, > > The rsyncd doesn't seem to be up. See the attached email. The mirror > tries to sync every 30 minutes and this is what I'm getting from the > cron job. This was from the sync attempted at 2:12pm (PDT) today. I think I got it working. Can you try it again and let me know if it works? Thanks. -- John T. > > Reid. > > John

On Tue, 2003-11-18 at 15:11, Vikram Adve wrote: > This is a hot topic in the compiler research community, but the focus > there is on > (a) choosing the right optimization sequences internally and > transparently, rather than through combinations of options, > (b) performance prediction techniques so you don't actually have to run > gazillion different choices, and perhaps

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:

The XPL compiler produced the attached OneOfEach.bc file without error or warning from either LLVM or XPLC. However when I llvm-dis the file, I get: llvm-dis: Failed value look-up for name 'entry' The Bytecode Reader prints this out when it can't find the associated value for the name. Obviously I botched something in the XPL compiler but I would have thought the verified would

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

Here are the FreeBSD and Win32 versions of TimeValue.cpp (along with all the other Win32 changes I've submitted that have yet to be comitted). Note there is a bug in all the Unix versions in that the time is not being converted from the Posix origin of 1/1/1970. On Fri, 24 Sep 2004 22:06:37 -0700 Reid Spencer <reid at x10sys.com> wrote: > This should be fixed. Sorry for the

Yes, pretty much. There are a few things that will go in the std namespace because its the way it is and a more natural fit. The other two namespaces already in use (cl and DOT) will be placed under the llvm namespace. The goal is to get everything that is currently at top level and put it in llvm. This means that in your programs, you wouldn't use: cl::XYZ anymore but: llvm::cl::XYZ. Or,

Okay, I'll fix that. But something *WILL* have to change, its not gratuitious. The "-c" option is in an enum which also has a "llvm" value which conflicts with the namespace name and caused a compilation error. To avoid the error, I changed "llvm" to "llvm_code". To be consistent, I changed the "c" enumeration to also have the same suffix,

Congratulations, Chris & LLVM Team. Having read nearly all the commit notices for this release I can attest to the amount of work that's gone into this release. Unfortunately, my contributions were meagre but I look forward to doing more for the 1.3 release now that I'm settled in Seattle. I'm looking forward to finally constructing my compiler with LLVM over the coming weeks.

Congratulations, Chris & LLVM Team. Having read nearly all the commit notices for this release I can attest to the amount of work that's gone into this release. Unfortunately, my contributions were meagre but I look forward to doing more for the 1.3 release now that I'm settled in Seattle. I'm looking forward to finally constructing my compiler with LLVM over the coming weeks.

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

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

On Fri, 20 Aug 2004 08:52:28 -0700 Reid Spencer <reid at x10sys.com> wrote: > Hi Jeff, > > On Fri, 2004-08-20 at 08:07, Jeff Cohen wrote: > > OK. I've built the front end without any heartaches, but I did > > encountered the following glitches: > > > > The documentation of --with-llvmgccdir is a bit ambiguous. I had to > > try several paths

The only thing I can think of is that string.h is being #included and has different signatures for memcpy and strncpy. Possibly "char" is not signed on your machine (very unusual) or some of the parameters are declared as "const". Reid. On Wed, 2004-04-14 at 18:19, Eric Zimmerman wrote: > Chris, > > I'm fine with using JIT, but I'm trying to understand this

Hi Chris, Congrats on getting this taken care of finally. I know its something you've wanted to do since 1.0. I have one question. How does LLVM disambiguate between a uint used for a structure and a uint used for an array? My assumption is that LLVM is aware of the type of the thing being indexed all the way through the dereference so it doesn't really matter what index type is being

Oops .. pardon my last incomplete posting, pushed Ctrl-Enter by accident! As I was saying .. Rahul's idea is interesting and would make some aspects of LLVM programming easier, but I wouldn't use it in my source language for the following reasons: 1. Of necessity the "snippet parser" would need to be based on the same language/grammar as AsmParser. Allowing parsing and