similar to: [LLVMdev] Just got bitten by accidentally using the wrong gcc

Am Freitag, den 21.03.2008, 06:56 -0700 schrieb Shantonu Sen: > I recommend you don't parse version strings. In fact I switch the > check to use AC_COMPILE precisely for the reason that gcc --version is > totally unreliable and vendor specific. For example, what's the > regular expression that tells you what the GCC version is: > i686-apple-darwin9-gcc-4.0.1 (GCC)

On Mar 20, 2008, at 3:00 PM, Joachim Durchholz wrote: > Hi all, > > I just forgot to ./configure with CC=gcc-4.2 CXX=g++-4.2, getting the > (broken-for-LLVM) gcc-4.1 as a compiler. > The error message that I got was this: > make[1]: Entering directory `/home/jo/llvm-wrk/lib/VMCore' > make[1]: *** No rule to make target > `/home/jo/llvm-wrk/Release/bin/tblgen',

llvm's ./configure already does that for gcc < 3. What are valid versions? Exactly 4.0 and 4.2? 4.0 and >=4.2? dnl Verify that GCC is version 3.0 or higher if test "$GCC" = "yes" then AC_COMPILE_IFELSE([[#if !defined(__GNUC__) || __GNUC__ < 3 #error Unsupported GCC version #endif ]], [], [AC_MSG_ERROR([gcc 3.x required, but you have a lower version])]) fi

Joachim Durchholz wrote: > Am Donnerstag, den 20.03.2008, 15:44 -0700 schrieb Tanya M. Lattner: > >> Its not just a matter of checking major/minor versions. It also depends on >> the target and in some cases the OS. >> http://llvm.org/docs/GettingStarted.html#brokengcc >> >> So for example, GCC 3.3.3 on Suse or GCC 3.4.0 on linux/x86 >> (32-bit) has

I recommend you don't parse version strings. In fact I switch the check to use AC_COMPILE precisely for the reason that gcc --version is totally unreliable and vendor specific. For example, what's the regular expression that tells you what the GCC version is: i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5470) (Aspen 5470.3) Per the rest of this thread, you can't

>> I just forgot to ./configure with CC=gcc-4.2 CXX=g++-4.2, getting the >> (broken-for-LLVM) gcc-4.1 as a compiler. >> The error message that I got was this: >> make[1]: Entering directory `/home/jo/llvm-wrk/lib/VMCore' >> make[1]: *** No rule to make target >> `/home/jo/llvm-wrk/Release/bin/tblgen', needed by >>

Hi all, I just forgot to ./configure with CC=gcc-4.2 CXX=g++-4.2, getting the (broken-for-LLVM) gcc-4.1 as a compiler. The error message that I got was this: make[1]: Entering directory `/home/jo/llvm-wrk/lib/VMCore' make[1]: *** No rule to make target `/home/jo/llvm-wrk/Release/bin/tblgen', needed by `/home/jo/llvm-wrk/lib/VMCore/Release/Intrinsics.gen.tmp'. Stop.

Am Donnerstag, den 20.03.2008, 15:44 -0700 schrieb Tanya M. Lattner: > Its not just a matter of checking major/minor versions. It also depends on > the target and in some cases the OS. > http://llvm.org/docs/GettingStarted.html#brokengcc > > So for example, GCC 3.3.3 on Suse or GCC 3.4.0 on linux/x86 > (32-bit) has issues. Is it easy to check these kinds of things? uname

Am Donnerstag, den 20.03.2008, 15:27 -0700 schrieb Shantonu Sen: > llvm's ./configure already does that for gcc < 3. > > What are valid versions? Exactly 4.0 and 4.2? 4.0 and >=4.2? There's a list at http://llvm.org/docs/GettingStarted.html#brokengcc so there is a reasonable basis. The list isn't comprehensive, of course, and will likely grow in the future. OTOH

> I guess it could be done for things like 4.1.1 or a couple of others on > the list. This gcc version always worked fine for me on ubuntu linux (though it might have been 4.1.2, I don't recall). Ciao, Duncan.

In general, the C++ compiler does NOT know the type of the leaf class when performing a virtual method invocation. In particular, a parameter (including "this") alleging to be a Foo* (Foo being some class) may actually be any subclass of Foo, so unless the compiler can trace the value flow all the way from the instantiation, it can't tell. The necessary tracing is (a) hard, (b)

On Mar 30, 2008, at 11:22 PM, Joachim Durchholz wrote: > > Am Sonntag, den 30.03.2008, 15:45 -0700 schrieb Tanya Lattner: >> On Mar 30, 2008, at 12:39 PM, Joachim Durchholz wrote: >> >>> >>> Am Sonntag, den 30.03.2008, 10:28 -0700 schrieb Tanya Lattner: >>>> On Mar 30, 2008, at 10:07 AM, Joachim Durchholz wrote: >>>>> Look at how

Am Sonntag, den 30.03.2008, 15:45 -0700 schrieb Tanya Lattner: > On Mar 30, 2008, at 12:39 PM, Joachim Durchholz wrote: > > > > > Am Sonntag, den 30.03.2008, 10:28 -0700 schrieb Tanya Lattner: > >> On Mar 30, 2008, at 10:07 AM, Joachim Durchholz wrote: > >>> Look at how $LLVM_CONFIGURE is built, the final value is > >>> > >>>

Am Montag, den 31.03.2008, 00:02 -0700 schrieb Tanya Lattner: > On Mar 30, 2008, at 11:22 PM, Joachim Durchholz wrote: > > > Am Sonntag, den 30.03.2008, 15:45 -0700 schrieb Tanya Lattner: > >> On Mar 30, 2008, at 12:39 PM, Joachim Durchholz wrote: > >> > >>> OK, I now have > >>> > >>> LLVM_VERSION_INFO=kurier-bootstrap

*bump* Anybody got a clue? I can post a full transcript of a shell session that reproduces the error if that helps. To reiterate the original problem: I'm trying to compile LLVM-GCC on an Ubuntu 64-bit box, with a 32-bit target (to avoid potential problems with PIC and such). I get errors like Error: suffix or operands invalid for `push' as soon as the make process tries to assemble

Am Freitag, den 04.04.2008, 11:19 -0700 schrieb Chris Lattner: > On Fri, 4 Apr 2008, Joachim Durchholz wrote: > >> No, please don't do this. The idea of llvmbuilder is that it is a > >> "free" wrapper around the other existing API calls. Making the > >> methods virtual would make them much more expensive. > > > > Wouldn't the class of

On Mar 30, 2008, at 12:39 PM, Joachim Durchholz wrote: > > Am Sonntag, den 30.03.2008, 10:28 -0700 schrieb Tanya Lattner: >> On Mar 30, 2008, at 10:07 AM, Joachim Durchholz wrote: >>> Look at how $LLVM_CONFIGURE is built, the final value is >>> >>> --prefix=/home/jo --enable-optimized --build=i686-pc-linux-gnu >>> --host=i686-pc-linux-gnu

It shoudl work fine if you set CC right and use --build --target --host == i686-pc-linux-gnu On Sun, Mar 30, 2008 at 10:40 AM, Joachim Durchholz <jo at durchholz.org> wrote: > Hi all, > > I managed to navigate around all those issues with environment variables > and such. llvm itself now builds and checks just fine, but I can't get > llvm-gcc to compile. > >

Am Mittwoch, den 05.03.2008, 23:03 -0800 schrieb Chris Lattner: > On Mar 3, 2008, at 2:49 AM, Joachim Durchholz wrote: > > > Hi all, > > > > I found enough to explain the behaviour that I encountered. If I'm > > correct, the bugs are just in the dejagnu-based test machinery, not in > > LLVM itself. > > Yep, I believe that. I haven't been

On Thu, May 15, 2008 at 1:38 AM, Joachim Durchholz <jo at durchholz.org> wrote: > > Am Dienstag, den 13.05.2008, 11:50 -0700 schrieb Bill Wendling: >> On Tue, May 13, 2008 at 2:24 AM, Joachim Durchholz <jo at durchholz.org> wrote: >> > >> > Am Dienstag, den 13.05.2008, 00:42 -0700 schrieb Bill Wendling: >> >> Sorry to step into this in the