llvm dev - Feb 2008 - [LLVMdev] llvm/test: suffix or operands invalid for `push'

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
>>> pushl %esi
>>> popl %ebp
>>> popl %esi
>>> It's always the same error, "suffix or operands invalid
for
>>> `push'" (resp `pop').
>>
>> 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 runtime.
>
> I was able to trigger the problem during ./configure, by using llvm- 
> gcc.
> With configure, it was fixable for the whole toolchain by saying
> --target=i686, so there is hope.
>
> Unfortunately, make check doesn't seem to use the setting
> from ./configure; this is what I see in site.exp, regardless of any  
> CC> or CFLAGS= settings on make check:
>  set gccpath "gcc"
>  set gxxpath "g++"
>
> Should I edit site.exp to fix that, or is there a better way?

>>>
>>> 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 runtime.
>>
>> I was able to trigger the problem during ./configure, by using llvm-
>> gcc.
>> With configure, it was fixable for the whole toolchain by saying
>> --target=i686, so there is hope.
>>
>> Unfortunately, make check doesn't seem to use the setting
>> from ./configure; this is what I see in site.exp, regardless of any
>> CC>> or CFLAGS= settings on make check:
>> set gccpath "gcc"
>> set gxxpath "g++"
>>
>> Should I edit site.exp to fix that, or is there a better way?
>
I'm coming into this late so I'm not really sure what's going on,
but
you
can pass options to dejagnu pretty easily using RUNTESTFLAGS. That
aside though, what are you doing, and what are you trying to  
accomplish? :)

-eric

Hi Eric,

Am Freitag, den 29.02.2008, 15:02 -0800 schrieb Eric
Christopher:
> I'm coming into this late so I'm not really sure what's going
on,
In a nutshell, I'm trying to get llvm to run on my amd64 Linux box.
Problem is that various tools are activated in 64-bit mode even though I
try to convince everybody to play fair with llvm and use 32 bits. (I
gather llvm doesn't currently have any 64-bit backends.)

Currently, I'm getting assembly error messages that amount to stating
that popl and pushl aren't valid instructions.
Tweaking CCFLAGS and CXXFLAGS to that a --32 option would be passed to
`as' would make these errors go away, so the error message probably is
because the standard 64-bit assembler tries to work on 32-bit assembly
instructions and fails.
Unfortunately, --32 on the assembler isn't enough; after that, `ld' will
fail because it's trying to link a 64-bit clib and crt to 32-bit code.

Actually dejagnu properly identifies the target platform; among other
things, the output from
  cd test
  make
has
  Target is i686-pc-none
  Host   is x86_64-unknown-linux-gnu
which means it knows that it is running on amd64 (host = x86_64) and
deals with compilers emitting code for 32 bit (target = i686).

I suspect it should pass on the target=i686 option to `as' and `ld', but
doesn't.
> but you can pass options to dejagnu pretty easily using RUNTESTFLAGS.
What back-end programs would these be passed on to? (I don't think a
target=i686 would make much sense to, say, a `cp' command...)
> That
> aside though, what are you doing, and what are you trying to  
> accomplish? :)
Just trying to get the routine checks in the test/ subdirectory to run
successfully. I'd rather have a reliable installation than spurious
errors later; the reports about potential miscompilations have made me a
bit cautious.
I'm open to trying a different approach. E.g. I could try bootstrapping
llvm using gcc -O1, then compiling llvm with itself, and arrive at a
bitcode version of llvm (this doesn't seem to be standard practice
though).

Regards,
Jo

For completeness, here's the log of what I did:

$ wget http://llvm.org/releases/2.2/llvm-test-2.2.tar.gz
$ tar xzf llvm-2.2.tar.gz
$ cd llvm-2.2.tar.gz
$ ./configure --prefix=$HOME --target=i686 --with-gnu-ld CC=gcc-4.2 \
  CXX=g++-4.2 CXXCPP=cpp-4.2
# The default compiler is 4.1.2, which I wanted to avoid after reading
# the warnings in the installation instructions.
# ./configure finished with no errors, though it warned about a few
# longints being truncated to signed, and some strict pointer stuff.
# (If anybody is interested, I'll post the warnings in a separate
# message.)
$ cd test
$ make

This is what I got:

-- snip --

( ulimit -t 600 ; ulimit -d 512000 ; \

PATH="/home/jo/Delta/llvm-2.2/Release/bin:/home/jo/Delta/llvm-2.2/test/Scripts:/home/jo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
\
          /usr/bin/runtest --ignore "llvm2cpp.exp ocaml.exp" )
WARNING: No tool specified
Test Run By jo on Sat Mar  1 00:03:22 2008
Target is i686-pc-none
Host   is x86_64-unknown-linux-gnu

                ===  tests ==
Schedule of variations:
    unix

Running target unix
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.
Running /home/jo/Delta/llvm-2.2/test/Analysis/Andersens/dg.exp ...
[...]
Running /home/jo/Delta/llvm-2.2/test/BugPoint/dg.exp ...
Running /home/jo/Delta/llvm-2.2/test/C++Frontend/dg.exp ...
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'

FAIL: /home/jo/Delta/llvm-2.2/test/C++Frontend/2006-11-30-Pubnames.cpp
Failed with exit(1) at line 2
while running: as 2006-11-30-Pubnames.cpp.tmp.s -o
2006-11-30-Pubnames.cpp.tmp.o
2006-11-30-Pubnames.cpp.tmp.s: Assembler messages:
2006-11-30-Pubnames.cpp.tmp.s:33: Error: suffix or operands invalid for
`push'
2006-11-30-Pubnames.cpp.tmp.s:55: Error: suffix or operands invalid for
`pop'

Running /home/jo/Delta/llvm-2.2/test/CFrontend/dg.exp ...
[...]
Running /home/jo/Delta/llvm-2.2/test/Verifier/dg.exp ...

                ===  Summary ==
# of expected passes            2518
# of unexpected failures        2
# of expected failures          7
make: *** [check-local] Fehler 1
-- snip --

(Snipped most lines reporting successful tests.)

HTH

Regards,
Jo