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