Hi, I'm currently working on upgrading the version of gcc we use for mobile game development on the mophun platform from 3.0.3 to 3.4.6. I've run into a problem related to __builtin_apply that I cannot solve and I don't really know where to start looking.
For some background the virtual CPU we target can be thought of as a typical 32-bit RISC but without a status register and compare-and-branch instructions instead. The first 4 function parameters are passed in registers. The compiler is in a fairly good working state right now, these are the results of running the testsuite: === gcc Summary === # of expected passes 24293 # of unexpected failures 72 # of unexpected successes 1 # of expected failures 82 # of unresolved testcases 59 # of untested testcases 59 # of unsupported tests 414 One of the tests that fail to compile is 930623-1.c which is: g (a, b) {} f (xx) void* xx; { __builtin_apply ((void*)g, xx, 200); } I don't have anything special defined that affects how __builtin_apply is handled (as far as I know). I don't have an untyped_call pattern for example. What I'm really after is if someone can make a good guess as to what the problem is from just seeing this. Details below. Thanks, Roland When I compile with the -da option I get a bunch of files. The first one, 930623-1.c.01.rtl looks quite reasonable but in all the others the function f is completely missing. The compilation never finishes though because I get: /home/roland/projects/tools/gonative/gcc-build/gcc/cc1 -O3 -fomit-frame-pointer -w -DSTACK_SIZE=16384 -DNO_TRAMPOLINES -o 930623-1.o /home/roland/projects/tools/gonative/gcc/gcc/testsuite/gcc.c-torture/compile /930623-1.c g f Analyzing compilation unit Performing intraprocedural optimizations Assembling functions: g f /home/roland/projects/tools/gonative/gcc/gcc/testsuite/gcc.c-torture/compile /930623-1.c: In function `f': /home/roland/projects/tools/gonative/gcc/gcc/testsuite/gcc.c-torture/compile /930623-1.c:8: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. This SIGSEGV happens here: mark_jump_label (x=0x0, insn=0xb7f34b00, in_mem=0) at ../../gcc/gcc/jump.c:1381 1381 RTX_CODE code = GET_CODE (x); (gdb) where #0 mark_jump_label (x=0x0, insn=0xb7f34b00, in_mem=0) at ../../gcc/gcc/jump.c:1381 #1 0x08123eee in mark_jump_label (x=0xb7f7c540, insn=0xb7f34b00, in_mem=0) at ../../gcc/gcc/jump.c:1469 #2 0x08123ed4 in mark_jump_label (x=0xb7f7c548, insn=0xb7f34b00, in_mem=0) at ../../gcc/gcc/jump.c:1474 #3 0x08124012 in mark_all_labels (f=Variable "f" is not available. ) at ../../gcc/gcc/jump.c:266 #4 0x08124131 in rebuild_jump_labels (f=0x0) at ../../gcc/gcc/jump.c:88 #5 0x081926e4 in rest_of_compilation (decl=0xb7f76d14) at ../../gcc/gcc/toplev.c:3193 #6 0x081b04f6 in tree_rest_of_compilation (fndecl=0xb7f76d14, nested_p=false) at ../../gcc/gcc/tree-optimize.c:168 #7 0x0805a876 in c_expand_body_1 (fndecl=0xb7f76d14, nested_p=0) at ../../gcc/gcc/c-decl.c:6190 #8 0x081b16ff in cgraph_expand_function (node=0xb7f350d8) at ../../gcc/gcc/cgraphunit.c:538 #9 0x081b2d9a in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1542 #10 0x0807fa91 in c_objc_common_finish_file () at ../../gcc/gcc/c-objc-common.c:240 #11 0x0819497a in toplev_main (argc=9, argv=0xbfbd6894) at ../../gcc/gcc/toplev.c:1822 #12 0x009e7de6 in __libc_start_main () from /lib/libc.so.6 #13 0x0804985d in _start ()