* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
@ 2021-01-06 5:33 ` marxin at gcc dot gnu.org
2021-01-06 6:05 ` marxin at gcc dot gnu.org
` (20 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-01-06 5:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Martin Liška <marxin at gcc dot gnu.org> 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 <marxin at gcc dot gnu.org> ---
Confirmed, reducing that right now..
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
2021-01-06 5:33 ` [Bug target/98549] " marxin at gcc dot gnu.org
@ 2021-01-06 6:05 ` marxin at gcc dot gnu.org
2021-01-14 17:26 ` segher at gcc dot gnu.org
` (19 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-01-06 6:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Martin Liška <marxin at gcc dot gnu.org> 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 <marxin at gcc dot gnu.org> ---
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 <typename T> void typecast_copy(unsigned char out[], T in, long N) {
memcpy(out, in, sizeof(T) * N);
}
template <typename T> 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, &compress_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*>(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 <https://gcc.gnu.org/bugs/> for instructions.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
2021-01-06 5:33 ` [Bug target/98549] " marxin at gcc dot gnu.org
2021-01-06 6:05 ` marxin at gcc dot gnu.org
@ 2021-01-14 17:26 ` segher at gcc dot gnu.org
2021-01-14 19:25 ` jakub at gcc dot gnu.org
` (18 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: segher at gcc dot gnu.org @ 2021-01-14 17:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P1 |P4
--- Comment #3 from Segher Boessenkool <segher at gcc dot gnu.org> ---
It is an ICE-on-invalid, so it cannot be P1.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (2 preceding siblings ...)
2021-01-14 17:26 ` segher at gcc dot gnu.org
@ 2021-01-14 19:25 ` jakub at gcc dot gnu.org
2021-01-15 1:58 ` segher at gcc dot gnu.org
` (17 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-14 19:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P4 |P1
CC| |jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (3 preceding siblings ...)
2021-01-14 19:25 ` jakub at gcc dot gnu.org
@ 2021-01-15 1:58 ` segher at gcc dot gnu.org
2021-01-15 7:37 ` jakub at gcc dot gnu.org
` (16 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: segher at gcc dot gnu.org @ 2021-01-15 1:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> ---
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?
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (4 preceding siblings ...)
2021-01-15 1:58 ` segher at gcc dot gnu.org
@ 2021-01-15 7:37 ` jakub at gcc dot gnu.org
2021-01-15 9:35 ` marxin at gcc dot gnu.org
` (15 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-15 7:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|ice-on-invalid-code |ice-on-valid-code
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (5 preceding siblings ...)
2021-01-15 7:37 ` jakub at gcc dot gnu.org
@ 2021-01-15 9:35 ` marxin at gcc dot gnu.org
2021-01-15 10:41 ` marxin at gcc dot gnu.org
` (14 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-01-15 9:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> ---
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 <typename T> void typecast_copy(unsigned char out[], T in, long N) {
memcpy(out, in, sizeof(T) * N);
}
template <typename T> 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*>(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 <https://gcc.gnu.org/bugs/> for instructions.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (6 preceding siblings ...)
2021-01-15 9:35 ` marxin at gcc dot gnu.org
@ 2021-01-15 10:41 ` marxin at gcc dot gnu.org
2021-01-16 16:25 ` segher at gcc dot gnu.org
` (13 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-01-15 10:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
And started with r11-3095-g47ddf4c7b1d4471cb9534f27844ab5e4279c2168 which
enabed more vectorization opportunities.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (7 preceding siblings ...)
2021-01-15 10:41 ` marxin at gcc dot gnu.org
@ 2021-01-16 16:25 ` segher at gcc dot gnu.org
2021-01-16 16:29 ` segher at gcc dot gnu.org
` (12 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: segher at gcc dot gnu.org @ 2021-01-16 16:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #9 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(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.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (8 preceding siblings ...)
2021-01-16 16:25 ` segher at gcc dot gnu.org
@ 2021-01-16 16:29 ` segher at gcc dot gnu.org
2021-01-18 8:29 ` marxin at gcc dot gnu.org
` (11 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: segher at gcc dot gnu.org @ 2021-01-16 16:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #10 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(And that new test case is full of obvious invalid code as well, fwiw.)
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (9 preceding siblings ...)
2021-01-16 16:29 ` segher at gcc dot gnu.org
@ 2021-01-18 8:29 ` marxin at gcc dot gnu.org
2021-01-18 20:27 ` segher at gcc dot gnu.org
` (10 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-01-18 8:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #11 from Martin Liška <marxin at gcc dot gnu.org> ---
(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.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (10 preceding siblings ...)
2021-01-18 8:29 ` marxin at gcc dot gnu.org
@ 2021-01-18 20:27 ` segher at gcc dot gnu.org
2021-01-18 23:04 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: segher at gcc dot gnu.org @ 2021-01-18 20:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #12 from Segher Boessenkool <segher at gcc dot gnu.org> ---
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).
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (11 preceding siblings ...)
2021-01-18 20:27 ` segher at gcc dot gnu.org
@ 2021-01-18 23:04 ` jakub at gcc dot gnu.org
2021-01-18 23:19 ` segher at gcc dot gnu.org
` (8 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-18 23:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (12 preceding siblings ...)
2021-01-18 23:04 ` jakub at gcc dot gnu.org
@ 2021-01-18 23:19 ` segher at gcc dot gnu.org
2021-01-18 23:38 ` joseph at codesourcery dot com
` (7 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: segher at gcc dot gnu.org @ 2021-01-18 23:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #14 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(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 :-)
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (13 preceding siblings ...)
2021-01-18 23:19 ` segher at gcc dot gnu.org
@ 2021-01-18 23:38 ` joseph at codesourcery dot com
2021-01-19 1:07 ` segher at gcc dot gnu.org
` (6 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: joseph at codesourcery dot com @ 2021-01-18 23:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #15 from joseph at codesourcery dot com <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 <segher at gcc dot gnu.org> ---
> (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.".
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (14 preceding siblings ...)
2021-01-18 23:38 ` joseph at codesourcery dot com
@ 2021-01-19 1:07 ` segher at gcc dot gnu.org
2021-01-19 1:54 ` segher at gcc dot gnu.org
` (5 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: segher at gcc dot gnu.org @ 2021-01-19 1:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #16 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Needs -mcpu=power8. Confirmed with that (and the given options).
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (15 preceding siblings ...)
2021-01-19 1:07 ` segher at gcc dot gnu.org
@ 2021-01-19 1:54 ` segher at gcc dot gnu.org
2021-01-19 1:55 ` segher at gcc dot gnu.org
` (4 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: segher at gcc dot gnu.org @ 2021-01-19 1:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #17 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to joseph@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 ;-)
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (16 preceding siblings ...)
2021-01-19 1:54 ` segher at gcc dot gnu.org
@ 2021-01-19 1:55 ` segher at gcc dot gnu.org
2021-01-19 8:57 ` marxin at gcc dot gnu.org
` (3 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: segher at gcc dot gnu.org @ 2021-01-19 1:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #18 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Created attachment 49996
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49996&action=edit
Patch
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (17 preceding siblings ...)
2021-01-19 1:55 ` segher at gcc dot gnu.org
@ 2021-01-19 8:57 ` marxin at gcc dot gnu.org
2021-01-19 8:59 ` marxin at gcc dot gnu.org
` (2 subsequent siblings)
21 siblings, 0 replies; 23+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-01-19 8:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #19 from Martin Liška <marxin at gcc dot gnu.org> ---
(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 <typename T> void typecast_copy(unsigned char out[], T in, long N) {
memcpy(out, in, sizeof(T) * N);
}
template <typename T> 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;
}
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (18 preceding siblings ...)
2021-01-19 8:57 ` marxin at gcc dot gnu.org
@ 2021-01-19 8:59 ` marxin at gcc dot gnu.org
2021-01-19 23:28 ` segher at gcc dot gnu.org
2021-01-20 19:02 ` segher at gcc dot gnu.org
21 siblings, 0 replies; 23+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-01-19 8:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #20 from Martin Liška <marxin at gcc dot gnu.org> ---
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (19 preceding siblings ...)
2021-01-19 8:59 ` marxin at gcc dot gnu.org
@ 2021-01-19 23:28 ` segher at gcc dot gnu.org
2021-01-20 19:02 ` segher at gcc dot gnu.org
21 siblings, 0 replies; 23+ messages in thread
From: segher at gcc dot gnu.org @ 2021-01-19 23:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #49996|0 |1
is obsolete| |
--- Comment #21 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Created attachment 50007
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50007&action=edit
Better patch
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
2021-01-05 21:13 [Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu doko at debian dot org
` (20 preceding siblings ...)
2021-01-19 23:28 ` segher at gcc dot gnu.org
@ 2021-01-20 19:02 ` segher at gcc dot gnu.org
21 siblings, 0 replies; 23+ messages in thread
From: segher at gcc dot gnu.org @ 2021-01-20 19:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #22 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Fixed with
commit f8c677776617ab91826af1d950b00d853eaff622
Author: Segher Boessenkool <segher@kernel.crashing.org>
Date: Tue Jan 19 23:43:56 2021 +0000
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 <segher@kernel.crashing.org>
* config/rs6000/rs6000.c (rs6000_emit_le_vsx_store): Change assert.
Adjust comment. Simplify code.
^ permalink raw reply [flat|nested] 23+ messages in thread