llvm/test: suffix or operands invalid for `push'

Project Infrastructure LLVM Dev List Archives
1

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@kurier:~/Delta/llvm/test$ CFLAGS=--multilib make check

See below for a transcript of the failed check.

What next?

Regards,
Jo

-- snip --
jo@kurier:~/Delta/llvm/test$ make check
llvm[0]: Running test suite
make[1]: Betrete Verzeichnis '/home/jo/Delta/llvm/test'
( ulimit -t 600 ; ulimit -d 512000 ; \

PATH="/home/jo/Delta/llvm/Debug/bin:/home/jo/Delta/llvm/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 Wed Feb 27 10:02:12 2008
Native configuration 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.
Running /home/jo/Delta/llvm/test/Analysis/Andersens/dg.exp ...
Running /home/jo/Delta/llvm/test/Analysis/BasicAA/dg.exp ...
Running /home/jo/Delta/llvm/test/Analysis/Dominators/dg.exp ...
Running /home/jo/Delta/llvm/test/Analysis/GlobalsModRef/dg.exp ...
Running /home/jo/Delta/llvm/test/Analysis/LoadVN/dg.exp ...
Running /home/jo/Delta/llvm/test/Analysis/LoopInfo/dg.exp ...
Running /home/jo/Delta/llvm/test/Analysis/ScalarEvolution/dg.exp ...
Running /home/jo/Delta/llvm/test/Archive/dg.exp ...
Running /home/jo/Delta/llvm/test/Assembler/dg.exp ...
Running /home/jo/Delta/llvm/test/Bitcode/dg.exp ...
Running /home/jo/Delta/llvm/test/BugPoint/dg.exp ...
Running /home/jo/Delta/llvm/test/C++Frontend/dg.exp ...
FAIL: /home/jo/Delta/llvm/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/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/test/CFrontend/dg.exp ...
Running /home/jo/Delta/llvm/test/CodeGen/ARM/dg.exp ...
Running /home/jo/Delta/llvm/test/CodeGen/Alpha/dg.exp ...
Running /home/jo/Delta/llvm/test/CodeGen/CBackend/dg.exp ...
Running /home/jo/Delta/llvm/test/CodeGen/CellSPU/dg.exp ...
Running /home/jo/Delta/llvm/test/CodeGen/Generic/GC/dg.exp ...
Running /home/jo/Delta/llvm/test/CodeGen/Generic/dg.exp ...
Running /home/jo/Delta/llvm/test/CodeGen/IA64/dg.exp ...
Running /home/jo/Delta/llvm/test/CodeGen/PowerPC/dg.exp ...
Running /home/jo/Delta/llvm/test/CodeGen/SPARC/dg.exp ...
Running /home/jo/Delta/llvm/test/CodeGen/X86/dg.exp ...
Running /home/jo/Delta/llvm/test/DebugInfo/dg.exp ...
Running /home/jo/Delta/llvm/test/ExecutionEngine/dg.exp ...
Running /home/jo/Delta/llvm/test/Feature/dg.exp ...
Running /home/jo/Delta/llvm/test/FrontendAda/dg.exp ...
Running /home/jo/Delta/llvm/test/FrontendObjC/dg.exp ...
Running /home/jo/Delta/llvm/test/Integer/dg.exp ...
Running /home/jo/Delta/llvm/test/Linker/dg.exp ...
Running /home/jo/Delta/llvm/test/Other/dg.exp ...
Running /home/jo/Delta/llvm/test/TableGen/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/ADCE/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/ArgumentPromotion/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/BlockPlacement/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/CodeExtractor/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/CondProp/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/ConstProp/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/ConstantMerge/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/CorrelatedExprs/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/DeadArgElim/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/DeadStoreElimination/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/DecomposeMultiDimRefs/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/GCSE/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/GVN/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/GVNPRE/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/GlobalDCE/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/GlobalOpt/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/IPConstantProp/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/IndVarsSimplify/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/Inline/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/InstCombine/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/LCSSA/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/LICM/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/LoopIndexSplit/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/LoopRotate/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/LoopSimplify/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/LoopStrengthReduce/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/LoopUnroll/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/LoopUnswitch/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/LowerInvoke/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/LowerSetJmp/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/LowerSwitch/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/Mem2Reg/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/PredicateSimplifier/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/PruneEH/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/RaiseAllocations/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/Reassociate/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/SCCP/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/ScalarRepl/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/SimplifyCFG/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/SimplifyLibCalls/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/StripSymbols/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/TailCallElim/dg.exp ...
Running /home/jo/Delta/llvm/test/Transforms/TailDup/dg.exp ...
Running /home/jo/Delta/llvm/test/Verifier/dg.exp ...

                === Summary ===

# of expected passes 2518
# of unexpected failures 2
# of expected failures 7
make[1]: *** [check-local] Fehler 1
make[1]: Verlasse Verzeichnis '/home/jo/Delta/llvm/test'
make: *** [check] Fehler 2
jo@kurier:~/Delta/llvm/test$

2

Some additional info:

I just found the .s files mentioned in the error message, and checked
them. 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').

There are no other push or pop instructions in any .s file.
2006-11-06-StackTrace is not listed during testing, and generates no
error messages. All other .s files with pushl or popl are listed during
testing and fail with the above-mentioned error message.

Again: What should I try next?

Regards,
Jo

3

Some additional info:

I just found the .s files mentioned in the error message, and checked
them. 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?
Perhaps it is not parsing tab characters?

4

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?

Regards,
Jo

5

I do not know the configury stuff well enough to answer this, can someone else help?

6

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? :slight_smile:

-eric

7

Hi Eric,

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? :slight_smile:

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

8

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.

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.

-eric

9

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

10

Good to read that! I was slowly approaching despair.

Seems to make a *far* slower compile though. Or it's compiling more code
- can't tell.

Results after
  ./configure ...
  make clean
  make
  cd test
  make
are...

... no joy. Still exactly the same messages.

Interestingly enough, dejagnu still insists that the host is
x86_64-unknown-linux-gnu.

What next?

Regards,
Jo

11

Is this configuring llvm or llvm-gcc? Seems to work just fine for configure; make; make check with llvm.

-eric

12

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

13

# 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

14

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

15

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 any build,host, target):
$ linux32 ./configure

It should make all tools believe you are on 32-bit:
$ linux32 uname -m
i686
$ uname -m
x86_64

--Edwin

16

Ah, I didn't know this command existed. You never stop learning :slight_smile:

$ linux32 ./configure --prefix=$HOME
$ linux32 make
$ linux32 make check

gives

...
Native configuration is i686-pc-linux-gnu
...
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'
...

So 'runtest' is indeed thinking it is running under a 32-bit system, but
'as' tries to assemble for 64 bits anyway.
I don't know whether that's a bug in 'as', or in Ubuntu, or just the way
'as' is supposed to work and the caller should determine the correct
options to use.

Regards,
Jo

17

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.
There seem to be two issues:

Issue 1 is that the CC, CFLAGS, CXX, and CXXFLAGS settings are not
reflected in the site.exp file. I had
CC=gcc-4.2
CFLAGS="-m32 -Wl,-melf_i386"
CXX=g++-4.2
CXXFLAGS=$CFLAGS
ARCH=i686-pc-linux-gnu
./configure --prefix=$HOME --target=$ARCH --host=$ARCH --build=$ARCH
but site.exp still has
  set gccpath "gcc"
  set gxxpath "g++"
and no mention of -m32 or -Wl,elf_i386 (these options are required to
force a 64-bit GNU toolchain into 32-bit mode).

I don't know where these options are lost; I did a little looking around
in the configure scripts, but didn't find any obvious problems and
decided to leave this kind of issue to the autoconf experts :slight_smile:

Issue 2 is that the RUN: lines in the dejagnu tests ignore $CC, $CXX,
$CFLAGS and $CXXFLAGS when calling gcc, g++, or as (and possibly ld). In
most cases things will happen to not fail, but the assembler choked on
32-bit opcodes when running in default mode (which is 64 bits on an
amd64 machine, of course).

If I'm correct, this is a bug in the tests, not in LLVM.
Proposed bug fix would then be to replace in all test case files
(hopefully I got the dejagnu macro syntax right):
  gcc -> %gccpath
  g++ -> %gxxpath
  as -> %gccpath (don't call 'as' directly, gcc knows how to call it!)
  ld -> %gccpath (just as with 'as')

Can anybody confirm or correct these findings?

Regards,
Jo

18

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 widespread changes to llvm/test, please change one test and propose it as a model for other tests.

Thanks for working on this!

-Chris

19

> 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?

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.
I submitted bug reports with patches recently (look for bugs submitted
by jo@durchholz.org). The patches are tiny, so it's not a real problem
if they need to be modified, and I'm willing to try out any needed
modifications and resubmit the patches.
(%compile_cxx wouldn't work because %compile_c would be substituted
before, so the first patch corrects that.)

Thanks for working on this!

You're welcome :slight_smile:

Regards,
Jo

20

Makes sense! I applied your patch, thanks!

-Chris