[LLVMdev] Anyone seen this before?

[Chris Lattner]

On Fri, 11 Mar 2005, Markus F.X.J. Oberhumer wrote:
> Chris Lattner wrote:
>> On Thu, 10 Mar 2005, Andrew Lenharth 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

>>> On Thu, 2005-03-10 at 19:25 -0700, Al Stone wrote:
>>> 
>>>> 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 at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>>> 
>> 
>> -Chris
>> 
>
>
>

-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/