similar to: [LLVMdev] Porting to x86 Linux

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

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:

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

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:

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

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: line 474 of InstrSelectionSupport.cpp is a conditional expression of the form (<expr> ? (ConstantSInt*) : (ConstantUInt*)), which is an unholy mixture of pointer types. ACTION: Apply static_cast<Value*> to the two pointers, as the source intends. -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69 -------------- next part -------------- An embedded and

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

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

ISSUE: getTimeRecord in lib/VMCore/Pass.cpp uses timeval and gettimeofday() without including sys/time.h. ACTION: Include sys/time.h. 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 was scrubbed... Name: patch URL:

ISSUE: ExternalFunctions.cpp::lookupFunction() calls dlsym(RTLD_DEFAULT, ...). In glibc, dlfcn.h does not make RTLD_DEFAULT visible unless _GNU_SOURCE is #defined. Unlike the evil money-grubbing non-free software pigs at sun, the FSF is trying not to pollute the C namespace. ;) ACTION: Hack the Makefile to #define _GNU_SOURCE while compiling in tools/lli. Yes, I know that this is ugly.

ISSUE: Linux doesn't have any steenking SIGEMT signal, as referred to in lib/Support/Signals.cpp. ACTION: Wrap the use with a #ifdef SIGEMT / #endif. 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 was scrubbed...

ISSUE: DSOs in Linux are created by "g++ -shared" instead of "g++ -G". ACTION: Compile with "g++ -shared" instead of "g++ -G", i.e., use the alternate definition of "MakeSO" in Makefile.common. PATCH: Apply from llvm top-level directory with "patch -p0". -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69

ISSUE: By default, symbols are not exported from an executable unless they are linked against a DSO. What this means is that dlopen()ed DSOs cannot link to symbols in the main executable unless that executable was linked with --export-dynamic. ACTION: Ensure that opt is linked with "-Wl,--export-dynamic" on the G++ command line by defining "ExportSymbols" in

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.

Chris Lattner wrote: >>test for linux / definition of __STDC_LIMIT_MACROS. This will not work, >>since stdint.h is implemented by including inttypes.h, which was already >>included the first time with __STDC_LIMIT_MACROS not defined. I think >>the best solution to this problem is to change DataTypes.h to simply: >> >> #define __STDC_LIMIT_MACROS >>

Like the subject says. -- 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/20020917/496d0a9c/attachment.ksh>