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 theApplied.> 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, > > -ChrisThanks, 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>