[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #22 from Segher Boessenkool --- Fixed with commit f8c66617ab91826af1d950b00d853eaff622 Author: Segher Boessenkool Date: Tue Jan 19 23:43:56 2021 + rs6000: Fix rs6000_emit_le_vsx_store (PR98549) One of the advantages of LRA is that you can create new pseudos from it just fine. The code in rs6000_emit_le_vsx_store was not aware of this. This patch changes that, in the process fixing PR98549 (where it is shown that we do call rs6000_emit_le_vsx_store during LRA, which we used to assert can not happen). 2021-01-20 Segher Boessenkool * config/rs6000/rs6000.c (rs6000_emit_le_vsx_store): Change assert. Adjust comment. Simplify code.
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 Segher Boessenkool changed: What|Removed |Added Attachment #49996|0 |1 is obsolete|| --- Comment #21 from Segher Boessenkool --- Created attachment 50007 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50007=edit Better patch
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 --- Comment #20 from Martin Liška --- > Yeah, good point. > > But we do not have a complete program here at all, so this doesn't We do have: https://github.com/randombit/botan
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #19 from Martin Liška ---
(In reply to Segher Boessenkool from comment #12)
> for (long i; i != compress_n_blocks; ++i)
It's not the code I pasted:
> for (long i = 0; i < compress_n_blocks; ++i) {
>unsigned char S[32], S2[32];
I initialized 'i' to zero.
>
> "i" is uninitialized; accessing it is UB. So this is ice-on-invalid.
>
> I have no doubt there is an actual bug somewhere here. We just do not
> have valid code yet as testcase (preferably shorter than this, and C
> code, so that it is easier and can run on more systems).
There's a code snippet that should not contain UBSAN:
extern "C" void *memcpy(void *, const void *, unsigned long);
inline void copy_mem(unsigned char *out, unsigned char *in, long n) {
memcpy(out, in, n);
}
template void typecast_copy(unsigned char out[], T in, long N) {
memcpy(out, in, sizeof(T) * N);
}
template void typecast_copy(T out, unsigned char in[], long N) {
memcpy(out, in, sizeof(T) * N);
}
void encrypt_me(unsigned char *ptr);
unsigned char *xor_buf_in;
class BlockCipher {
public:
void encrypt(unsigned char *ptr);
} * compress_n___trans_tmp_2;
class GOST_34_11 {
void compress_n();
BlockCipher m_cipher;
};
long compress_n_blocks = 0;
void GOST_34_11::compress_n() {
for (long i = 0; i < compress_n_blocks; ++i) {
unsigned char S[32], S2[32];
char S_1;
m_cipher.encrypt(S);
S2[13] = S_1;
long x[4], y[4];
typecast_copy(x, S2, 4);
x[0] ^= y[0];
x[1] ^= y[1];
x[2] ^= x[3];
typecast_copy(S, x, 4);
S2[0] = S[4] ^ S[6] ^ 4 ^ S[30];
copy_mem(S, S + 2, 30);
S[30] = S2[0];
{
long x[4];
typecast_copy(x, S, 4);
typecast_copy(y, xor_buf_in, 4);
x[0] ^= y[0];
typecast_copy(S, x, 4);
}
S2[4] = S[6];
memcpy(compress_n___trans_tmp_2, S2, 32);
}
}
int main()
{
return 0;
}
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 --- Comment #18 from Segher Boessenkool --- Created attachment 49996 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49996=edit Patch
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 --- Comment #17 from Segher Boessenkool --- (In reply to jos...@codesourcery.com from comment #15) > Only if the undefined behavior is a property of the program, or of all > possible executions of the program, as opposed to a property of a > particular execution of the program. See C90 DR#109. "A conforming > implementation must not fail to translate a strictly conforming program > simply because *some* possible execution of that program would result in > undefined behavior.". Yeah, good point. But we do not have a complete program here at all, so this doesn't say much. If this was a complete program likely *every* execution of it would be UB; but of course it is also possible to make one where no execution has UB. Since the main routine in this snippet unconditionally has undefined behaviour, there is no way I can call this valid code. Anyway, the attached patch fixes the problem in this testcase. Not sure yet it is actually correct ;-)
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 --- Comment #16 from Segher Boessenkool --- Needs -mcpu=power8. Confirmed with that (and the given options).
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 --- Comment #15 from joseph at codesourcery dot com --- On Mon, 18 Jan 2021, segher at gcc dot gnu.org via Gcc-bugs wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 > > --- Comment #14 from Segher Boessenkool --- > (In reply to Jakub Jelinek from comment #13) > > For UB at runtime, we can warn, but shouldn't error because the code might > > never be invoked at runtime. > > As far as I can see at least the C standard disagrees with this: > NOTE Possible undefined behavior ranges from ignoring the situation > completely with unpredictable results, to behaving during translation > or program execution in a documented manner characteristic of the > environment (with or without the issuance of a diagnostic message), to > terminating a translation or execution (with the issuance of a > diagnostic message). > > So we are allowed to error. Only if the undefined behavior is a property of the program, or of all possible executions of the program, as opposed to a property of a particular execution of the program. See C90 DR#109. "A conforming implementation must not fail to translate a strictly conforming program simply because *some* possible execution of that program would result in undefined behavior.".
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 --- Comment #14 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #13) > For UB at runtime, we can warn, but shouldn't error because the code might > never be invoked at runtime. As far as I can see at least the C standard disagrees with this: NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). So we are allowed to error. It doesn't seem we will ever agree whether this is valid code. This is not a very useful discussion anyway: let's just make a small (valid code) testcase and be done with it :-)
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #13 from Jakub Jelinek ---
It is not ice-on-invalid, the invalid in there stands for code that should be
rejected by the compiler (emit error).
UB at runtime can be even int foo (int x, int y) { return x + y; }
but we surely don't want to treat ICE on it as less important because it might
cause UB at runtime. While the x + y is conditional UB, e.g.
int foo () { return __builtin_unreachable (); } is unconditional UB when that
function is called, but that still doesn't mean it will ever be called, the
same with whatever ICEs in this PR.
Other bug categories are accepts-invalid and rejects-valid, those talk about
the same invalid vs. valid categories, we should reject invalid and accept
valid code and lack thereof is a bug.
For UB at runtime, we can warn, but shouldn't error because the code might
never be invoked at runtime.
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 --- Comment #12 from Segher Boessenkool --- for (long i; i != compress_n_blocks; ++i) "i" is uninitialized; accessing it is UB. So this is ice-on-invalid. I have no doubt there is an actual bug somewhere here. We just do not have valid code yet as testcase (preferably shorter than this, and C code, so that it is easier and can run on more systems).
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #11 from Martin Liška ---
(In reply to Segher Boessenkool from comment #10)
> (And that new test case is full of obvious invalid code as well, fwiw.)
Wait here. Changing the code to:
long compress_n_blocks = 0;
void GOST_34_11::compress_n() {
for (long i = 0; i < compress_n_blocks; ++i) {
unsigned char S[32], S2[32];
the function GOST_34_11::compress_n now does not execute at all. Thus it should
not consider an invalid code. Can you please prove where the invalid code?
Moreover, the test-case comes from the original Botan benchmark:
https://github.com/randombit/botan
I'm able to run the benchmark with Sanitizers enabled, so I really don't think
it contains an invalid code.
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 --- Comment #10 from Segher Boessenkool --- (And that new test case is full of obvious invalid code as well, fwiw.)
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 --- Comment #9 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #6) > The warning often warns on dead code. > But even if the warning is right, that doesn't make it ice-on-invalid-code. > The code may have UB at runtime, but that UB doesn't need to be ever > triggered when running the program. That does not make it valid code. > ice-on-invalid-code stands for code that should be rejected (diagnosed with > errors, not warnings), but instead of giving the error we ICE on it instead. > That is not the case here. The documentation says ice-on-invalid-code ICE on code that is not valid which is true here. Anyway: unsigned long xor_buf_y[1]; ... typecast_copy(xor_buf_y, in, 4); which obviously is an out-of-bounds access. But there are even worse things: char *__trans_tmp_2; memcpy(__trans_tmp_2, S2, 32); (accessing an uninitialised variable). So no, there is no way I can consider this a P1.
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 Martin Liška changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #8 from Martin Liška --- And started with r11-3095-g47ddf4c7b1d4471cb9534f27844ab5e4279c2168 which enabed more vectorization opportunities.
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #7 from Martin Liška ---
There's a reproducer without a warning if you want:
$ cat pr98549-2.C
extern "C" void *memcpy(void *, const void *, unsigned long);
inline void copy_mem(unsigned char *out, unsigned char *in, long n) {
memcpy(out, in, n);
}
template void typecast_copy(unsigned char out[], T in, long N) {
memcpy(out, in, sizeof(T) * N);
}
template void typecast_copy(T out, unsigned char in[], long N) {
memcpy(out, in, sizeof(T) * N);
}
unsigned char *xor_buf_in;
class BlockCipher {
public:
void encrypt(unsigned char[]);
} * compress_n___trans_tmp_2;
class GOST_34_11 {
void compress_n();
BlockCipher m_cipher;
};
long compress_n_blocks;
void GOST_34_11::compress_n() {
for (long i; i != compress_n_blocks; ++i) {
unsigned char S[32], S2[32];
char S_1;
m_cipher.encrypt(S);
S2[13] = S_1;
long x[4], y[4];
typecast_copy(x, S2, 4);
x[0] ^= y[0];
x[1] ^= y[1];
x[2] ^= x[3];
typecast_copy(S, x, 4);
S2[0] = S[4] ^ S[6] ^ 4 ^ S[30];
copy_mem(S, S + 2, 30);
S[30] = S2[0];
{
long x[4];
typecast_copy(x, S, 4);
typecast_copy(y, xor_buf_in, 4);
x[0] ^= y[0];
typecast_copy(S, x, 4);
}
S2[4] = S[6];
memcpy(compress_n___trans_tmp_2, S2, 32);
}
}
$ ~/BIG/bin/ppc64le/dev/shm/buildbot/install/gcc/bin/ppc64le-linux-gnu-gcc -c
-O3 -fPIC -fstack-protector pr98549-2.C
during RTL pass: reload
pr98549-2.C: In member function ‘void GOST_34_11::compress_n()’:
pr98549-2.C:46:1: internal compiler error: in rs6000_emit_le_vsx_store, at
config/rs6000/rs6000.c:9938
46 | }
| ^
0x606cd2 rs6000_emit_le_vsx_store(rtx_def*, rtx_def*, machine_mode)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/config/rs6000/rs6000.c:9938
0x12579e7 gen_movv2di(rtx_def*, rtx_def*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/config/rs6000/vector.md:155
0x99a777 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/recog.h:407
0x99a777 emit_move_insn_1(rtx_def*, rtx_def*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/expr.c:3766
0x99abac emit_move_insn(rtx_def*, rtx_def*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/expr.c:3936
0xb16bd6 lra_emit_move(rtx_def*, rtx_def*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/lra.c:502
0xb29ed3 curr_insn_transform
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/lra-constraints.c:4547
0xb2aff5 lra_constraints(bool)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/lra-constraints.c:5138
0xb19182 lra(_IO_FILE*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/lra.c:2332
0xad65c9 do_reload
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/ira.c:5811
0xad65c9 execute
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/ira.c:5997
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 Jakub Jelinek changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code --- Comment #6 from Jakub Jelinek --- The warning often warns on dead code. But even if the warning is right, that doesn't make it ice-on-invalid-code. The code may have UB at runtime, but that UB doesn't need to be ever triggered when running the program. ice-on-invalid-code stands for code that should be rejected (diagnosed with errors, not warnings), but instead of giving the error we ICE on it instead. That is not the case here.
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 --- Comment #5 from Segher Boessenkool --- The "warninb" says warning: ‘void* memcpy(void*, const void*, long unsigned int)’ writing 32 bytes into a region of size 8 overflows the destination [-Wstringop-overflow=] It says it is wrong, so it is not a warning, it is an error. Perhaps that warning is just completely broken, it is lying to the user?
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 Jakub Jelinek changed: What|Removed |Added Priority|P4 |P1 CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Why do you think it is invalid? The fact that there is some warning emitted (which often has false positives) doesn't mean the code is invalid. P4 is for error-recovery bugs or bugs affecting non-primary languages.
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 Segher Boessenkool changed: What|Removed |Added Priority|P1 |P4 --- Comment #3 from Segher Boessenkool --- It is an ICE-on-invalid, so it cannot be P1.
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |11.0
Priority|P3 |P1
CC||segher at gcc dot gnu.org
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Status|ASSIGNED|NEW
--- Comment #2 from Martin Liška ---
Reduced test-case:
$ extern "C" void *memcpy(void *, const void *, unsigned long);
inline void copy_mem(unsigned char *out, unsigned char *in, long n) {
memcpy(out, in, n);
}
template void typecast_copy(unsigned char out[], T in, long N) {
memcpy(out, in, sizeof(T) * N);
}
template void typecast_copy(T out, unsigned char in[], long N) {
memcpy(out, in, sizeof(T) * N);
}
unsigned long xor_buf_y[1];
inline void xor_buf(unsigned char out[], unsigned char in[]) {
unsigned long x[4];
typecast_copy(x, out, 4);
typecast_copy(xor_buf_y, in, 4);
x[0] ^= xor_buf_y[0];
x[3] ^= 3;
typecast_copy(out, x, 4);
}
char compress_n_S_10, compress_n_S_8, compress_n_S_27, compress_n_S_25,
compress_n_S_0;
unsigned char compress_n___trans_tmp_1;
unsigned char *compress_n_input;
void compress_n() {
unsigned char S[32], S2[32];
S2[9] = compress_n_S_25;
S2[13] = S[7];
S2[14] = S[28];
S2[15] = S2[16] = S[0];
S2[17] = 9 ^ S[31];
S2[18] = S[8];
S2[19] = S[29];
S2[21] = compress_n_S_27;
S2[22] = compress_n_S_10;
S2[23] = S[1];
S2[24] = S[6];
S2[25] = S[23];
S2[6] = S[2] ^ compress_n_S_8;
S2[7] = S[9];
S2[8] = S[22];
S2[29] = S[11] ^ S[17];
S2[0] = S[12] ^ compress_n_S_0;
S2[1] = S[5] ^ S[3];
long x[4], y[4];
typecast_copy(x, S2, 4);
typecast_copy(y, compress_n_input, 4);
x[0] ^= y[0];
x[1] ^= y[1];
x[2] ^= x[3] ^= y[3];
typecast_copy(S, x, 4);
S2[1] = 5 ^ S[7];
copy_mem(S, S + 2, 30);
S[31] = S2[1];
xor_buf(S, _n___trans_tmp_1);
S2[2] = S2[3] = S2[4] = S[24];
S2[5] = S2[0] = compress_n_S_8 ^ S[4] ^ S[28];
char *__trans_tmp_2;
memcpy(__trans_tmp_2, S2, 32);
}
$ g++ pr98549.C -c -O3 -fPIC -fstack-protector
In function ‘void typecast_copy(T, unsigned char*, long int) [with T = long
unsigned int*]’,
inlined from ‘void xor_buf(unsigned char*, unsigned char*)’ at
pr98549.C:15:16,
inlined from ‘void compress_n()’ at pr98549.C:54:10:
pr98549.C:9:9: warning: ‘void* memcpy(void*, const void*, long unsigned int)’
writing 32 bytes into a region of size 8 overflows the destination
[-Wstringop-overflow=]
9 | memcpy(out, in, sizeof(T) * N);
| ~~^~~~
pr98549.C: In function ‘void compress_n()’:
pr98549.C:11:15: note: destination object ‘xor_buf_y’ of size 8
11 | unsigned long xor_buf_y[1];
| ^
during RTL pass: reload
pr98549.C:59:1: internal compiler error: in rs6000_emit_le_vsx_store, at
config/rs6000/rs6000.c:9938
59 | }
| ^
0x606caa rs6000_emit_le_vsx_store(rtx_def*, rtx_def*, machine_mode)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/config/rs6000/rs6000.c:9938
0x1252e57 gen_movv2di(rtx_def*, rtx_def*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/config/rs6000/vector.md:155
0x999ce7 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/recog.h:407
0x999ce7 emit_move_insn_1(rtx_def*, rtx_def*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/expr.c:3764
0x99a11c emit_move_insn(rtx_def*, rtx_def*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/expr.c:3934
0xb16086 lra_emit_move(rtx_def*, rtx_def*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/lra.c:502
0xb29343 curr_insn_transform
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/lra-constraints.c:4547
0xb2a465 lra_constraints(bool)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/lra-constraints.c:5138
0xb18632 lra(_IO_FILE*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/lra.c:2329
0xad5a89 do_reload
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/ira.c:5802
0xad5a89 execute
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/ira.c:5988
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-01-06 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Martin Liška --- Confirmed, reducing that right now..
