similar to: [LLVMdev] Bugzilla Email On The Blink?

On Mon, 17 Nov 2003, Reid Spencer wrote: > I've noticed in the last day that I'm not getting any Bugzilla email any > more. I haven't changed my settings in Bugzilla. Did something change > at UIUC? I don't think so... I'm still getting plenty of bugzilla mail. :) -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/

Hi, I'm working on bug 122, consolidating the interface to the SymbolTable class. In doing so, I found the function below which traverses the symbol table but apparently unnecessarily. Before I remove the traversal, I thought I better check with you guys. Posted this to the list because it looks like _everyone_ has edited this file :) In the code below, the IOB variable is the only thing in

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

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

I'm cross-posting the message below (from GCC list) because I believe it would (at some point) be very beneficial to build an evolutionary optimization pass into LLVM. The idea would be to discover the perfect set of optimizations for a given program by trying them all and analyzing the execution times of each. This would be somewhat like profile driven optimization except the profile is

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

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: > Do you really want external patches for this ? A simple Perl script > that runs on all *.h and *.cpp files, and a local commit from your > side would be much simpler. I'm in the process of doing just this as we speak. What this

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 can even avoid the problem of choosing representative inputs, as you talked

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:

Hi all, I just checked in a series of patches that makes some substantial changes to the LLVM getelementptr instruction. In particular, in LLVM 1.2 and earlier, the getelementptr instruction required index operands for structure types to be 'ubyte' constants and index operands for sequential types to be 'long' values. This had several problems, most notably that it was

On Sun, 10 Apr 2005, Markus F.X.J. Oberhumer wrote: > sys::Program::ExecuteAndWait() requires that the first element in "args" > should be the name of the program, but (at least) llvm-ld.cpp and gccld.cpp > fail to do so, thereby effectively swallowing the first parameter. > This is the reason that -native-cbe has not working for some time - actually > I wonder why no

On Thu, 21 Apr 2005, Reid Spencer wrote: > With Misha's changes requiring a total rebuild, I've been reminded how > long the targets take to build. Now that there are more of them and in > most cases I really don't care about n-1 of them, I'm wondering if its > time to have configure allow optional compilation for them. > > I would like to suggest: > > 1.

Dear, im using mingw and as under win xp. "Vyacheslav, This is the same problem that I had with Cygwin .. nearly identical. The issue was documented in PR492 if you want some background. I'm currently trying to dig up what I did to fix this in December for Cygwin and see if I can apply the same change for mingw. " im dont understand. What is pr492? (url) and where is the fix for

On Wed, Apr 27, 2005 at 10:28:30PM +0200, Thomas Lodenscheidt wrote: > im dont understand. What is pr492? (url) http://llvm.cs.uiuc.edu/PR492 -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu

> What's the current status of the test suite. After putting everything > in the llvm namespace and getting everything to link, I am getting=20 > only about 75% of the tests passing. Is this to be expected or have > I broken something? I think that you broke something, specifically the C backend. See this comment for details: http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=109#c12

I am trying to obtain native code from the bytecode by using commands: % llc hello.bc -o hello.s % gcc hello.s -o hello.native This is working for a simple program( a single source file) but when I try to run it on grep utility (grep.bc) , it gives me the following error: $ llc grep.bc -o grep.s $ gcc grep.s -o grep.native /tmp/ccY3oNAA.o(.text+0x2f2f): In function `main': :

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

With Misha's changes requiring a total rebuild, I've been reminded how long the targets take to build. Now that there are more of them and in most cases I really don't care about n-1 of them, I'm wondering if its time to have configure allow optional compilation for them. I would like to suggest: 1. The default (build all targets) remains the same 2. We add to configure

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

On Thu, 2005-21-04 at 19:43 -0700, Reid Spencer wrote: > In case it wasn't obvious from Misha's answer, the main reason for > doing this is speed. RTTI is not very quick. Right. This is why I was somewhat suprized to see the "isa" facilities included in LLVM without also disabling rtti. It will reduce the memory footprint a fair bit if you do disable it, at least based on