Joachim Durchholz
2008-Mar-01 09:29 UTC
[LLVMdev] llvm/test: suffix or operands invalid for `push'
Am Freitag, den 29.02.2008, 18:15 -0800 schrieb Eric Christopher:> Is this configuring llvm or llvm-gcc?This is inside the llvm-2.2 directory.> Seems to work just fine for > configure; make; make check with llvm.Trying "make check" from the llvm directory instead of "make" from llvm/test... doesn't work. Retrying from scratch, here's the transcript: # I had set up $PATH like this: $ which llvm-gcc llvm-g++ /home/jo/bin/llvm-gcc /home/jo/bin/llvm-g++ # ... and $HOME/bin like this: $ ll $HOME/bin llvm-g++ -> /home/jo/Delta/llvm-gcc4.2-2.2-x86-linux-RHEL4/bin/llvm-g++ llvm-gcc -> /home/jo/Delta/llvm-gcc4.2-2.2-x86-linux-RHEL4/bin/llvm-gcc # Reset to initial state: $ rm -rf llvm-2.2 llvm-gcc4.2-2.2-x86-linux-RHEL4 $ tar xzf llvm-2.2.tar.gz $ tar xzf llvm-gcc4.2-2.2-x86-linux-RHEL4.tar.gz # Configure & install $ cd llvm-2.2 # I'm trying the --build option, too. $ ./configure --prefix=$HOME CC=gcc-4.2 CXX=g++-4.2 \ --build=x86_64-pc-linux-gnu \ --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu $ 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 ... Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as 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 operands invalid for `push' NoCompileUnit.s:83: Error: suffix or operands invalid for `pop' NoCompileUnit.s:95: Error: suffix or operands invalid for `push' NoCompileUnit.s:116: Error: suffix or operands invalid for `pop' NoCompileUnit.s:128: Error: suffix or operands invalid for `push' NoCompileUnit.s:225: Error: suffix or operands invalid for `pop' NoCompileUnit.s:237: Error: suffix or operands invalid for `push' NoCompileUnit.s:243: Error: suffix or operands invalid for `push' NoCompileUnit.s:268: Error: suffix or operands invalid for `pop' NoCompileUnit.s:269: Error: suffix or operands invalid for `pop' ... I'm not sure what to make of that "tool config file" warning. Regards, Jo
Chris Lattner
2008-Mar-01 18:57 UTC
[LLVMdev] llvm/test: suffix or operands invalid for `push'
> # Configure & install > $ cd llvm-2.2 > # I'm trying the --build option, too. > $ ./configure --prefix=$HOME CC=gcc-4.2 CXX=g++-4.2 \ > --build=x86_64-pc-linux-gnu \ > --host=i686-pc-linux-gnu --target=i686-pc-linux-gnuThis is probably the problem. It sounds like you have llvm-gcc building 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 > ... > Using /usr/share/dejagnu/baseboards/unix.exp as board description file > for target. > Using /usr/share/dejagnu/config/unix.exp as 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 operands invalid for `push' > NoCompileUnit.s:83: Error: suffix or operands invalid for `pop' > NoCompileUnit.s:95: Error: suffix or operands invalid for `push' > NoCompileUnit.s:116: Error: suffix or operands invalid for `pop' > NoCompileUnit.s:128: Error: suffix or operands invalid for `push' > NoCompileUnit.s:225: Error: suffix or operands invalid for `pop' > NoCompileUnit.s:237: Error: suffix or operands invalid for `push' > NoCompileUnit.s:243: Error: suffix or operands invalid for `push' > NoCompileUnit.s:268: Error: suffix or operands invalid for `pop' > NoCompileUnit.s:269: Error: suffix or operands invalid for `pop' > ... > > I'm not sure what to make of that "tool config file" warning. > > Regards, > Jo > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Joachim Durchholz
2008-Mar-02 00:27 UTC
[LLVMdev] llvm/test: suffix or operands invalid for `push'
Am Samstag, den 01.03.2008, 10:57 -0800 schrieb Chris Lattner:> > # Configure & install > > $ cd llvm-2.2 > > # I'm trying the --build option, too. > > $ ./configure --prefix=$HOME CC=gcc-4.2 CXX=g++-4.2 \ > > --build=x86_64-pc-linux-gnu \ > > --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu > > This is probably the problem. It sounds like you have llvm-gcc > building for x86-64 (so the compiler defaults to emitting x86-64 code)Hmm... did I misunderstand ./configure --help? It says --build=BUILD configure for building on BUILD [guessed] --host=HOST cross-compile to build programs to run on HOST [BUILD] --target=TARGET configure for building compilers for TARGET [HOST] which I interpreted to mean: --build - the arch the build process will run on (usually the same as the current machine, though in some cases people might want to run ./configure on one machine and then distribute it to other machines) --host - the arch the compilers will be run on --target - the arch the programs compiled by the compilers will run on In my case, since I'm using an amd64 machine that can run both 32-bit and 64-bit code, this would mean that any combination of x86_64 and i686 for --build, --host, and --target should work. Since llvm cannot generate code for amd64 at this time, this translates to an additional constraint on --target, restricting me to --target=i686 only. If I wish to compile llvm-gcc, and compile llvm itself using llvm-gcc, I'd have to set both --host and --target as i686. Well, at least that's how I interpret these options. If that interpretation is correct, then I suspect there's a bug in the way the configure script processes these options.> 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.Actually it's the other way round: the assembler needs a --32 option. I had set CCFLAGS and CXXFLAGS to -Wa,--32 (the Wa meaning "pass the following options to as", and the --32 tells as it's being fed 32-bit assembly instructions), and with that, the assembly instructions would pass without an error. After that, the linker would complain because it tried to link the default 64-bit libraries with the 32-bit object files generated by the assembler. That's the point at which I started to think that -Wa,--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 that the RUN lines are using g++. Shouldn't they use $(CXX) so that the same toolchain is used for building and testing llvm? After all, I did ./configure CXX=gcc-4.2 specifically to avoid miscompilation issues with the default gcc on Ubuntu, which is currently 4.1. I have also been toying with the idea of compiling llvm with llvm-gcc, and it would be quite reassuring if I could run the tests using just the llvm infrastructure. Now back to our regularly scheduled programme, and trying --64 now: ... gives me the same old "suffix or operand invalid for pop/push" errors. Trying with --32: FAIL: /home/jo/Delta/llvm-2.2/test/\ C++Frontend/2006-11-30-NoCompileUnit.cpp Failed with exit(1) at line 3 while running: g++ NoCompileUnit.o -o NoCompileUnit.exe /usr/bin/ld: i386 architecture of input file `NoCompileUnit.o' is incompatible with i386:x86-64 output collect2: ld gab 1 als Ende-Status zurück So the assembler is doing its thing (no error message from that stage), but after that, ld fails because it wasn't told to use the 32-bit libs. However, if the llvm build/test machinery mishandles --build/host/target somewhere, things *should* work if all three are uniformly set for 32 bits. Trying that approach with $ ./configure --prefix=$HOME CC=gcc-4.2 CXX=g++-4.2 \ --build=i686-pc-linux-gnu \ --host=i686-pc-linux-gnu \ --target=i686-pc-linux-gnu $ make $ make check ... well, what shall I say: it's still saying Host is x86_64-unknown-linux-gnu and giving me NoCompileUnit.s:33: Error: suffix or operands invalid for `push' (plus variations of the latter). My best hypothesis is that the test simply doesn't follow ./configure. Would it make sense to skip the short test entirely and proceed with the full test suite? I had considered running it anyway, so that wouldn't be a serious problem for me. Heck, I'd even compile llvm-gcc using llvm and good riddance to the preinstalled gcc/g++ infrastructure, I wasn't planning on using it for more than doing the initial bootstrap anyway. I'm not sure whether that solves more problems than it creates though, and that's why I didn't try to that yet - but I'm beginning to think it might be the easier route for me. Regards, Jo
Possibly Parallel Threads
- [LLVMdev] llvm/test: suffix or operands invalid for `push'
- [LLVMdev] llvm/test: suffix or operands invalid for `push'
- [LLVMdev] llvm/test: suffix or operands invalid for `push'
- [LLVMdev] llvm/test: suffix or operands invalid for `push'
- [LLVMdev] llvm/test: suffix or operands invalid for `push'