[Bug target/84279] [8 Regression] powerpc64le ICE on cvc4

2018-02-14 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84279

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #10 from Peter Bergner  ---
Closing as fixed.

[Bug target/84279] [8 Regression] powerpc64le ICE on cvc4

2018-02-14 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84279

--- Comment #9 from Peter Bergner  ---
Author: bergner
Date: Wed Feb 14 15:17:04 2018
New Revision: 257661

URL: https://gcc.gnu.org/viewcvs?rev=257661=gcc=rev
Log:
gcc/
Back port from mainline
2018-02-13  Peter Bergner  

PR target/84279
* config/rs6000/rs6000.c (mem_operand_gpr): Disallow altivec addresses.

gcc/testsuite/
Back port from mainline
2018-02-13  Peter Bergner  

PR target/84279
* g++.dg/pr84279.C: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/pr84279.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/84279] [8 Regression] powerpc64le ICE on cvc4

2018-02-13 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84279

Peter Bergner  changed:

   What|Removed |Added

   Target Milestone|8.0 |7.4

[Bug target/84279] [8 Regression] powerpc64le ICE on cvc4

2018-02-13 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84279

Peter Bergner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Peter Bergner  ---
Fixed on trunk.

[Bug target/84279] [8 Regression] powerpc64le ICE on cvc4

2018-02-13 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84279

--- Comment #7 from Peter Bergner  ---
Author: bergner
Date: Tue Feb 13 23:05:59 2018
New Revision: 257647

URL: https://gcc.gnu.org/viewcvs?rev=257647=gcc=rev
Log:
gcc/
PR target/84279
* config/rs6000/rs6000.c (mem_operand_gpr): Disallow altivec addresses.

gcc/testsuite/
PR target/84279
* g++.dg/pr84279.C: New test.

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

[Bug target/84279] [8 Regression] powerpc64le ICE on cvc4

2018-02-12 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84279

--- Comment #6 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #5)
> I think you should do this check inside address_offset?

I don't think that is possible.  The callers of address_offset assume if
address_offset returns a non-NULL rtx, then it *IS* a constant (eg, they use
INTVAL() on its return value).  The problematical address we have here doesn't
have constant offset, so to "change" anything, we'd have to return non-NULL
(otherwise we return true from mem_operand_gpr) and that would cause issues
with INTVAL...or I'd have to guard all return values of address_offset.

I'll also note that the patch also matches the usage of mem_operand_ds_form()
which also has an early out for an unsupported case before it calls
address_offset:

bool
mem_operand_ds_form (rtx op, machine_mode mode)
{
  unsigned HOST_WIDE_INT offset;
  int extra;
  rtx addr = XEXP (op, 0);

  if (!offsettable_address_p (false, mode, addr))
return false;

  op = address_offset (addr);
  if (op == NULL_RTX)
return true;

...

[Bug target/84279] [8 Regression] powerpc64le ICE on cvc4

2018-02-12 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84279

--- Comment #5 from Segher Boessenkool  ---
I think you should do this check inside address_offset?

[Bug target/84279] [8 Regression] powerpc64le ICE on cvc4

2018-02-12 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84279

--- Comment #4 from Peter Bergner  ---
This actually seems to be a constraint problem caused by mem_operand_gpr()
which implements the "Y" constraint (ie, mem's ok for GPR load/stores) allowing
altivec type addresses that contain the 'and' like we see in the ICE above. 
The patch below fixes the ICE and I'm going to bootstrap and regtest it.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 257606)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -8220,6 +8220,12 @@
   int extra;
   rtx addr = XEXP (op, 0);

+  /* Don't allow altivec type addresses like (mem: (and: ...)).
+ See PR target/84279.  */
+
+  if (GET_CODE (addr) == AND)
+return false;
+
   op = address_offset (addr);
   if (op == NULL_RTX)
 return true;

[Bug target/84279] [8 Regression] powerpc64le ICE on cvc4

2018-02-09 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84279

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org

--- Comment #3 from Peter Bergner  ---
This looks to be a similar problem that I fixed in PR83399 except that the
store here isn't generated by a builtin, but by Kelvin's optimization here:

  https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01115.html

My guess is we'll need a similar fix here, meaning tighten some predicates used
in some vsx patterns/splitters.  I'll have a look.

[Bug target/84279] [8 Regression] powerpc64le ICE on cvc4

2018-02-09 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84279

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2018-02-08 00:00:00 |2018-02-09
 Ever confirmed|0   |1

[Bug target/84279] [8 Regression] powerpc64le ICE on cvc4

2018-02-08 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84279

Peter Bergner  changed:

   What|Removed |Added

   Last reconfirmed||2018-2-8
 CC||bergner at gcc dot gnu.org

--- Comment #2 from Peter Bergner  ---
Confirmed.

[Bug target/84279] [8 Regression] powerpc64le ICE on cvc4

2018-02-08 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84279

--- Comment #1 from Jakub Jelinek  ---
pr84279.C: In member function ‘void B::m5(B::D*)’:
pr84279.C:29:79: error: could not split insn
 void B::m5 (D *c) { unsigned x; C ar; A am; if (ar.m1 (c->e, am)) m6 (x, am);
}
  
^
(insn:TI 121 137 175 (set (mem/c:V4SI (and:DI (plus:DI (reg:DI 9 9 [172])
(reg:DI 6 6 [158]))
(const_int -16 [0xfff0])) [3 MEM[(struct A *)]+0
S16 A128])
(reg:V4SI 4 4 [141])) "pr84279.C":25 1042 {*vsx_movv4si_64bit}
 (expr_list:REG_DEAD (reg:DI 9 9 [172])
(expr_list:REG_DEAD (reg:DI 6 6 [158])
(expr_list:REG_DEAD (reg:V4SI 4 4 [141])
(nil)
during RTL pass: final
pr84279.C:29:79: internal compiler error: in final_scan_insn, at final.c:2997
0x115bfdd _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0xd92138 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/final.c:2997
0xd90224 final(rtx_insn*, _IO_FILE*, int)
../../gcc/final.c:1999
0xd94fed rest_of_handle_final
../../gcc/final.c:4485
0xd95304 execute
../../gcc/final.c:4559
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/84279] [8 Regression] powerpc64le ICE on cvc4

2018-02-08 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84279

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
   Target Milestone|--- |8.0