[Bug target/104681] New: [9/10/11/12 Regression] ppc64le -mabi=ieeelongdouble ICE since r9-6460

[Bug target/104681] New: [9/10/11/12 Regression] ppc64le -mabi=ieeelongdouble ICE since r9-6460

[jakub at gcc dot gnu.org]

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

            Bug ID: 104681
           Summary: [9/10/11/12 Regression] ppc64le -mabi=ieeelongdouble
                    ICE since r9-6460
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

The following testcase ICEs on powerpc64le-linux with -O2 -mabi=ieeelongdouble
since r9-6460-gb496651b7d281bd1bf22688f4de0cbb78c1bf8e5:
struct A {
  A(bool) : a(__builtin_nansl ("")), b(0) {}
  long double a;
  long b;
};
struct B {
  void foo() {
    void bar();
    c = bar;
  }
  A c;
};
struct C {
  void baz();
  B d;
};
void C::baz() { d.foo(); }
cc7NbdyL.C: In member function ‘void C::baz()’:
cc7NbdyL.C:17:26: error: unrecognizable insn:
   17 | void C::baz() { d.foo(); }
      |                          ^
(insn 6 3 7 2 (set (mem:TF (reg/f:DI 121 [ this ]) [3 MEM[(struct A
*)this_1(D)]+0 S16 A8])
        (const_double:TF +SNaN [+SNaN])) "cc7NbdyL.C":9:7 -1
     (nil))
during RTL pass: vregs
cc7NbdyL.C:17:26: internal compiler error: in extract_insn, at recog.c:2310

I think the reason for it is the movmisalign<mode> expander which is just:
(define_expand "movmisalign<mode>"
 [(set (match_operand:VEC_N 0 "nonimmediate_operand")
       (match_operand:VEC_N 1 "any_operand"))]
 "VECTOR_MEM_VSX_P (<MODE>mode) && TARGET_ALLOW_MOVMISALIGN"
 "")
and so doesn't what normal "mov<mode>" expanders do - rs6000_emit_move - which
e.g. for the MEM destinations and CONST_DOUBLE sources forces the sources into
reg.

[Bug target/104681] [9/10/11/12 Regression] ppc64le -mabi=ieeelongdouble ICE since r9-6460

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
   Target Milestone|---                         |9.5
                 CC|                            |dje at gcc dot gnu.org,
                   |                            |meissner at gcc dot gnu.org,
                   |                            |segher at gcc dot gnu.org,
                   |                            |wschmidt at gcc dot gnu.org
           Keywords|                            |ice-on-valid-code

[Bug target/104681] [9/10/11/12 Regression] ppc64le -mabi=ieeelongdouble ICE since r9-6460

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52513
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52513&action=edit
gcc12-pr104681.patch

Patch I'm testing right now.

[Bug target/104681] [9/10/11/12 Regression] ppc64le -mabi=ieeelongdouble ICE since r9-6460

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Could you just change the insn condition to test if at least one of the
operands is a reg?

[Bug target/104681] [9/10/11/12 Regression] ppc64le -mabi=ieeelongdouble ICE since r9-6460

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
No.
          /* The movmisalign<mode> pattern cannot fail, else the assignment
             would silently be omitted.  */

[Bug target/104681] [9/10/11/12 Regression] ppc64le -mabi=ieeelongdouble ICE since r9-6460

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool <segher at gcc dot gnu.org> ---
We also do the same in define_insn bodies, with a force_reg if needed.

But we do indirect via rs6000_emit_move elsewhere, so let's do that here as
well; it isn't a great idea, but consistency wins, certainly in stage 4.

The patch is okay for trunk.  Thank you!  Any backports as well, if you want.

[Bug target/104681] [9/10/11/12 Regression] ppc64le -mabi=ieeelongdouble ICE since r9-6460

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:3885a122f817a1b6dca4a84ba9e020d5ab2060af

commit r12-7393-g3885a122f817a1b6dca4a84ba9e020d5ab2060af
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Feb 25 18:58:48 2022 +0100

    rs6000: Use rs6000_emit_move in movmisalign<mode> expander [PR104681]

    The following testcase ICEs, because for some strange reason it decides to
use
    movmisaligntf during expansion where the destination is MEM and source is
    CONST_DOUBLE.  For normal mov<mode> expanders the rs6000 backend uses
    rs6000_emit_move to ensure that if one operand is a MEM, the other is a REG
    and a few other things, but for movmisalign<mode> nothing enforced this.
    The middle-end documents that movmisalign<mode> shouldn't fail, so we can't
    force that through predicates or condition on the expander.

    2022-02-25  Jakub Jelinek  <jakub@redhat.com>

            PR target/104681
            * config/rs6000/vector.md (movmisalign<mode>): Use
rs6000_emit_move.

            * g++.dg/opt/pr104681.C: New test.

[Bug target/104681] [9/10/11 Regression] ppc64le -mabi=ieeelongdouble ICE since r9-6460

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
            Summary|[9/10/11/12 Regression]     |[9/10/11 Regression]
                   |ppc64le                     |ppc64le
                   |-mabi=ieeelongdouble ICE    |-mabi=ieeelongdouble ICE
                   |since r9-6460               |since r9-6460
   Last reconfirmed|                            |2022-02-25
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.

[Bug target/104681] [9/10/11 Regression] ppc64le -mabi=ieeelongdouble ICE since r9-6460

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:b59d29392774b115bea0066b4ad1eb2b959a3a2b

commit r11-9721-gb59d29392774b115bea0066b4ad1eb2b959a3a2b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Feb 25 18:58:48 2022 +0100

    rs6000: Use rs6000_emit_move in movmisalign<mode> expander [PR104681]

    The following testcase ICEs, because for some strange reason it decides to
use
    movmisaligntf during expansion where the destination is MEM and source is
    CONST_DOUBLE.  For normal mov<mode> expanders the rs6000 backend uses
    rs6000_emit_move to ensure that if one operand is a MEM, the other is a REG
    and a few other things, but for movmisalign<mode> nothing enforced this.
    The middle-end documents that movmisalign<mode> shouldn't fail, so we can't
    force that through predicates or condition on the expander.

    2022-02-25  Jakub Jelinek  <jakub@redhat.com>

            PR target/104681
            * config/rs6000/vector.md (movmisalign<mode>): Use
rs6000_emit_move.

            * g++.dg/opt/pr104681.C: New test.

    (cherry picked from commit 3885a122f817a1b6dca4a84ba9e020d5ab2060af)

[Bug target/104681] [9/10 Regression] ppc64le -mabi=ieeelongdouble ICE since r9-6460

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[9/10/11 Regression]        |[9/10 Regression] ppc64le
                   |ppc64le                     |-mabi=ieeelongdouble ICE
                   |-mabi=ieeelongdouble ICE    |since r9-6460
                   |since r9-6460               |

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 11.3 too.

[Bug target/104681] [9/10 Regression] ppc64le -mabi=ieeelongdouble ICE since r9-6460

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:cc7bc8b2ba5adc89e99bc7923cd3e822b7d465cf

commit r10-10689-gcc7bc8b2ba5adc89e99bc7923cd3e822b7d465cf
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Feb 25 18:58:48 2022 +0100

    rs6000: Use rs6000_emit_move in movmisalign<mode> expander [PR104681]

    The following testcase ICEs, because for some strange reason it decides to
use
    movmisaligntf during expansion where the destination is MEM and source is
    CONST_DOUBLE.  For normal mov<mode> expanders the rs6000 backend uses
    rs6000_emit_move to ensure that if one operand is a MEM, the other is a REG
    and a few other things, but for movmisalign<mode> nothing enforced this.
    The middle-end documents that movmisalign<mode> shouldn't fail, so we can't
    force that through predicates or condition on the expander.

    2022-02-25  Jakub Jelinek  <jakub@redhat.com>

            PR target/104681
            * config/rs6000/vector.md (movmisalign<mode>): Use
rs6000_emit_move.

            * g++.dg/opt/pr104681.C: New test.

    (cherry picked from commit 3885a122f817a1b6dca4a84ba9e020d5ab2060af)

[Bug target/104681] [9/10 Regression] ppc64le -mabi=ieeelongdouble ICE since r9-6460

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:5c742d9a7e217746de961da20a39f04e5ec1df25

commit r9-10135-g5c742d9a7e217746de961da20a39f04e5ec1df25
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Feb 25 18:58:48 2022 +0100

    rs6000: Use rs6000_emit_move in movmisalign<mode> expander [PR104681]

    The following testcase ICEs, because for some strange reason it decides to
use
    movmisaligntf during expansion where the destination is MEM and source is
    CONST_DOUBLE.  For normal mov<mode> expanders the rs6000 backend uses
    rs6000_emit_move to ensure that if one operand is a MEM, the other is a REG
    and a few other things, but for movmisalign<mode> nothing enforced this.
    The middle-end documents that movmisalign<mode> shouldn't fail, so we can't
    force that through predicates or condition on the expander.

    2022-02-25  Jakub Jelinek  <jakub@redhat.com>

            PR target/104681
            * config/rs6000/vector.md (movmisalign<mode>): Use
rs6000_emit_move.

            * g++.dg/opt/pr104681.C: New test.

    (cherry picked from commit 3885a122f817a1b6dca4a84ba9e020d5ab2060af)

[Bug target/104681] [9/10 Regression] ppc64le -mabi=ieeelongdouble ICE since r9-6460

[jakub at gcc dot gnu.org]

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

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

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

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