similar to: [LLVMdev] utils/Burg Makefile fails

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>. -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL:

In case others are interested in what happened with Casey's patches, here's the digest: > Issue: STLExtras.h includes a class mapped_iterator that uses > std::iterator_traits<> without including <iterator>. > Fix: have STLExtras.h include Support/iterator. Applied. > DSGraph.h has a prototype in it with a std::string& parameter, but does > not include

Issue: STLExtras.h includes a class mapped_iterator that uses std::iterator_traits<> without including <iterator>. Fix: have STLExtras.h include Support/iterator. -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL:

DSGraph.h has a prototype in it with a std::string& parameter, but does not include <string>. -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20021027/a98ab220/attachment.ksh>

Statistic.cpp uses std::stable_sort without including <algorithm>. -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20021027/4d75abdc/attachment.ksh>

Timer.cpp uses std::greater without including <functional>. -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20021027/b70e3ac4/attachment.ksh>

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

Another "big unsigned constant for 32-bit architecture" warning. -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20021027/0ea3a8ff/attachment.ksh>

ISSUE: Changing definitions in Makefile.common by hand from Solaris to Linux values offends me. ACTION: As a quick fix to this (i.e., w/o autoconf) I have separated out the different settings into new files Makefile.$(PLATFORM) in the top-level directory of llvm. A dirty hack to Makefile.common automatically includes the proper arch-specific file by setting PLATFORM to the output of uname.

For your listening pleasure, I got tired of seeing these unnecessary warnings from make, so I changed the line from include xxx to -include xxx to make make be quiet. -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: p URL:

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

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

Does our pass need to ensure that the new names it creates for the field allocations are, in fact, unique? -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69

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:

ISSUE: In CommandLine.h, gcc 2.96 thinks that the apply() template function, when called as: apply("Some text string", x) should be expanded to applicator<const char[n]>("Some text string", x) instead of applicator<char[n]>("Some text string", x). ACTION: Duplicate the template specialization for applicator<char[n]> as applicator<const

ISSUE: In Interpreter::executeInstruction(), _sys_siglistp is a Solarisism. ACTION: Replace _sys_siglistp[signo] with strsignal(signo) which is more portable, maybe POSIX? PATCH: Apply from llvm top-level directory with "patch -p0." -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69 -------------- next part -------------- An embedded and charset-unspecified text