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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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

Reply via email to