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
