[Bug target/66785] internal compiler error in record_operand_use

[jgreenhalgh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66785

James Greenhalgh <jgreenhalgh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #35920|0                           |1
        is obsolete|                            |
                 CC|                            |jgreenhalgh at gcc dot gnu.org

--- Comment #1 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> ---
Created attachment 36341
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36341&action=edit
Reduced testcase without Undefined Behaviour

Confirmed with the testcase updated to avoid Undefined Behaviour.

It isn't immediately clear what is going wrong here, the ICE occurs before any
of the cortex-a57-fma-steering analysis kicks in, which implies an issue in the
generic register rename analysis code. The assert trips on this line:

  gcc_assert (cur_operand->n_chains < MAX_REGS_PER_ADDRESS);

When handling this rtx:

  (insn 403 78 417 4 (set (mem:XI (post_inc:DI (reg:DI 17 x17 [orig:205
ivtmp.18 ] [205])) [4 MEM[(float *)vectp_pretmp.12_54]+0 S64 A32])
        (unspec:XI [
                (reg:XI 32 v0 [orig:165 vect_array.14 ] [165])
                (unspec:V4SF [
                        (const_int 0 [0])
                    ] UNSPEC_VSTRUCTDUMMY)
            ] UNSPEC_ST4)) error.c:20 2372 {aarch64_simd_st4v4sf}
     (expr_list:REG_INC (reg:DI 17 x17 [orig:205 ivtmp.18 ] [205])
        (nil)))

In this case n_chains is either 2 or 3 and MAX_REGS_PER_ADDRESS for aarch64 is
set to 2, so we trip the assert.

I don't know regrename at all, so I'm not sure how we get in to this situation.