[Bug tree-optimization/97764] New: wrong code at -O1 and above on x86_64-pc-linux-gnu

[Bug tree-optimization/97764] New: wrong code at -O1 and above on x86_64-pc-linux-gnu

[zhendong.su at inf dot ethz.ch]

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

            Bug ID: 97764
           Summary: wrong code at -O1 and above on x86_64-pc-linux-gnu
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[514] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201109 (experimental) [master revision
946b73c1132:a700e491347:dc7e8839c92c4bc3c3741cf27b0af81edb803fe7] (GCC) 
[515] % 
[515] % gcctk -O0 small.c; ./a.out
[516] % 
[516] % gcctk -O1 small.c
[517] % ./a.out
Aborted
[518] % 
[518] % cat small.c
struct S {
  int b : 3;
  int c : 28;
  int d : 1;
};

int main() {
  struct S e = {1, -1};
  if (e.d)
    __builtin_abort();
  return 0;
}

[Bug tree-optimization/97764] [10/11 Regression] wrong code at -O1 and above on x86_64-pc-linux-gnu since r10-6809

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2020-11-09
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
     Ever confirmed|0                           |1
            Summary|wrong code at -O1 and above |[10/11 Regression] wrong
                   |on x86_64-pc-linux-gnu      |code at -O1 and above on
                   |                            |x86_64-pc-linux-gnu since
                   |                            |r10-6809
                 CC|                            |jakub at gcc dot gnu.org
   Target Milestone|---                         |10.3

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with my r10-6809-g7f5617b00445dcc861a498a4cecc8aaa59e05b8c

[Bug tree-optimization/97764] [10/11 Regression] wrong code at -O1 and above on x86_64-pc-linux-gnu since r10-6809

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
                 CC|                            |rguenth at gcc dot gnu.org
           Keywords|                            |wrong-code

[Bug tree-optimization/97764] [10/11 Regression] wrong code at -O1 and above on x86_64-pc-linux-gnu since r10-6809

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 49525
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49525&action=edit
gcc11-pr97764.patch

Untested fix.

[Bug tree-optimization/97764] [10/11 Regression] wrong code at -O1 and above on x86_64-pc-linux-gnu since r10-6809

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:c69325a5db450dbac198f76f1162734af05a1061

commit r11-4867-gc69325a5db450dbac198f76f1162734af05a1061
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Nov 10 11:17:46 2020 +0100

    sccvn: Fix up push_partial_def little-endian bitfield handling [PR97764]

    This patch fixes a thinko in the left-endian push_partial_def path.
    As the testcase shows, we have 3 bitfields in the struct,
    bitoff  bitsize
    0       3
    3       28
    31      1
    the corresponding read is the byte at offset 3 (i.e. 24 bits)
    and push_partial_def first handles the full store ({}) to all bits
    and then is processing the store to the middle bitfield with value of -1.
    Here are the interesting spots:
      pd.offset -= offseti;
    this adjusts the pd to { -21, 28 }, the (for little-endian lowest) 21
    bits aren't interesting to us, we only care about the upper 7.
              len = native_encode_expr (pd.rhs, this_buffer, bufsize,
                                        MAX (0, -pd.offset) / BITS_PER_UNIT);
    native_encode_expr has the offset parameter in bytes and we tell it
    that we aren't interested in the first (lowest) two bytes of the number.
    It encodes 0xff, 0xff with len == 2 then.
          HOST_WIDE_INT size = pd.size;
          if (pd.offset < 0)
            size -= ROUND_DOWN (-pd.offset, BITS_PER_UNIT);
    we get 28 - 16, i.e. 12 - the 16 is subtracting those 2 bytes that we
    omitted in native_encode_expr.
              size = MIN (size, (HOST_WIDE_INT) needed_len * BITS_PER_UNIT);
    needed_len is how many bytes the read at most needs, and that is 1,
    so we get size 8 and copy all 8 bits (i.e. a single byte plus nothing)
    from the native_encode_expr filled this_buffer; this incorrectly sets
    the byte to 0xff when we want 0x7f.  The above line is correct for the
    pd.offset >= 0 case when we don't skip anything, but for the pd.offset < 0
    case we need to subtract also the remainder of the bits we aren't
interested
    in (the code shifts the bytes by that number of bits).
    If it weren't for the big-endian path, we could as well do
          if (pd.offset < 0)
            size += pd.offset;
    but the big-endian path needs it differently.
    With the following patch, amnt is 3 and we subtract from 12 the (8 - 3)
    bits and thus get the 7 which is the value we want.

    2020-11-10  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/97764
            * tree-ssa-sccvn.c (vn_walk_cb_data::push_partial_def): For
            little-endian stores with negative pd.offset, subtract
            BITS_PER_UNIT - amnt from size if amnt is non-zero.

            * gcc.c-torture/execute/pr97764.c: New test.

[Bug tree-optimization/97764] [10/11 Regression] wrong code at -O1 and above on x86_64-pc-linux-gnu since r10-6809

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:4b47f86c40a071fbcad5bce5001b1b689748a2e8

commit r10-8998-g4b47f86c40a071fbcad5bce5001b1b689748a2e8
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Nov 10 11:17:46 2020 +0100

    sccvn: Fix up push_partial_def little-endian bitfield handling [PR97764]

    This patch fixes a thinko in the left-endian push_partial_def path.
    As the testcase shows, we have 3 bitfields in the struct,
    bitoff  bitsize
    0       3
    3       28
    31      1
    the corresponding read is the byte at offset 3 (i.e. 24 bits)
    and push_partial_def first handles the full store ({}) to all bits
    and then is processing the store to the middle bitfield with value of -1.
    Here are the interesting spots:
      pd.offset -= offseti;
    this adjusts the pd to { -21, 28 }, the (for little-endian lowest) 21
    bits aren't interesting to us, we only care about the upper 7.
              len = native_encode_expr (pd.rhs, this_buffer, bufsize,
                                        MAX (0, -pd.offset) / BITS_PER_UNIT);
    native_encode_expr has the offset parameter in bytes and we tell it
    that we aren't interested in the first (lowest) two bytes of the number.
    It encodes 0xff, 0xff with len == 2 then.
          HOST_WIDE_INT size = pd.size;
          if (pd.offset < 0)
            size -= ROUND_DOWN (-pd.offset, BITS_PER_UNIT);
    we get 28 - 16, i.e. 12 - the 16 is subtracting those 2 bytes that we
    omitted in native_encode_expr.
              size = MIN (size, (HOST_WIDE_INT) needed_len * BITS_PER_UNIT);
    needed_len is how many bytes the read at most needs, and that is 1,
    so we get size 8 and copy all 8 bits (i.e. a single byte plus nothing)
    from the native_encode_expr filled this_buffer; this incorrectly sets
    the byte to 0xff when we want 0x7f.  The above line is correct for the
    pd.offset >= 0 case when we don't skip anything, but for the pd.offset < 0
    case we need to subtract also the remainder of the bits we aren't
interested
    in (the code shifts the bytes by that number of bits).
    If it weren't for the big-endian path, we could as well do
          if (pd.offset < 0)
            size += pd.offset;
    but the big-endian path needs it differently.
    With the following patch, amnt is 3 and we subtract from 12 the (8 - 3)
    bits and thus get the 7 which is the value we want.

    2020-11-10  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/97764
            * tree-ssa-sccvn.c (vn_walk_cb_data::push_partial_def): For
            little-endian stores with negative pd.offset, subtract
            BITS_PER_UNIT - amnt from size if amnt is non-zero.

            * gcc.c-torture/execute/pr97764.c: New test.

[Bug tree-optimization/97764] [10/11 Regression] wrong code at -O1 and above on x86_64-pc-linux-gnu since r10-6809

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 97775 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/97764] [10/11 Regression] wrong code at -O1 and above on x86_64-pc-linux-gnu since r10-6809

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

[Bug tree-optimization/97764] [10/11 Regression] wrong code at -O1 and above on x86_64-pc-linux-gnu since r10-6809

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |haoxintu at gmail dot com

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
*** Bug 98074 has been marked as a duplicate of this bug. ***