similar to: Extra environment variable breaks wine

On Monday 25 April 2005 14:43, Vladimir Prus wrote: > The 'i' variable is never modified in the program, however, all analyses > except for -globalsmodref-aa report that the > > %tmp.3 = call int %_Z3bari( int %p ) ; <int> [#uses=1] > > instruction can modify 'i'. I'm somewhat surprised, because it looks like > -globalsmodref-aa is the simplest

Okay, let me test with exactly your options and I'll let you know what I get. Reid. On Wed, 7 Jul 2004 19:53:15 +0400 Vladimir Prus <ghost at cs.msu.su> wrote: > Reid Spencer wrote: >> Volodya, >> >> I think you may need to update your CFE and rebuild. I compiled the test >> using my local build and I didn't get the results you see below. I'm

Okay, I've replicated your results, but I don't think there's an error here, its just not nice output from the disassembler. The first %tmp.ll is of type long. The second one is of type short. I think that's valid for LLVM. That is, the SSA form depends on both the type and name of the virtual register. In any event, llvm-as seems to compile the llvm-dis output just fine. Make

Hello, I'm playing with alias analysis, using the following program: %i = external global int ; <int*> [#uses=2] implementation ; Functions: int %_Z3bari(int %p) { entry: %tmp.0 = load int* %i ; <int> [#uses=1] %tmp.1 = setgt int %tmp.0, 10 ; <bool> [#uses=1] br bool %tmp.1, label %then, label %UnifiedReturnBlock then:

i don't know the status of nci, but suif/suif2 development and publication is very active. it's will be great if there are tools to transform llvm ir and suif ir to each other. acutally, i didn't use suif but llvm just because suif cannot be compiled by visual studio.net (but visual studio 6). On 5/10/05, Vladimir Prus <ghost at cs.msu.su> wrote: > On Tuesday 10 May 2005

Reid Spencer wrote: > Volodya, > > I think you may need to update your CFE and rebuild. I compiled the test > using my local build and I didn't get the results you see below. I'm > also very surprised to see this output. The first %tmp.11 should have > been %tmp.1 .. not sure how it got corrupted. In any event, the > attachment is obviously generated by code that runs

Vladimir Prus <ghost at cs.msu.su> writes: > Why do you really need distributed development? The possible problems with > centralized development are > 1. The server might be often down. > 2. There's too much number of active branches, so nobody understand what's > going on. > 3. You can't commit while you're on a plane. Replace 3 with "You have no

On 9/23/05, Vladimir Prus <ghost at cs.msu.su> wrote: > In fact, I believe that > > using namespace llvm; > using namespace boost; > using boost::tie; > > should resove the problem witout needed to explicitly nominate all boost names > you use. Except that this does not work on global scope, but only in > namespace: <SNIP> Also, it might be an idea

Chris Lattner wrote: > > Right, but you'd need HTTP/FTP server. Not a problem for *me*, but lots > > of folks are behind firewalls and can't do that. > > Sure. I can't imagine that there is a wonderful solution other than this > though. In particular, how can you do distributed development without it? > The whole idea is to reduce the need for a completely

Chris Lattner wrote: > On Thu, 16 Mar 2006, Vladimir Prus wrote: >> Ah, hell, as soon as I've send this email I've updated from CVS to find >> that the issue was fixed by Jim several hours after I reported the crash, >> by making MachineDebugInfo don't check for empty name of type. > > :) > >> Here's what I get now: >> >>

On Thursday 22 September 2005 19:12, Chris Lattner wrote: > On Thu, 22 Sep 2005, Tzu-Chien Chiu wrote: > > On 22/09/05, Bill Wendling <isanbard at gmail.com> wrote: > >> Couldn't you state the explicit namespaces. So not using "using > >> namespace llvm" and instead prefix all calls with "llvm::"? > > > > The header files in

I've just had some fun, because I wanted to override FunctionPass::addAnalysisUsage, but forgot "const" after the method name -- so instead of overriding I've just created a new unrelated method. After spending some time on this, I've decided to add -Woverloaded-virtual option to compiler to catch such cases. However, it also gives some warnings on LLVM code:

Vladimir Prus wrote: > > I'm getting this: > > /home/ghost/Work/llvm-cvs/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp: > In > member function `void > llvm::SelectionDAGLowering::visitSetCC(llvm::User&, > llvm::ISD::CondCode, llvm::ISD::CondCode, llvm::ISD::CondCode)': > /home/ghost/Work/llvm-cvs/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1107:

Chris Lattner wrote: > Here's a new snapshot of the front-end: > http://nondot.org/sabre/2006-03-14-llvm-gcc-4.tar.gz > > This: > > 1. Fixes the inline asm problem you have above. > 2. Includes patches to make it better on Alpha's (thanks to patches by > Andrew Lenharth). > 3. Sync's it up with debug info changes in LLVM CVS (by Jim Laskey). > 4.

Suppose I have a target that does not have register+constant addressing mode. Then, I have DAG like: (store ..., (frameindex)) Targets like SPARC have the following patterns to catch this: def ADDRri : ComplexPattern<i32, 2, "SelectADDRri", [frameindex], []>; def STri : F3_2<3, 0b000100, (outs), (ins MEMri:$addr, IntRegs:$src),

On Dec 3, 2007, at 12:53 PM, Vladimir Prus wrote: > > Suppose I have a target that does not have register+constant > addressing mode. Then, I have DAG like: > > (store ..., (frameindex)) > > Targets like SPARC have the following patterns to catch this: > > def ADDRri : ComplexPattern<i32, 2, > "SelectADDRri", [frameindex], []>; > def STri :

Evan Cheng wrote: > > On Dec 3, 2007, at 12:53 PM, Vladimir Prus wrote: > >> >> Suppose I have a target that does not have register+constant >> addressing mode. Then, I have DAG like: >> >> (store ..., (frameindex)) >> >> Targets like SPARC have the following patterns to catch this: >> >> def ADDRri : ComplexPattern<i32, 2,

Evan Cheng wrote: > Hi, > > Here is the follow on patch for this problem. Please apply this from > the top of the tree and rebuild. With the patch from Chris and then the patch from you combined, the previous error disappeared, but I get another error, reduced to this: ./cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mtune=pentiumpro -auxbase-strip libgcc/./_clz.o -g -O2

On Wed, 5 May 2004, Oscar Fuentes wrote: > Vladimir Prus <ghost at cs.msu.su> writes: > > > Why do you really need distributed development? The possible problems with > > centralized development are > > 1. The server might be often down. > > 2. There's too much number of active branches, so nobody understand what's > > going on. > > 3. You

Chris Lattner wrote: > On Thu, 2 Mar 2006, Vladimir Prus wrote: >>>> The instructions seem to have one path wrong. It says to get: >>> >>> I'll put together a tarball today. That will be easier than dealing >>> with a patch, and it will include a bunch of bugfixes since the previous >>> email. >> Further into process, I get this error: