similar to: [LLVMdev] Compile error in include/Support/GraphWriter.h

Bill? Wendling wrote: >Also sprach Casey Carter: >} Issue: GraphWriter includes <ostream>, which my gcc2 apparently thinks >} is <ostream.h>. >} Fix: Make a new <Support/ostream> that handles this discrepancy, ala >} <Support/hash_set>. >} >Um...was it entirely necessary to issue *8* email messages to the group >with mostly single-line fixes

Also sprach Casey Carter: } Issue: GraphWriter includes <ostream>, which my gcc2 apparently thinks } is <ostream.h>. } Fix: Make a new <Support/ostream> that handles this discrepancy, ala } <Support/hash_set>. } Um...was it entirely necessary to issue *8* email messages to the group with mostly single-line fixes instead of just one email with all of the fixes and an

Also sprach Casey Carter: } Bill? Wendling wrote: } } >Um...was it entirely necessary to issue *8* email messages to the group } >with mostly single-line fixes instead of just one email with all of the } >fixes and an explanation for each? } > } > } > } Actually, yes it was. Proper netiquette when submitting to a technical } list is to have a single topic per message. This

So, I had to make a few changes to the llvm sources to allow compilation on x86 redhat 7.3 (gcc-2.96, glibc 2.2.4). Is there any general interest in maintaining a port? I will happily submit patches. -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69

ISSUE: In Interpreter::getCurrentExecutablePath(), dladdr() is a Solarisism. Luckily, getCurrentExecutablePath isn't being currently used anywhere in lli. ACTION: Wrap the method contents with #ifdef __sun__ ... #else return ""; #endif. If this functionality is actually desired, it would be more portable to hack up main() to join getcwd() with basename(argv[0]) to find the

Chris Lattner wrote: >>>Interesting. INT64_MAX is supposed to be provided by >>>include/Support/DataTypes.h. Do you know of a reliable preprocessor >>>symbol that can be used to determine whether we're on a linux box, or >>> >>> > > > >>Well, there is always __linux__, but that doesn't necessarily imply that >>we

ISSUE: This code: %bob = type { int } int %alias() { %pbob1 = alloca %bob %pbob2 = getelementptr %bob* %pbob1 ;pbob2 aliases pbob1 %pbobel = getelementptr %bob* %pbob2, long 0, ubyte 0 %rval = load int* %pbobel ret int %rval } Crashes when run through opt -instcombine. InstCombiner visits instructions in reverse declaration order, but

ISSUE: INT64_MAX undefined in InstrSelectionSupport.cpp and InstructionCombining.cpp. I'm not completely sure where INT64_MAX comes from on Solaris, but C99 says that INT64_MAX is defined in stdint.h, but, for C++, only if __STDC_LIMIT_MACROS is #defined. Solaris (at least in CSIL) unfortunately does not have stdint.h, but it does have the old inttypes.h - and so does Linux. ACTION: In

Hi. I'd like to know where LLVM installs the GraphWriter.h file on a standard install. I'd like to know this to avoid any possibility of overwriting it with software that I am developing. Please CC me as I'm off list. Thanks! Paul Blackburn

Chris Lattner wrote: >>ISSUE: INT64_MAX undefined in InstrSelectionSupport.cpp and >>InstructionCombining.cpp. I'm not completely sure where INT64_MAX comes >>from on Solaris, but C99 says that INT64_MAX is defined in stdint.h, >>but, for C++, only if __STDC_LIMIT_MACROS is #defined. Solaris (at >>least in CSIL) unfortunately does not have stdint.h, but it does

Hi all, I have two questions related to .dot graph output. Basically, I have a graph representing a program dependence graph like structure with (a) multiple edges between the same pair of nodes (b) each edge having a special (different) text/label I implemented a template-specialized version of DotGraphTraits for the my graph structure which given a node, uses a map_iterator (similar to the one

Hello Prakash, The SelectionDAG viewers (llc -view-isel-dags etc.) support both multiple edges between the same pair of nodes, and labels at least for each incoming edge. See lib/CodeGen/SelectionDAG/SelectionDAGPrinter.cpp for code you might use as an example, though it is a bit tricky. Dan On Sep 15, 2008, at 3:15 PM, Prakash Prabhu wrote: > Hi all, > > I have two questions related

I can't seem to figure out how to tell the PassManager that one Pass requires the results of two other Passes, in such a way that it will not crash itself. Attached file is the simplest possible example of Passes A, B, and C, such that C's getAnalysisUsage(AU) method calls AU.addRequired<A>() and AU.addRequired<B>(). When I try to run opt -load ... -opt-c, it tells me:

Hi Dan, Thanks for the reply. I got the labels for each outgoing edge (at the source node's 'structure' field) working. Is there a way to find out the outgoing edge number from EdgeIter. (Basically the Node in my graph has a a bunch of outgoing edges, so that I can just index into that collection within the node to get the appropriate edges' attributes). regards, Prakash On Tue,

I just wanted to mention that there is a new global makefile target "make cleandeps", which recursively walks through the source tree, deleting .d files, without removing anything else. This is useful when you update from CVS, and find out that there has been a header file removed. Before you'd have to go in and remove the outdated .d manually, now you can just run 'make

> so i confess i'm still not clear on what the first index into > getelementptr is all about. I'm sure you're not the only one. :) This is one of the wierdest aspects of LLVM to the unaccustomed. > it makes perfect sense for an example like > getelementptr %mystruct * %reg100 > to just return a %mystruct * equivalent to %reg100. > > it does *not* make sense to

PreSelection.cpp uses the form "++(ConstantExpr*)->op_begin()" in a couple of places: gcc2 considers this to be an illegal use of a constant reference (the temporary iterator) as an lvalue. Fix is to use "(ConstantExpr*)->op_begin() + 1" instead. -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69 -------------- next part -------------- An

Hi Prakash, I don't know of an easy way to do this, other than to use random-access iterators so you can compute the distance between the edge and the beginning of the list of edges. Dan On Sep 16, 2008, at 2:58 PM, Prakash Prabhu wrote: > Hi Dan, > > Thanks for the reply. I got the labels for each outgoing edge (at the > source node's 'structure' field) working. Is

Chris Lattner wrote: >>I don't grok this error message. Of course, -opt-a and -opt-b both work >>fine in isolation. >> >> > >You're right, this error message is terrible. As it turns out, all of >your passes invalidate all of the other passes, so C doesn't get A (which >is invalidated by B). The problem turns out to be a really trivial bug:

Hi, I am trying to generate the DFG of machine functions. Initially, I added a pass to generate the DFG of LLVM IR functions. This was based on the mail thread - http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025582.html. This pass worked fine and I was able to generate DFG of LLVM IR functions. Later, I ported the DFG pass code for machine functions. I ported the InstIterator.h