Anyone seen this before?

So, I'm trying to build everything from source for the Debian
package for LLVM, including the C/C++ front end. I'm running
this build on LLVM 1.4 source (the released tarball), using
Debian unstable (gcc 3.3.5, on a 2.6.8 kernel, on an x86_64
box, dual CPU). Before I get _too_ deep into it, I thought I
would ask if the following compilation failure on the CFE
looks the least bit familiar to anyone:

/home/ahs3/llvm/llvm-1.4/cfrontend/build/gcc/xgcc
-B/home/ahs3/llvm/llvm-1.4/cfrontend/build/gcc/
-B/usr/lib/llvm/cfrontend/x86_64-unknown-linux-gnu/bin/
-B/usr/lib/llvm/cfrontend/x86_64-unknown-linux-gnu/lib/
-isystem /usr/lib/llvm/cfrontend/x86_64-unknown-linux-gnu/include
-isystem /usr/lib/llvm/cfrontend/x86_64-unknown-linux-gnu/sys-include -c
-DHAVE_CONFIG_H -O2 -O2 -I. -I../../../src/libiberty/../include -W
-Wall -Wtraditional -pedantic ../../../src/libiberty/concat.c -o
concat.o
gccas: /tmp/ccl9eZIl.s:569: Can't load from pointer of non-first-class
type:
make[3]: *** [concat.o] Error 1
make[3]: Leaving directory
`/home/ahs3/llvm/llvm-1.4/cfrontend/build/x86_64-unknown-linux-gnu/libiberty'
make[2]: *** [all-target-libiberty] Error 2
make[2]: Leaving directory `/home/ahs3/llvm/llvm-1.4/cfrontend/build'
make[1]: *** [stamp/build-stamp] Error 20
make[1]: Leaving directory `/home/ahs3/llvm/llvm-1.4'
make: *** [install-arch] Error 2

If this isn't familiar, that's fine. That'll give me something to do
tomorrow :). Have I perhaps just built gccas incorrectly, or something
like that?

yes, so this happens on anything that uses a struct for va_list (like
alpha). I am currently working on fixing this. if you look at the last
patch to the alpha portion of llvm-gcc, you can see a quick hack to work
around that (aka, get it to compile), but the resultant compiler will
have issues with varargs.

Alternately, build ia-32 binaries on x86_64, llvm-gcc is happy with the
the abi there.

Andrew Lenharth

yes, so this happens on anything that uses a struct for va_list (like
alpha). I am currently working on fixing this. if you look at the last
patch to the alpha portion of llvm-gcc, you can see a quick hack to work
around that (aka, get it to compile), but the resultant compiler will
have issues with varargs.

While Andrew is working on the real fix, here's the patch that hacked around it for X86-64 (which went in after 1.4):

http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050103/022913.html

-Chris

Andrew Lenharth

So, I'm trying to build everything from source for the Debian
package for LLVM, including the C/C++ front end. I'm running
this build on LLVM 1.4 source (the released tarball), using
Debian unstable (gcc 3.3.5, on a 2.6.8 kernel, on an x86_64
box, dual CPU). Before I get _too_ deep into it, I thought I
would ask if the following compilation failure on the CFE
looks the least bit familiar to anyone:

/home/ahs3/llvm/llvm-1.4/cfrontend/build/gcc/xgcc
-B/home/ahs3/llvm/llvm-1.4/cfrontend/build/gcc/
-B/usr/lib/llvm/cfrontend/x86_64-unknown-linux-gnu/bin/
-B/usr/lib/llvm/cfrontend/x86_64-unknown-linux-gnu/lib/
-isystem /usr/lib/llvm/cfrontend/x86_64-unknown-linux-gnu/include
-isystem /usr/lib/llvm/cfrontend/x86_64-unknown-linux-gnu/sys-include -c
-DHAVE_CONFIG_H -O2 -O2 -I. -I../../../src/libiberty/../include -W
-Wall -Wtraditional -pedantic ../../../src/libiberty/concat.c -o
concat.o
gccas: /tmp/ccl9eZIl.s:569: Can't load from pointer of non-first-class
type:
make[3]: *** [concat.o] Error 1
make[3]: Leaving directory
`/home/ahs3/llvm/llvm-1.4/cfrontend/build/x86_64-unknown-linux-gnu/libiberty'
make[2]: *** [all-target-libiberty] Error 2
make[2]: Leaving directory `/home/ahs3/llvm/llvm-1.4/cfrontend/build'
make[1]: *** [stamp/build-stamp] Error 20
make[1]: Leaving directory `/home/ahs3/llvm/llvm-1.4'
make: *** [install-arch] Error 2

If this isn't familiar, that's fine. That'll give me something to do
tomorrow :). Have I perhaps just built gccas incorrectly, or something
like that?

_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev

-Chris

Chris Lattner wrote:

yes, so this happens on anything that uses a struct for va_list (like
alpha). I am currently working on fixing this. if you look at the last
patch to the alpha portion of llvm-gcc, you can see a quick hack to work
around that (aka, get it to compile), but the resultant compiler will
have issues with varargs.

While Andrew is working on the real fix, here's the patch that hacked around it for X86-64 (which went in after 1.4):

http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050103/022913.html

Please note that this is not a hack but actually the correct solution to handle varargs for the llvm CFE.

I'm sorry, I did not mean to denigrate your patch. I don't think it's the right long-term solution, because it makes the code generated by llvm-gcc not match the target ABI (i.e. you can't pass a va_list from a piece of code compiled by llvm to a piece of code compiled by GCC) on targets like X86-64 and Alpha. This is what Andrew is working on fixing.

And we will have to duplicate the complex gcc code for the AMD64 varargs calling convention if we ever decide to add support for native code generation (currently only -Wl,-native-cbe is supported).

Very true!

-Chris

Perfect. Y'all are awesome. amd64 now builds from scratch. Thanks!