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

[Joachim Durchholz]

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