search for: nocompileunit

...generic interface file for target. WARNING: Couldn't find tool config file for unix, using default. WARNING: Assuming target board is the local machine (which is probably wrong). You may need to set your DEJAGNU environment variable. ...FAIL: /home/jo/Delta/llvm-2.2/test/C ++Frontend/2006-11-30-NoCompileUnit.cpp Failed with exit(1) at line 2 while running: as NoCompileUnit.s -o NoCompileUnit.o NoCompileUnit.s: Assembler messages: NoCompileUnit.s:33: Error: suffix or operands invalid for `push' NoCompileUnit.s:52: Error: suffix or operands invalid for `pop' NoCompileUnit.s:64: Error: suffix or o...

...for x86-64 (so the compiler defaults to emitting x86-64 code) but your assembler defaults to x86-32. Thus, your assembler requires - m64 to be passed for it to grok 64-bit code, which isn't being passed by the test. Does it work if you change the top of that test to: ... // RUN: as -m64 NoCompileUnit.s -o NoCompileUnit.o .. ? -Chris > > $ make > $ make check > # Host is still wrong. > # Not sure whether the warnings are a problem. > # The used description files might be for x86_64 though. > ... > Target is i686-pc-linux-gnu > Host is x86_64-unknown-linux-gnu >...

On Feb 29, 2008, at 4:05 PM, Joachim Durchholz wrote: > > Am Freitag, den 29.02.2008, 15:37 -0800 schrieb Eric Christopher: >> Aaah. Try: >> >> .../configure --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu >> >> and see if that works. If it doesn't it may need some more configure >> love, but it might happen. > > Good to read that! I was

Am Freitag, den 29.02.2008, 15:37 -0800 schrieb Eric Christopher: > Aaah. Try: > > .../configure --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu > > and see if that works. If it doesn't it may need some more configure > love, but it might happen. Good to read that! I was slowly approaching despair. Seems to make a *far* slower compile though. Or it's compiling

>>> >>> Those are valid instructions in every x86-32 assembler I'm aware of. >>> Perhaps it needs a switch to put it in 32-bit mode? >> >> Yes, I have been able to confirm that's what's happening behind the >> scene. The switch would be --32, however after that, ld will try to >> link >> the 64-bit versions of libc and the C

I do not know the configury stuff well enough to answer this, can someone else help? On Feb 28, 2008, at 1:55 AM, Joachim Durchholz wrote: > Am Mittwoch, den 27.02.2008, 14:31 -0800 schrieb Dale Johannesen: >> On Feb 27, 2008, at 2:12 PM, Joachim Durchholz wrote: >>> All error messages refer to one of the following four >>> instructions: >>> pushl %ebp

...,--32 is probably a fix that's a bit too low-level; besides, sorting out 32-bit and 64-bit libraries sounded like Very Much Not Fun, and hoped I could avoid the issue by placing the toolchain in 32-bit mode. > Does it work if you change the top of that test to: > ... > // RUN: as -m64 NoCompileUnit.s -o NoCompileUnit.o > .. > ? Lemme see (and checking my own hypotheses, of course...) ... gives me as: unrecognized option `-m64' This is actually gas, the GNU assembler. It expects a --64 or a --32 option (or --arch=<whatever>, but I'll stick with --64 for now) BTW I see...

Hi all again, llvm is failing the 2006-11-30-NoCompileUnit and 2006-11-30-Pubnames tests on me. -m32 and --disable-multilib didn't change the outcome. Did I get the command wrong? I tried jo at kurier:~/Delta/llvm/test$ CFLAGS=--multilib make check See below for a transcript of the failed check. What next? Regards, Jo -- snip -- jo at kurier:~/D...

Joachim Durchholz wrote: > Since llvm cannot generate code for amd64 at this time, this translates > to an additional constraint on --target, restricting me to --target=i686 > only. llvm can generate code for amd64, but shared libs don't work, and bootstrapping doesn't work (PR1711). Still, if you want to compile it as 32-bit, does it work if you run configure like this (without

...ct, the bugs are just in the dejagnu-based test machinery, not in > > LLVM itself. > > Yep, I believe that. I haven't been following the whole thread very > closely, what specific tests are affected here? test/C++Frontend/2006-11-06-StackTrace.cpp test/C++Frontend/2006-11-30-NoCompileUnit.cpp test/C++Frontend/2006-11-30-Pubnames.cpp > Before making any significant and widespread changes to llvm/test, > please change one test and propose it as a model for other tests. The changes were actually very local: replace calls to gcc/g++/as with calls to %compile_c and %compile_cxx...

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 following the whole thread very closely, what specific tests are affected here? Before making any significant and

...In function ‘test’: /home/kooijman/src/llvm-trunk/test/FrontendC/2008-05-12-TempUsedBeforeDef.c:8: warning: comparison is always true due to limited range of data type Running /home/kooijman/src/llvm-trunk/test/FrontendC++/dg.exp ... FAIL: /home/kooijman/src/llvm-trunk/test/FrontendC++/2006-11-30-NoCompileUnit.cpp Failed with unknown error (or has stderr output) at line 3 while running: g++ -I/home/kooijman/src/llvm-trunk/include -I/home/kooijman/src/llvm-trunk/test -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -g -fno-exceptions -Woverloaded-virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -W...