llvm dev - Mar 2008 - [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

> # 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)  
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

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