llvm dev - Sep 2006 - [LLVMdev] trying to build llvm-gcc in linux/amd64

I am trying to build llvm-gcc4 on a amd64. I had to add the attached
patch to get the build system to select the correct library. Now the
build fails while compiling a code that has __builtin_va_copy. The
attached test.i fails with:

cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value*
TreeToLLVM::Emit(tree_node*, llvm::Value*): Assertion
`(isAggregateType(((exp)->common.type)) == (DestLoc != 0) || ((enum
tree_code) (exp)->common.code) == MODIFY_EXPR) && "Didn't
pass DestLoc
to an aggregate expr, or passed it to scalar!"' failed.

I know that linux/amd64 is not currently supported, but does someone
knows how to fix this?

Thanks,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: amd64.patch
Type: application/octet-stream
Size: 404 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20060911/052ca249/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.i
Type: application/octet-stream
Size: 78 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20060911/052ca249/attachment-0001.obj>

On Mon, 11 Sep 2006, [UTF-8] Rafael Esp?ndola wrote:
> I am trying to build llvm-gcc4 on a amd64. I had to add the attached
> patch to get the build system to select the correct library. Now the
Applied.
> build fails while compiling a code that has __builtin_va_copy. The
> attached test.i fails with:
>
> cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value*
> TreeToLLVM::Emit(tree_node*, llvm::Value*): Assertion
> `(isAggregateType(((exp)->common.type)) == (DestLoc != 0) || ((enum
> tree_code) (exp)->common.code) == MODIFY_EXPR) &&
"Didn't pass DestLoc
> to an aggregate expr, or passed it to scalar!"' failed.
>
> I know that linux/amd64 is not currently supported, but does someone
> knows how to fix this?
Can you gdb cc1, run until the assertion, then mail the output of "call 
debug_tree(exp)"?  Also, can you include a stack trace with line numbers 
as well?

Thanks,

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

> Can you gdb cc1, run until the assertion, then mail the output of
"call
> debug_tree(exp)"?  Also, can you include a stack trace with line
numbers
> as well?
debug_tree crashes with a segfault. The backtrace is

#0  TreeToLLVM::Emit (this=0x7fff68bf4a40, exp=0x2acb42ae2100,
DestLoc=0x11f98d0) at ../../trunk/gcc/llvm-convert.cpp:441
#1  0x00000000006b16b6 in TreeToLLVM::EmitBuiltinVACopy
(this=0x7fff68bf4a40, exp=0x2acb42a137d0) at
../../trunk/gcc/llvm-convert.cpp:3381
#2  0x00000000006cf57c in TreeToLLVM::EmitBuiltinCall
(this=0x7fff68bf4a40, exp=0x2acb42a137d0, fndecl=0x2acb42aa70e0,
DestLoc=0x0, Result=@0x7fff68bf4648) at
../../trunk/gcc/llvm-convert.cpp:2871
#3  0x00000000006d03d4 in TreeToLLVM::EmitCALL_EXPR
(this=0x7fff68bf4a40, exp=0x2acb42a137d0, DestLoc=0x0) at
../../trunk/gcc/llvm-convert.cpp:1666
#4  0x00000000006ac84f in TreeToLLVM::Emit (this=0x7fff68bf4a40,
exp=0x2acb42a137d0, DestLoc=0x0) at
../../trunk/gcc/llvm-convert.cpp:501
#5  0x00000000006d376b in TreeToLLVM::EmitSTATEMENT_LIST
(this=0x7fff68bf4a40, exp=0x2acb42ae1db0, DestLoc=0x0) at
../../trunk/gcc/llvm-convert.cpp:1155
#6  0x00000000006ac767 in TreeToLLVM::Emit (this=0x7fff68bf4a40,
exp=0x2acb42ae1db0, DestLoc=0x0) at
../../trunk/gcc/llvm-convert.cpp:475
#7  0x00000000006d501d in TreeToLLVM::EmitBIND_EXPR
(this=0x7fff68bf4a40, exp=0x2acb42a13820, DestLoc=0x0) at
../../trunk/gcc/llvm-convert.cpp:1130
#8  0x00000000006ac74d in TreeToLLVM::Emit (this=0x7fff68bf4a40,
exp=0x2acb42a13820, DestLoc=0x0) at
../../trunk/gcc/llvm-convert.cpp:474
#9  0x000000000069922b in llvm_emit_code_for_current_function
(fndecl=0x2acb42ad4460) at ../../trunk/gcc/llvm-backend.cpp:405
#10 0x000000000048921a in tree_rest_of_compilation
(fndecl=0x2acb42ad4460) at ../../trunk/gcc/tree-optimize.c:702
#11 0x0000000000416a1c in c_expand_body (fndecl=0x7fff68bf4a40) at
../../trunk/gcc/c-decl.c:6771
#12 0x0000000000726aae in cgraph_expand_function (node=0x2acb42ad4a80)
at ../../trunk/gcc/cgraphunit.c:896
#13 0x0000000000726c31 in cgraph_assemble_pending_functions () at
../../trunk/gcc/cgraphunit.c:313
#14 0x0000000000729055 in cgraph_finalize_function
(decl=0x2acb42ad4460, nested=false) at
../../trunk/gcc/cgraphunit.c:411
#15 0x0000000000416f65 in finish_function () at ../../trunk/gcc/c-decl.c:6740
#16 0x0000000000409185 in yyparse () at c-parse.y:436
#17 0x000000000040e789 in c_parse_file () at c-parse.y:3438
#18 0x0000000000457df5 in c_common_parse_file (set_yydebug=<value
optimized out>) at ../../trunk/gcc/c-opts.c:1221
#19 0x0000000000670d0a in toplev_main (argc=<value optimized out>,
argv=<value optimized out>) at ../../trunk/gcc/toplev.c:1105
#20 0x00002acb4268e4ca in __libc_start_main () from /lib/libc.so.6
#21 0x0000000000407f7a in _start () at ../sysdeps/x86_64/elf/start.S:113


One think that I find interesting is that amd64 has a different
implementation of varargs. Running cc1 with -fdump-tree-all one gets
the following generic dump:
-----------------------------------------
f ()
{
  struct  va1[1];
  struct  va2[1];

  __builtin_va_copy (&va1, &va2);
}
------------------------------------------
in a x86 the output is

f ()
{
  char * va1;
  char * va2;

  __builtin_va_copy (&va1, va2);
}

> Thanks,
>
> -Chris
Thanks,
Rafael

> Can you gdb cc1, run until the assertion, then mail the output of
"call
> debug_tree(exp)"?  Also, can you include a stack trace with line
numbers
> as well?
The problem with debug_tree was actually with gdb. Modifing the code
produces this output when trying to ouput Arg1T. We must pass a
DestLoc for Emit when va_list is implemented with a structure?

 <addr_expr 0x2b6656a500c0
    type <pointer_type 0x2b66569981c0
        type <record_type 0x2b6656997a80 __va_list_tag sizes-gimplified BLK
            size <integer_cst 0x2b66569928d0 constant invariant 192>
            unit size <integer_cst 0x2b6656992870 constant invariant 24>
            align 64 symtab 18729424 alias set -1 fields <field_decl
0x2b6656997c40 gp_offset>
            pointer_to_this <pointer_type 0x2b66569981c0> chain
<type_decl 0x2b6656997b60 __va_list_tag>>
        unsigned DI
        size <integer_cst 0x2b665697cba0 constant invariant 64>
        unit size <integer_cst 0x2b665697cbd0 constant invariant 8>
        align 64 symtab 18731200 alias set -1>
    invariant
    arg 0 <var_decl 0x2b6656a42700 va1
        type <array_type 0x2b66569982a0 __builtin_va_list type
<record_type 0x2b6656997a80 __va_list_tag>
            sizes-gimplified BLK size <integer_cst 0x2b66569928d0 192>
unit size <integer_cst 0x2b6656992870 24>
            align 64 symtab 0 alias set -1 domain <integer_type
0x2b6656998000>>
        addressable used asm-frame-size 0 BLK file test.i line 3 size
<integer_cst 0x2b66569928d0 192> unit size <integer_cst 0x2b6656992870
24>
        align 128 context <function_decl 0x2b6656a42460 f>
        LLVM: [1 x %struct.__va_list_tag]* %va1
        chain <var_decl 0x2b6656a427e0 va2 type <array_type
0x2b66569982a0 __builtin_va_list>
            addressable used asm-frame-size 0 BLK file test.i line 3
size <integer_cst 0x2b66569928d0 192> unit size <integer_cst
0x2b6656992870 24>
            align 128 context <function_decl 0x2b6656a42460 f>
            LLVM: [1 x %struct.__va_list_tag]* %va2>>>



Rafael

I think that the attached patch solves the problem.

Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: amd64.patch
Type: application/octet-stream
Size: 581 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20060913/a8639933/attachment.obj>

On Wed, 13 Sep 2006, [UTF-8] Rafael Esp?ndola wrote:
> I think that the attached patch solves the problem.
Ahhh, excellent detective work!  Applied!

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/