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.
