https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78038
--- Comment #3 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #2)
> Hmm, so the zero_extend candidate is:
> (insn 9 10 11 2 (set (reg/f:DI 1 x1 [orig:74 g.1_2 ] [74])
> (zero_extend:DI (reg/v:SI 28 x28 [ g ]))) "ree.c":16 84
> {*zero_extendsidi2_aarch64}
> (nil))
>
> and the def_insn that causes the ICE in get_sub_rtx is:
> (call_insn 8 7 10 2 (parallel [
> (call (mem:DI (reg/f:DI 0 x0 [orig:77 test_fptr ] [77]) [0
> *test_fptr.0_1 S8 A8])
> (const_int 0 [0]))
> (use (const_int 0 [0]))
> (clobber (reg:DI 30 x30))
> ]) "ree.c":14 41 {*call_reg}
> (expr_list:REG_CALL_DECL (nil)
> (nil))
> (expr_list (clobber (reg:DI 17 x17))
> (expr_list (clobber (reg:DI 16 x16))
> (nil))))
>
> This doesn't have a SET anywhere in it so it causes the ICE.
> The question is, by what logic did dataflow decide that call_insn 8 defines
> register x28?
I suppose it's because of:
register struct test2_s *g __asm__("x28");
Are calls assumed to clobber/write such things?
