[Bug target/65242] New: [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[Bug target/65242] New: [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

            Bug ID: 65242
           Summary: [5 Regression] ICE (in gen_add2_insn, at
                    optabs.c:4761) on powerpc64le-linux-gnu
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at gcc dot gnu.org

with r221042

$ g++ -c -g -O3 loadbi3.ii 
loadbi3.ii: In function 'void J::m_fn8()':
loadbi3.ii:91:1: internal compiler error: in gen_add2_insn, at optabs.c:4761
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

$ cat loadbi3.ii
class A {
public:
  int m_fn1();
};
class B {
public:
  enum IOMode { reading };
};
class tn_file_buf_stream : B {
public:
  tn_file_buf_stream(IOMode);
  ~tn_file_buf_stream();
};
class C {
public:
  int &operator[](int);
};
class D {
public:
  bool m_fn2();
};
class F {
public:
  int m_fn3(D &);
};
class G {
public:
  D bdt;
};
class ObjectType {
public:
  int id;
  D weather;
  struct H {
    F terrainaccess;
  };
  H m_fn4();
  struct {
    A images;
  } weatherPicture[];
  ObjectType *m_fn5();
  int m_fn6();
} a;
#pragma pack(1)
class I {};
class J {
  J(I *);
  I translationTableTMISSPart;
  void m_fn8();
  tn_file_buf_stream *MissFile;
  void m_fn9();
  virtual G *m_fn7(int, int);
};
int b, c, d, g;
int e[5];
short f;
void J::m_fn9() {
  int h;
  C k;
  for (; b;) {
    int l = c, n = c & 1;
    for (int m; d;) {
      int o = 0;
      for (int p = 0; p < 2 && !o; p++)
        if (g)
          for (int i; i < a.m_fn6(); i++) {
            ObjectType *q = a.m_fn5();
            for (int r = 0; r < 6; r++)
              if (q->weather.m_fn2())
                for (int j; j < q->weatherPicture[r].images.m_fn1(); j++)
                  if (e[m]) {
                    G *s = m_fn7(l, n);
                    if (q->m_fn4().terrainaccess.m_fn3(s->bdt))
                      g = o = 1;
                  }
          }
      k[h++] = f;
    }
  }
}

void J::m_fn8() try {
  tn_file_buf_stream t(B::reading);
  MissFile = &t;
  m_fn9();
  J u(0);
  u.m_fn8();
}

catch (int) {
}

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #2 from Matthias Klose <doko at gcc dot gnu.org> ---
shorter testcase from another package:

$ g++ -c -g -O3 -Wno-write-strings Channel.ii 
Channel.ii: In member function 'void C::m_fn2()':
Channel.ii:46:1: internal compiler error: in gen_add2_insn, at optabs.c:4761
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

$ cat Channel.ii
enum tCapiStructType { cxt_FacilityReq_WakeUp, cxt_FacilityReq_WakeUpParam };
class CCStruct {
public:
  virtual ~CCStruct();
  CCStruct(tCapiStructType, void *);
  tCapiStructType m_DataType;
  char *m_Format;
  int m_MaxLen;
  unsigned char *m_pData;
};
char a;
class A {
public:
  A();
};
class B {
public:
  void m_fn1(unsigned *);
};
class C {
  void m_fn2();
  int m_fn3();
};
unsigned b;
int c;
CCStruct::CCStruct(tCapiStructType p1, void *p2)
    : m_DataType(p1), m_Format(&a), m_MaxLen(), m_pData((unsigned char *)p2) {}

#pragma pack(1)
class D : CCStruct {
public:
  D()
      : CCStruct(cxt_FacilityReq_WakeUpParam, &pCalledPartyNumber),
        pCalledPartyNumber() {}
  A *pCalledPartyNumber;
  A m_CalledPartyNumber;
};

void C::m_fn2() {
  do {
    B d;
    D e;
    d.m_fn1(&b);
    new D[c];
  } while (m_fn3());
}

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner <bergner at gcc dot gnu.org> ---
The debugger shows:

#1  0x0000000010d0d2ec in gen_add2_insn (x=0x3fffb57ddf08, y=0x3fffb57dded8)
    at /home/bergner/gcc/gcc-fsf-mainline-PR65242/gcc/optabs.c:4761
4761      gcc_assert (insn_operand_matches (icode, 2, y));
(gdb) pr x
(reg:DI 32 0)
(gdb) pr y
(mem/u/c:DI (lo_sum:DI (high:DI (unspec:DI [
                    (symbol_ref/u:DI ("*.LC2") [flags 0x2])
                    (reg:DI 2 2)
                ] UNSPEC_TOCREL))
        (unspec:DI [
                (symbol_ref/u:DI ("*.LC2") [flags 0x2])
                (reg:DI 2 2)
            ] UNSPEC_TOCREL)) [14  S8 A64])

Talking with Mike, he said this is a fusion issue, so I'm going to leave this
one for him.

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
   Target Milestone|---                         |5.0

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
Although the error is different, similarly to pr65278, unable to reproduce with
a stage1 compiler.  Will try after bootstrapping.

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
Unable to reproduce with either test case and either stage1 or a fully
bootstrapped 5.0.0 20150302 on ppc64le.

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law <law at redhat dot com> ---
So I think two things are coming into play with reproducing these issues. 
First an inaccurate trunk version #.  r221042 is not a trunk commit.  I was
able to reproduce with r221041 which is a trunk commit.  Odds are Matthias
typo'd.

Second, these issues are highly dependent upon reloads actions which are known
to be notoriously difficult to predict and are easily perturbed.

So using r221041 or d21bee29dffb3724605183d17983dfc9f0ee6f21 for the GIT folks,
I was able to reproduce with the original testcase without problems.

There's a few key insns in play here.  The most important (from the IRA dump)
is:

(insn 32 33 128 3 (set (mem/f:DI (plus:DI (reg/f:DI 203 [ this ])
                (const_int 9 [0x9])) [6 this_1(D)->MissFile+0 S8 A8])
        (reg/f:DI 264)) j.C:84 467 {*movdi_internal64}
     (nil))


r203 will get a suitable hard register (r25).  r264 will not.  r264 is set via:

(insn 26 18 17 2 (set (reg/f:DI 264)
        (plus:DI (reg/f:DI 113 sfp)
            (const_int 51 [0x33]))) j.C:83 81 {*adddi3}
     (expr_list:REG_EQUIV (plus:DI (reg/f:DI 113 sfp)
            (const_int 51 [0x33]))
        (nil)))

I'm guessing sfp is a soft frame pointer or some-such eliminable register. 
Anyway, the REG_EQUIV note for r264 gets shoved into insn 32 resulting in:

(insn 32 33 128 3 (set (mem/f:DI (plus:DI (reg/f:DI 25 25 [orig:203 this ]
[203])
                (const_int 9 [0x9])) [6 this_1(D)->MissFile+0 S8 A8])
        (plus:DI (reg/f:DI 1 1)
            (const_int 51 [0x33]))) j.C:84 467 {*movdi_internal64}
     (nil))


We record the following reloads:

Reload 0: BASE_REGS, RELOAD_FOR_OPADDR_ADDR (opnum = 0), optional, can't
combine, secondary_reload_p
Reload 1: GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0), optional, can't
combine, secondary_reload_p
        secondary_out_reload = 0

        secondary_out_icode = reload_di_store
Reload 2: reload_out (DI) = (mem/f:DI (plus:DI (reg/f:DI 25 25 [orig:203 this ]
[203])
                                                        (const_int 9 [0x9])) [6
this_1(D)->MissFile+0 S8 A8])
        NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
        reload_out_reg: (mem/f:DI (plus:DI (reg/f:DI 25 25 [orig:203 this ]
[203])
                                                        (const_int 9 [0x9])) [6
this_1(D)->MissFile+0 S8 A8])
        secondary_out_reload = 1

Reload 3: reload_in (DI) = (plus:DI (reg/f:DI 1 1)
                                                    (mem/u/c:DI (unspec:DI [
                                                               
(symbol_ref/u:DI ("*.LC4") [flags 0x2])
                                                                (reg:DI 2 2)
                                                            ] UNSPEC_TOCREL)
[13  S8 A64]))
        FLOAT_REGS, RELOAD_FOR_INPUT (opnum = 1), can't combine
        reload_in_reg: (plus:DI (reg/f:DI 1 1)
                                                    (const_int 51 [0x33]))

Ugh.  So many bad things happening here I want to cry.  But I'll focus on
reload #3, note FLOAT_REGS.

In gen_add2_insn we have:
(gdb) p debug_rtx (x)
(reg:DI 32 0)
$107 = void
(gdb) p debug_rtx (y)
(mem/u/c:DI (unspec:DI [
            (symbol_ref/u:DI ("*.LC4") [flags 0x2])
            (reg:DI 2 2)
        ] UNSPEC_TOCREL) [13  S8 A64])
$108 = void

Note the register used for X.  This is a direct result of FLOAT_REGS as the
class for reload #3.

So going to the appropriate insn in the MD file we have:

(define_insn "*movdi_internal64"
  [(set (match_operand:DI 0 "nonimmediate_operand"
"=Y,r,r,r,r,r,?m,?*d,?*d,r,*h,*h,r,?*wg,r,?*wj,?*wi")
        (match_operand:DI 1 "input_operand"
"r,Y,r,I,L,nF,d,m,d,*h,r,0,*wg,r,*wj,r,O"))]

Note carefully the constraints for alternative #7.  op0  is "?m" and op1 is
"d".  

The odd offset in the address computation for operand0 causes mem_operand_opr
not to match and thus we ultimately target alternative #7.  And "d" happens to
be FP regs for double values, presumably FLOAT_REGS.  And ultimately this
causes the ICE when we try to realize the recorded reloads.

That seems a particularly bad alternative to select.  One could easily argue
the constraint for operand 0, alterantive 7 should be "!m".  In fact, if I do
that, the test passes and a peek at the reloads we generate for the
problematical insn look much better.

I'm far from a expert in the PPC backend and not confident enough to propose
this patch and find other instances that might need similar updates.  But
perhaps this saves someone else some analysis time.

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[dje at gcc dot gnu.org]

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

--- Comment #7 from David Edelsohn <dje at gcc dot gnu.org> ---
I'll defer to Mike for deeper analysis, but changing ?m to !m seems very
reasonable.

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

--- Comment #8 from Michael Meissner <meissner at gcc dot gnu.org> ---
I'm going to start looking at this.  I suspect the issue is we need more checks
about the offset in TOC references.  In particular, the 64-bit GPR load/store
instruction (ld, std), the sign-extended 32-bit load (lwa), and 128-bit
load/store (lq, stq) are B-form instructions instead of D-form, meaning that
the bottom 2 bits of the offset are required to be zero, and the encoding uses
these bits for other purposes.

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

--- Comment #9 from Michael Meissner <meissner at gcc dot gnu.org> ---
Created attachment 34994
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34994&action=edit
Proposed patch to fix the problem

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
While touching the comment, can you please also fix up the floaitng typo?

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

Michael Meissner <meissner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #34994|0                           |1
        is obsolete|                            |

--- Comment #11 from Michael Meissner <meissner at gcc dot gnu.org> ---
Created attachment 34996
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34996&action=edit
Proposed patch to fix the problem (plus fix comment & add test case)

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

Michael Meissner <meissner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #34996|0                           |1
        is obsolete|                            |

--- Comment #12 from Michael Meissner <meissner at gcc dot gnu.org> ---
Created attachment 34998
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34998&action=edit
Proposed patch to fix the problem (plus fix comment #2 & add test case)

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

Michael Meissner <meissner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

--- Comment #13 from Michael Meissner <meissner at gcc dot gnu.org> ---
My gut feeling is we don't want to change ?m to !m, because it might impact
floating point conversions <-> integer, where we need the DI mode in a floating
point register.  In addition, I might worry that it could impact breaking apart
_Decimal128 values, which I believe uses DImode for the two parts.  I was also
trying to make the minimal change, and I didn't want an iteration where we fix
up any collateral damage.

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

--- Comment #14 from Michael Meissner <meissner at gcc dot gnu.org> ---
Author: meissner
Date: Wed Mar 11 16:57:41 2015
New Revision: 221350

URL: https://gcc.gnu.org/viewcvs?rev=221350&root=gcc&view=rev
Log:
[gcc]
2015-03-09  Michael Meissner  <meissner@linux.vnet.ibm.com>

    PR target/65242
    * config/rs6000/rs6000.c (rs6000_preferred_reload_class): Do not
    allow reloads of PLUS in floating point/VSX registers.

[gcc/testsuite]
2015-03-09  Michael Meissner  <meissner@linux.vnet.ibm.com>

    PR target/65242
    * g++.dg/pr65242.C: New test.


Added:
    trunk/gcc/testsuite/g++.dg/pr65242.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/rs6000/rs6000.c
    trunk/gcc/testsuite/ChangeLog

[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed, thanks.