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

--- Comment #11 from Kewen Lin <linkw at gcc dot gnu.org> ---
Thanks a lot for Martin's help on reproduction. I can reproduce this ICE and
confirmed that if commenting out my patch r272731 in loop-iv.c, it can pass. I
can also reproduce it on powerpc64 (ppc64-redhat-linux) with -m32.

Looking into the source code of the case, the bound of the loop NSphInp is an
automatic variable and uninitialized, but we still can assert the loop is
finite since it will wrap.

* The ICE occurs on the RTL insn: *

(insn 219 60 61 8 (parallel [
                  (set (reg:SF 184 [ _2 ])
                      (mem:SF (plus:SI (reg/f:SI 110 sfp)
                              (const_int -400 [0xfffffffffffffe70])) [1
MEM[base: _22, offset: 0B]+0 S4 A32]))
                  (set (reg:SI 121 [ ivtmp.11 ])
                      (plus:SI (reg/f:SI 110 sfp)
                          (const_int -400 [0xfffffffffffffe70])))
              ])
"/home/linkw/gcc/gcc-git/gcc/testsuite/gfortran.dg/vect/cost-model-pr34445.f":5:0
659 {*movsf_update1}
           (nil))

The assertion requires it should have single set but this one doesn't.

* In 280r.sched1: *
   67: NOTE_INSN_BASIC_BLOCK 8
  ...
  103: NOTE_INSN_DELETED
   59: {r184:SF=[sfp:SI-0x190];r121:SI=sfp:SI-0x190;}
      REG_UNUSED r121:SI
   77: {r191:SF=[sfp:SI-0x18c];r121:SI=sfp:SI-0x18c;}
   60: r122:SI=r127:SI
      REG_DEAD r127:SI
   61: [r122:SI]=r184:SF
      REG_DEAD r184:SF
   79: [++r122:SI]=r191:SF
      REG_DEAD r191:SF
      REG_INC r122:SI
   ...

* Entering ira 282r.ira: *

  59 gets deleted and generates 219 as below.

   67: NOTE_INSN_BASIC_BLOCK 8
  ...
  103: NOTE_INSN_DELETED
   77: {r191:SF=[sfp:SI-0x18c];r121:SI=sfp:SI-0x18c;}
      REG_UNUSED r121:SI
   60: r122:SI=r127:SI
      REG_DEAD r127:SI
  219: {r184:SF=[sfp:SI-0x190];r121:SI=sfp:SI-0x190;}
   61: [r122:SI]=r184:SF
      REG_DEAD r184:SF
   79: [++r122:SI]=r191:SF
      REG_DEAD r191:SF
      REG_INC r122:SI

1) It can pass with -mno-update since we don't generate that update-form insn
parallel with two SETs.
2) If we disable ira_conflicts_p, it can also pass. I can see the update-form
assembly is generated well. So I think my patch just exposes some ira issue.
3) The original insn 59 has REG_UNUSED, but the new one 219 was put after 77,
then 77 has REG_UNUSED but 219 doesn't, I'll look into why. I assume the
assertion "ira_assert (set != NULL_RTX)" would match some previous analysis
(criteria into the queue), there may be something unexpected.

Reply via email to