Rainer Orth <r...@cebitec.uni-bielefeld.de> writes:
> Hi Richard,
>>> It seems the new get_some_local_dynamic_name implementation in
>>> function.c lost the non-NULL check the sparc.c version had. I'm
>>> currently testing the following patch:
>>
>> Could you do a:
>>
>> call debug_rtx (...)
>>
>> on the insn that contains a null pointer? Normally insn patterns
>> shouldn't contain nulls, so I was wondering whether this was some
>> SPARC-specific construct.
>
> proved a bit difficult to do: at the default -O2, insn was optimized
> away, at -g3 -O0, I only got
>
> can't compute CFA for this frame
>
> with gdb 7.8 even after recompiling all of the gcc dir with -g3 -O0.
>
> Here's what I find after inserting the call in the source:
>
> (insn 30 6 28 (sequence [
> (call_insn:TI 8 6 7 (parallel [
> (set (reg:SI 8 %o0)
> (call (mem:SI (unspec:SI [
> (symbol_ref:SI ("__tls_get_addr"))
> ] UNSPEC_TLSLDM) [0 S4 A32])
> (const_int 1 [0x1])))
> (clobber (reg:SI 15 %o7))
> ]) /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:936
> 390 {tldm_call32}
> (expr_list:REG_EH_REGION (const_int -2147483648
> [0xffffffff80000000])
> (nil))
> (expr_list (use (reg:SI 8 %o0))
> (nil)))
> (insn 7 8 28 (set (reg:SI 8 %o0)
> (plus:SI (reg:SI 23 %l7)
> (unspec:SI [
> (reg:SI 8 %o0 [112])
> ] UNSPEC_TLSLDM))) 388 {tldm_add32}
> (nil))
> ]) /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:936 -1
> (nil))
Bah, a sequence. Hadn't thought of that.
IMO it's a bug for a walk on a PATTERN to pull in non-PATTERN parts
of an insn. We should really be looking at the patterns of the two
subinsns instead and ignore the other stuff. Let me have a think
about it.
Now that we know the underlying cause, I personally wouldn't mind the
null check being committed as a workaround. If you do though, please
could you add a comment saying that this is for SEQUENCEs?
Thanks,
Richard
