GCC 3.4.6 __builtin_apply problem for custom target

GCC 3.4.6 __builtin_apply problem for custom target

[Roland Persson]

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

Re: GCC 3.4.6 __builtin_apply problem for custom target

[Eric Christopher]

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

The thing to figure out is why you're passing x=0x0 into  
mark_jump_label.

-eric

RE: GCC 3.4.6 __builtin_apply problem for custom target

[Roland Persson]

Yes, I had noticed that, but I thought it was just a consequence of
something else going wrong much earlier. Perhaps it is the actual problem
though.

For some reason I assumed that the files produced by the -da option were
written sequentially but I guess they are all kind of written to in
parallel, perhaps on a per function basis.

The insn when x==0 is this:

(call_insn 28 27 29 (parallel [
            (set (reg:DI 30 $r0)
                (call (mem:SI (symbol_ref:SI ("g") [flags 0x3]
<function_decl 0xb7f719b4 g>) [0 S4 A32])
                    (const_int 0 [0x0])))
            (use (nil))
            (clobber (reg:SI 2 $ra))
        ]) -1 (nil)
    (nil)
    (expr_list (use (reg:SI 15 $p3))
        (expr_list (use (reg:SI 14 $p2))
            (expr_list (use (reg:SI 13 $p1))
                (expr_list (use (reg:SI 12 $p0))
                    (nil))))))

The only thing that looks a bit unusual to me in that is the DI mode used in
the set. 

Anyway, thanks for the hint. I started thinking differently about all this
at least. 

Are there any usual suspects for this kind of problem then? As I don't call
mark_jump_label directly I don't really feel responsible for the NULL passed
to it although I'm sure it is my fault in some way... :-)

/Roland

> -----Original Message-----
> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
> Eric Christopher
> Sent: Wednesday, May 31, 2006 23:50
> To: Roland Persson
> Cc: gcc@gcc.gnu.org
> Subject: Re: GCC 3.4.6 __builtin_apply problem for custom target
> 
> >
> > 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
> 
> The thing to figure out is why you're passing x=0x0 into
> mark_jump_label.
> 
> -eric

Re: GCC 3.4.6 __builtin_apply problem for custom target

[Eric Christopher]

>
> The insn when x==0 is this:
>
> (call_insn 28 27 29 (parallel [
>             (set (reg:DI 30 $r0)
>                 (call (mem:SI (symbol_ref:SI ("g") [flags 0x3]
> <function_decl 0xb7f719b4 g>) [0 S4 A32])
>                     (const_int 0 [0x0])))
>             (use (nil))
>             (clobber (reg:SI 2 $ra))
>         ]) -1 (nil)
>     (nil)
>     (expr_list (use (reg:SI 15 $p3))
>         (expr_list (use (reg:SI 14 $p2))
>             (expr_list (use (reg:SI 13 $p1))
>                 (expr_list (use (reg:SI 12 $p0))
>                     (nil))))))
>
> The only thing that looks a bit unusual to me in that is the DI  
> mode used in
> the set.
>

use nil?

> Anyway, thanks for the hint. I started thinking differently about  
> all this
> at least.
>
> Are there any usual suspects for this kind of problem then? As I  
> don't call
> mark_jump_label directly I don't really feel responsible for the  
> NULL passed
> to it although I'm sure it is my fault in some way... :-)

Well, it's likely the rtl that you're generating so, yeah, it'd be  
likely your fault. :)

Otherwise you also might want to look to moving to 4.1/2 as long as  
you're moving.

-eric

RE: GCC 3.4.6 __builtin_apply problem for custom target

[Roland Persson]

> 
> Otherwise you also might want to look to moving to 4.1/2 as long as
> you're moving.
> 

I've been thinking about that recently. The main reason I'm going for 3.4 is
that it's what I started with about a year ago. Since then I've had to work
on other things most of the time. 

Going from 3.0.3 to 3.4 required quite a bit of changes to the target files,
lots of things becoming hooks instead of macros etc as well as some things
being done differently. All of that is resolved now however.

How much typically needs to be done when going from 3.4 to 4.1? If it's alot
then I will finish 3.4.6 first since it's pretty close. It's quite an
improvement over 3.0.3 too.

/Roland