[Bug c++/70761] New: C++ ICE on ppc64le and ppc64 with -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70761
Bug ID: 70761
Summary: C++ ICE on ppc64le and ppc64 with -m64
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: markos at freevec dot org
Target Milestone: ---
Target: ppc64le, ppc64
Created attachment 38326
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38326&action=edit
Reduced testcase for ICE on ppc64/ppc64le
On ppc64le (Debian testing, g++ 5.3.1-14)
$ g++-5 -O2 testcase.cpp
testcase.cpp: In function ‘void x36()’:
testcase.cpp:150:1: error: unable to generate reloads for:
}
^
(jump_insn 10 5 11 2 (parallel [
(set (pc)
(if_then_else (eq (reg:DI 3 3)
(const_int 1 [0x1]))
(label_ref:DI 20)
(pc)))
(set (reg:DI 63 31 [orig:157 D.3107 ] [157])
(plus:DI (reg:DI 3 3)
(const_int -1 [0x])))
(clobber (scratch:CC))
(clobber (scratch:DI))
]) testcase.cpp:132 794 {*ctrdi_internal5}
(expr_list:REG_DEAD (reg:DI 3 3)
(int_list:REG_BR_PROB 4877 (nil)))
-> 20)
testcase.cpp:150:1: internal compiler error: in find_reloads, at reload.c:3862
0x102c425b _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:110
0x109dcd8f find_reloads(rtx_insn*, int, int, int, short*)
../../src/gcc/reload.c:3862
0x109f03a3 calculate_needs_all_insns
../../src/gcc/reload1.c:1540
0x109f03a3 reload(rtx_insn*, int)
../../src/gcc/reload1.c:1028
0x10903027 do_reload
../../src/gcc/ira.c:5454
0x10903027 execute
../../src/gcc/ira.c:5613
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
On powerpc32 (Debian testing, g++ 5.3.1-14, only when -m64 is added)
$ g++-5 -m64 -O2 testcase.cpp
testcase.cpp: In function ‘void x36()’:
testcase.cpp:150:1: error: unable to generate reloads for:
}
^
(jump_insn 10 5 11 2 (parallel [
(set (pc)
(if_then_else (eq (reg:DI 3 3)
(const_int 1 [0x1]))
(label_ref:DI 20)
(pc)))
(set (reg:DI 63 31 [orig:157 D.3085 ] [157])
(plus:DI (reg:DI 3 3)
(const_int -1 [0x])))
(clobber (scratch:CC))
(clobber (scratch:DI))
]) testcase.cpp:132 794 {*ctrdi_internal5}
(expr_list:REG_DEAD (reg:DI 3 3)
(int_list:REG_BR_PROB 4877 (nil)))
-> 20)
testcase.cpp:150:1: internal compiler error: in find_reloads, at reload.c:3862
0x1027c933 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:110
0x108ecbf7 find_reloads(rtx_insn*, int, int, int, short*)
../../src/gcc/reload.c:3862
0x108feefb calculate_needs_all_insns
../../src/gcc/reload1.c:1540
0x108feefb reload(rtx_insn*, int)
../../src/gcc/reload1.c:1028
0x1082d9db do_reload
../../src/gcc/ira.c:5454
0x1082d9db execute
../../src/gcc/ira.c:5613
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
Reduced testcase attached, same for both architectures
[Bug target/70963] New: vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963 Bug ID: 70963 Summary: vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point Product: gcc Version: 5.3.1 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: markos at freevec dot org Target Milestone: --- Host: powerpc64le-linux-gnu Target: powerpc64le-linux-gnu Build: powerpc64le-linux-gnu Created attachment 38420 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38420&action=edit small test program to verify vec_cts/vec_ctf working on doubles I've noticed some tests in Eigen failing for VSX 64-bit doubles code, when the algorithm looked perfectly normal. Further investigation -and comparison with direct output using same inputs from an SSE test program, showed that the conversion to integer yielded 0 results in the case of VSX (vec_cts basically returned 0 vectors). I've written a small test case that verifies this on both big/little endian VSX-capable systems (compiled with -m64 -mvsx). When using the intrinsic the result is wrong, when using the inline asm version, it works as expected. I could not test it in a more recent gcc so it may well be fixed, however it would be great if this would be backported to gcc 5. Some asm output follows from test program (attached): vec_cts: 166c: 60 67 00 f0 xvcvdpsxds vs0,vs12 1670: 50 02 00 f0 xxswapd vs0,vs0 asm: 1674: 51 02 00 f0 xxswapd vs32,vs0 1678: 60 07 00 f0 xvcvdpsxds vs0,vs0 167c: 56 02 00 f0 xxswapd vs0,vs32 vec_ctf: 16f8: 50 02 00 f0 xxswapd vs0,vs0 16fc: e0 07 00 f0 xvcvsxddp vs0,vs0 1700: 50 02 00 f0 xxswapd vs0,vs0 asm: 16f8: 51 02 00 f0 xxswapd vs32,vs0 16fc: e0 07 00 f0 xvcvsxddp vs0,vs0 1700: 56 02 00 f0 xxswapd vs0,vs32
[Bug target/70963] vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963 --- Comment #5 from Konstantinos Margaritis --- Ack, thanks for the heads up on VSX registers, it does print more reasonable results now.
[Bug target/82317] New: error "'__builtin_s390_vec_min' matching variant requires z14 or higher" for __vector(2) double when it should work on -march=z13 as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82317
Bug ID: 82317
Summary: error "'__builtin_s390_vec_min' matching variant
requires z14 or higher" for __vector(2) double when it
should work on -march=z13 as well
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: markos at freevec dot org
Target Milestone: ---
Host: s390x-ibm-linux-gnu
Target: s390x-ibm-linux-gnu
Build: s390x-ibm-linux-gnu
While trying to extend SIMD code that worked on z13 to z14, I ran into this
error (using latest gcc snapshot:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/lib64/gcc/s390x-ibm-linux-gnu/8.0.0/lto-wrapper
Target: s390x-ibm-linux-gnu
Configured with: ../configure --prefix=/usr/local --libdir=/usr/local/lib64
--libexecdir=/usr/local/lib64 --enable-languages=c,c++
--enable-checking=release --enable-ssp --disable-libssp --disable-libvtv
--disable-plugin --disable-libgcj --with-system-zlib --enable-__cxa_atexit
--enable-linker-build-id --enable-linux-futex --without-system-libunwind
--with-tune=z13 --with-arch=z13 --with-long-double-128 --enable-decimal-float
Thread model: posix
gcc version 8.0.0 20170924 (experimental) (GCC)
$ /usr/local/bin/g++-pedantic -Wall -Wextra -Wundef -Wcast-align
-Wchar-subscripts -Wnon-virtual-dtor -Wunused-local-typedefs -Wpointer-arith
-Wwrite-strings -Wformat-security -Wlogical-op -Wdouble-promotion -Wno-psabi
-Wno-variadic-macros -Wno-long-long -fno-check-new -fno-common
-fstrict-aliasing -ansi -march=z13 -mzvector -std=c++11 -g
-I/srv/data/eigen.mine/build/test -I/srv/data/eigen.mine/test
-I/srv/data/eigen.mine -I/srv/data/eigen.mine/build
-DEIGEN_TEST_MAX_SIZE=320 -DEIGEN_TEST_FUNC=packetmath -DEIGEN_FAST_MATH=1
-DEIGEN_TEST_PART_1=1 -o CMakeFiles/packetmath_1.dir/packetmath.cpp.o -c
/srv/data/eigen.mine/test/packetmath.cpp
In file included from /srv/data/eigen.mine/Eigen/Core:426:0,
from /srv/data/eigen.mine/Eigen/QR:11,
from /srv/data/eigen.mine/test/main.h:259,
from /srv/data/eigen.mine/test/packetmath.cpp:11:
/srv/data/eigen.mine/Eigen/src/Core/arch/ZVector/PacketMath.h: In function
'Packet Eigen::internal::pmin(const Packet&, const Packet&) [with Packet =
__vector(2) double]':
/srv/data/eigen.mine/Eigen/src/Core/arch/ZVector/PacketMath.h:425:115: error:
'__builtin_s390_vec_min' matching variant requires z14 or higher
template<> EIGEN_STRONG_INLINE Packet2d pmin(const Packet2d& a,
const Packet2d& b) { return vec_min(a, b); }
Packet2d is a typedef of __vector double.
This code is compiled with both -march=z13 and z14 options as I need to keep
compatibility with existing z13 systems and it compiles fine with an older
compiler (gcc 6), meaning vec_min() is available on z13 for double vectors. So
either the intrinsic name has changed in latest version (gcc 8 snapshot) or
this is a bug?
Thanks
[Bug target/82322] New: vec_ceil/vec_floor/vec_round intrincics do not work for gcc 8, need __builtin_s390_vfidb.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82322
Bug ID: 82322
Summary: vec_ceil/vec_floor/vec_round intrincics do not work
for gcc 8, need __builtin_s390_vfidb.
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: markos at freevec dot org
Target Milestone: ---
Host: s390x-ibm-linux-gnu
Target: s390x-ibm-linux-gnu
Build: s390x-ibm-linux-gnu
Created attachment 42233
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42233&action=edit
testcase demonstrating compiler error for vec_round, etc.
When trying to compile the attached source with gcc 8.0.0:
> g++ -mzvector -march=z14 /home/markos/Development/zvectortest.cpp -o
> /home/markos/Development/zvectortest
In file included from /home/markos/Development/zvectortest.cpp:1:0:
/home/markos/Development/zvectortest.cpp: In function 'Packet2d pround(const
Packet2d&)':
/home/markos/Development/zvectortest.cpp:6:45: error: '__builtin_s390_vfi' was
not declared in this scope
Packet2d pround(const Packet2d& a) { return vec_round(a); }
^
/home/markos/Development/zvectortest.cpp:6:45: note: suggested alternative:
'__builtin_s390_vfidb'
/home/markos/Development/zvectortest.cpp: In function 'Packet2d pceil(const
Packet2d&)':
/home/markos/Development/zvectortest.cpp:7:45: error: '__builtin_s390_vfi' was
not declared in this scope
Packet2d pceil(const Packet2d& a) { return vec_ceil(a); }
^~~~
/home/markos/Development/zvectortest.cpp:7:45: note: suggested alternative:
'__builtin_s390_vfidb'
/home/markos/Development/zvectortest.cpp: In function 'Packet2d pfloor(const
Packet2d&)':
/home/markos/Development/zvectortest.cpp:8:45: error: '__builtin_s390_vfi' was
not declared in this scope
Packet2d pfloor(const Packet2d& a) { return vec_floor(a); }
^
/home/markos/Development/zvectortest.cpp:8:45: note: suggested alternative:
'__builtin_s390_vfidb'
Same result with -march=z13. Works fine with g++-6.
However, it worked with both compilers if I add the code with #ifdef __GNUC__ <
8 and use helper defines using __builtin_s390_vfidb() intrinsic.
[Bug target/82322] [7/8 Regression] vec_ceil/vec_floor/vec_round intrincics do not work for gcc 8, need __builtin_s390_vfidb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82322 Konstantinos Margaritis changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #4 from Konstantinos Margaritis --- Confirmed that the bug is fixed.
[Bug target/82317] [8 Regression] "'__builtin_s390_vec_min' matching variant requires z14 or higher" for __vector(2) double when it should work on -march=z13 as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82317 Konstantinos Margaritis changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #4 from Konstantinos Margaritis --- Confirmed that the bug is fixed.
[Bug target/82463] New: vec_madd does not map to __builtin_s390_vfmasb for z14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82463
Bug ID: 82463
Summary: vec_madd does not map to __builtin_s390_vfmasb for z14
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: markos at freevec dot org
Target Milestone: ---
Host: s390x-ibm-linux-gnu
Target: s390x-ibm-linux-gnu
Build: s390x-ibm-linux-gnu
Trying to compile the simple test case breaks:
#include
typedef __vector float Packet4f;
int main() {
Packet4f v1 = { 1.0, -1.0, -2.0, 2.0 };
Packet4f v2 = { 2.0, 0.5, 0.1, 0.2 };
Packet4f v0 = { 0.0, 0.0, 0.0, 0.0 };
Packet4f prod = vec_madd(v1, v2, v0);
}
g++ -march=z14 -mzvector zvectortest2.cpp -o zvectortest2
zvectortest2.cpp: In function 'int main()':
zvectortest2.cpp:10:37: error: cannot convert 'Packet4f {aka __vector(4)
float}' to '__vector(2) double' for argument '1' to '__vector(2) double
__builtin_s390_vfmadb(__vector(2) double, __vector(2) double, __vector(2)
double)'
Packet4f prod = vec_madd(v1, v2, v0);
Changing to __builtin_s390_vfmasb explicitly seems to work.
[Bug target/82464] New: s390x z14: vector float: invalid parameter combination for intrinsic '__builtin_s390_vec_xor'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82464
Bug ID: 82464
Summary: s390x z14: vector float: invalid parameter combination
for intrinsic '__builtin_s390_vec_xor'
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: markos at freevec dot org
Target Milestone: ---
Host: s390x-ibm-linux-gnu
Target: s390x-ibm-linux-gnu
Build: s390x-ibm-linux-gnu
In this small testcase:
#include
typedef __vector float Packet4f;
int main() {
Packet4f v1 = { 1.0, -1.0, -2.0, 2.0 };
Packet4f v2 = { 2.0, 0.5, 0.1, 0.2 };
Packet4f prod = vec_xor(v1, v2);
}
$ g++ -march=z14 -mzvector zvectortest2.cpp -o zvectortest2
zvectortest2.cpp: In function 'int main()':
zvectortest2.cpp:9:32: error: invalid parameter combination for intrinsic
'__builtin_s390_vec_xor'
Packet4f prod = vec_xor(v1, v2);
However it works with vec_or() intrinsic and others (vec_and, etc), I guess
it's just an ommission.
[Bug target/82463] vec_madd does not map to __builtin_s390_vfmasb for z14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82463 Konstantinos Margaritis changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Konstantinos Margaritis --- accidentally pressed submit twice, duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82462 *** This bug has been marked as a duplicate of bug 82462 ***
[Bug target/82462] New: vec_madd does not map to __builtin_s390_vfmasb for z14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82462
Bug ID: 82462
Summary: vec_madd does not map to __builtin_s390_vfmasb for z14
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: markos at freevec dot org
Target Milestone: ---
Host: s390x-ibm-linux-gnu
Target: s390x-ibm-linux-gnu
Build: s390x-ibm-linux-gnu
Trying to compile the simple test case breaks:
#include
typedef __vector float Packet4f;
int main() {
Packet4f v1 = { 1.0, -1.0, -2.0, 2.0 };
Packet4f v2 = { 2.0, 0.5, 0.1, 0.2 };
Packet4f v0 = { 0.0, 0.0, 0.0, 0.0 };
Packet4f prod = vec_madd(v1, v2, v0);
}
g++ -march=z14 -mzvector zvectortest2.cpp -o zvectortest2
zvectortest2.cpp: In function 'int main()':
zvectortest2.cpp:10:37: error: cannot convert 'Packet4f {aka __vector(4)
float}' to '__vector(2) double' for argument '1' to '__vector(2) double
__builtin_s390_vfmadb(__vector(2) double, __vector(2) double, __vector(2)
double)'
Packet4f prod = vec_madd(v1, v2, v0);
Changing to __builtin_s390_vfmasb explicitly seems to work.
--- Comment #1 from Konstantinos Margaritis ---
*** Bug 82463 has been marked as a duplicate of this bug. ***
[Bug target/82465] New: vec_sqrt() for vector double erroneously fails for z13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82465
Bug ID: 82465
Summary: vec_sqrt() for vector double erroneously fails for z13
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: markos at freevec dot org
Target Milestone: ---
Host: s390x-ibm-linux-gnu
Target: s390x-ibm-linux-gnu
Build: s390x-ibm-linux-gnu
The following code:
#include
int main() {
__vector double v = { 2.0, 1.0 };
__vector double prod = vec_sqrt(v);
}
works for z14 as expected, but fails on z13:
$ g++ -march=z13 -mzvector zvectortest2.cpp -o zvectortest2
zvectortest2.cpp: In function 'int main()':
zvectortest2.cpp:6:35: error: '__vector(4) int
__builtin_s390_vec_sqrt(__vector(4) int)' requires z14 or higher
__vector double prod = vec_sqrt(v);
I think this is a bug.
[Bug target/82464] s390x z14: vector float: invalid parameter combination for intrinsic '__builtin_s390_vec_xor'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82464 --- Comment #4 from Konstantinos Margaritis --- Fix confirmed to work.
[Bug target/82465] vec_sqrt() for vector double erroneously fails for z13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82465 --- Comment #2 from Konstantinos Margaritis --- Fix confirmed to work.
[Bug target/71648] C++ ICE on ppc64 with -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71648 Konstantinos Margaritis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Konstantinos Margaritis --- verified in both g++ 6 and 7.
[Bug c/63673] New: VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63673
Bug ID: 63673
Summary: VSX intrinsic vec_vsx_ld fails to compile with double,
maps to wrong instructions with float
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: markos at freevec dot org
Created attachment 33836
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33836&action=edit
failing to compile testcase for vec_vsx_ld using doubles
These are actually two issues, but I'm filing a single bug report as it looks
like they are related.
First the build error, I've created a small failing testcase (also attached):
--
#include
int main() {
double __attribute__((aligned(16))) d[4] = {0.0, 1.0, 2.0, 3.0 };
vector double v = vec_vsx_ld(8, d); // should load {1.0, 2.0}
}
--
This fails to compile under Debian gcc (4.9.1-19), with the following error:
$ gcc vec_vsx_ld_fail.c -c
vec_vsx_ld_fail.c: In function ‘main’:
vec_vsx_ld_fail.c:6:2: error: invalid parameter combination for AltiVec
intrinsic
vector double v = vec_vsx_ld(4, d); // should load {1.0, 2.0}
Casting d to (float *) makes it compile, but vec_vsx_ld intrinsic definitely
should handle double parameters, so I think this is a bug.
Now the second problem, a similar testcase for float (also attached):
--
#include
int main() {
float __attribute__((aligned(16))) f[8] = {0.0, 1.0, 2.0, 3.0, 4.0,
5.0, 6.0, 7.0 };
vector float v = vec_vsx_ld(4, f); // should load {1.0, 2.0, 3.0, 4.0}
}
--
This does compile, but the asm output uses the lxvd2x asm instruction, when
according the the ISA, lxvw4x should be used -at least according to my
understanding (page 359, Power ISA 2.07). Asm output also attached.
[Bug c/63673] VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63673 --- Comment #1 from Konstantinos Margaritis --- Created attachment 33837 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33837&action=edit testcase for vec_vsx_ld using floats
[Bug c/63673] VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63673 --- Comment #2 from Konstantinos Margaritis --- Created attachment 33838 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33838&action=edit asm output for testcase for vec_vsx_ld using floats
[Bug target/63673] VSX intrinsic vec_vsx_ld fails to compile with double, maps to wrong instructions with float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63673 --- Comment #6 from Konstantinos Margaritis --- Hi Bill, Thanks for the fix in the double * patch. It's listed as a valid option in: https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec_002fVSX-Built-in-Functions.html vector double vec_vsx_ld (int, const double *); Similarly for vec_vsx_st: void vec_vsx_st (vector double, int, double *); Also, thanks for the clarifications for the lxvw4x.
[Bug target/71648] New: C++ ICE on ppc64 with -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71648
Bug ID: 71648
Summary: C++ ICE on ppc64 with -m64
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: markos at freevec dot org
CC: wschmidt at gcc dot gnu.org
Target Milestone: ---
Host: powerpc-linux-gnu
Target: powerpc-linux-gnu
Build: powerpc-linux-gnu
$ g++-6 -m64 -O2 -c testcase2.cpp
testcase2.cpp: In function ‘void x33()’:
testcase2.cpp:55:1: error: insn does not satisfy its constraints:
}
^
(insn 40 39 41 2 (set (reg:DI 63 31 [orig:157 _6 ] [157])
(reg:DI 9 9)) testcase2.cpp:44 549 {*movdi_internal64}
(nil))
testcase2.cpp:55:1: internal compiler error: in extract_constrain_insn, at
recog.c:2190
0x107077ff _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:108
0x10707833 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.c:119
0x106d5be7 extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2190
0x106da11f copyprop_hardreg_forward_1
../../src/gcc/regcprop.c:774
0x106db59f copyprop_hardreg_forward_bb_without_debug_insn(basic_block_def*)
../../src/gcc/regcprop.c:1152
0x107493bf prepare_shrink_wrap
../../src/gcc/shrink-wrap.c:440
0x107493bf try_shrink_wrapping(edge_def**, bitmap_head*, rtx_insn*)
../../src/gcc/shrink-wrap.c:646
0x104f0c7b thread_prologue_and_epilogue_insns()
../../src/gcc/function.c:6066
0x104f1757 rest_of_handle_thread_prologue_and_epilogue
../../src/gcc/function.c:6588
0x104f1757 execute
../../src/gcc/function.c:6630
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/71648] C++ ICE on ppc64 with -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71648 --- Comment #1 from Konstantinos Margaritis --- Created attachment 38760 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38760&action=edit Reduced testcase for ICE on ppc64
[Bug target/71648] C++ ICE on ppc64 with -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71648 --- Comment #4 from Konstantinos Margaritis --- That's true, it compiled fine with -mcpu=power8.
