[Bug target/98549] New: [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[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]

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

            Bug ID: 98549
           Summary: [11 Regression] ICE in rs6000_emit_le_vsx_store, at
                    config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at debian dot org
  Target Milestone: ---

seen with trunk 20210102 on powerpc64le-linux-gnu, not yet reduced.

https://launchpadlibrarian.net/515474879/buildlog_ubuntu-hirsute-ppc64el.botan_2.17.2+dfsg-2_BUILDING.txt.gz

search for "BEGIN GCC DUMP" for compiler options and configure flags.

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[marxin at gcc dot gnu.org]

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..

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[marxin at gcc dot gnu.org]

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.

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[segher at gcc dot gnu.org]

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.

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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.

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[segher at gcc dot gnu.org]

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?

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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.

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[marxin at gcc dot gnu.org]

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.

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[marxin at gcc dot gnu.org]

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.

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[segher at gcc dot gnu.org]

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.

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[segher at gcc dot gnu.org]

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.)

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[marxin at gcc dot gnu.org]

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.

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[segher at gcc dot gnu.org]

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).

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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.

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[segher at gcc dot gnu.org]

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 :-)

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[joseph at codesourcery dot com]

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.".

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[segher at gcc dot gnu.org]

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).

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[segher at gcc dot gnu.org]

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 ;-)

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[segher at gcc dot gnu.org]

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

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[marxin at gcc dot gnu.org]

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;
}

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[marxin at gcc dot gnu.org]

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

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[segher at gcc dot gnu.org]

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

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[segher at gcc dot gnu.org]

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.