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 ()
