[Bug c/110702] New: Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

[Bug c/110702] New: Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

[shaohua.li at inf dot ethz.ch]

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

            Bug ID: 110702
           Summary: Wrong code at -O1 on x86_64-linux-gnu (regression
                    since GCC-12.2)
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: shaohua.li at inf dot ethz.ch
  Target Milestone: ---

This looks like a regression since GCC-12.2.

Compiler explorer: https://godbolt.org/z/655af97j7

$ cat a.c
int printf(const char *, ...);
int a, b, c, d;
long e[9][7][4];
void f() {
  for (; a >= 0; a--) {
    b = 0;
    for (; b <= 3; b++) {
      c = 0;
      for (; c <= 3; c++) {
        int *g = &d;
        *g = e[0][0][b] | e[a][b][a];
      }
    }
  }
}
int main() {
  f();
  printf("%d\n", a);
}
$
$ gcc-tk -O0 a.c && ./a.out
-1
$ gcc-tk -O1 a.c && ./a.out
0
$
$ gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-322d17ae51ea0137167424e0018d7fa355948f9f/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-322d17ae51ea0137167424e0018d7fa355948f9f
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230711 (experimental) (GCC) 
$

[Bug c/110702] [12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Wrong code at -O1 on        |[12/13/14 Regression] Wrong
                   |x86_64-linux-gnu            |code at -O1 on
                   |(regression since GCC-12.2) |x86_64-linux-gnu
                   |                            |(regression since GCC-12.2)
           Keywords|                            |wrong-code
      Known to work|                            |11.4.0, 12.1.0
      Known to fail|                            |12.2.0, 12.3.0, 13.1.0
   Target Milestone|---                         |12.4

[Bug middle-end/110702] [12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|c                           |middle-end
           Keywords|                            |needs-bisection
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-07-17

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

[Bug middle-end/110702] [12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

[mikpelinux at gmail dot com]

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

Mikael Pettersson <mikpelinux at gmail dot com> changed:

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

--- Comment #2 from Mikael Pettersson <mikpelinux at gmail dot com> ---
Masked at -Os/O2/O3. The regression at -O1 started with

374cee99d01fceb89d0929da8b38051e6c9768f0 is the first new commit
commit 374cee99d01fceb89d0929da8b38051e6c9768f0
Author: Richard Biener <rguenther@suse.de>
Date:   Tue May 17 09:45:02 2022 +0200

    tree-optimization/105618 - restore load sinking

[Bug middle-end/110702] [12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

[shaohua.li at inf dot ethz.ch]

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

--- Comment #3 from Shaohua Li <shaohua.li at inf dot ethz.ch> ---
Bisect to r13-550-gebce0e9bd8d

[Bug tree-optimization/110702] [12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-bisection             |
             Status|NEW                         |ASSIGNED
                 CC|                            |hubicka at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
          Component|middle-end                  |tree-optimization

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think the bisected rev just exposes an existing issue.  Namely IVOPTs
generates

  _1 = MEM[(long int *)_52];
  _3 = MEM[(long int *)0B + ivtmp.36_9 + ivtmp.28_44 * 4];
  _4 = (int) _3;
  _2 = (int) _1;
  _5 = _2 | _4;

with -fno-ivopts it works fine and we sink

  _1 = e[0][0][b.7_29];
  _3 = e[a.9_30][b.7_29][a.9_30];

the issue is without IVOPTs the late pure-const pass correctly does nothing
but with IVOPTs and the above MEMs we get it to produce pure because:

  scanning: _1 = MEM[(long int *)_52];
    Indirect ref read is not const
  NULL memory access; terminating BB

which is because infer_nonnull_range_by_dereference eventually does

static bool
check_loadstore (gimple *, tree op, tree, void *data)
{
  if (TREE_CODE (op) == MEM_REF || TREE_CODE (op) == TARGET_MEM_REF)
    {                           
      /* Some address spaces may legitimately dereference zero.  */
      addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (op));
      if (targetm.addr_space.zero_address_valid (as))
        return false;

      return operand_equal_p (TREE_OPERAND (op, 0), (tree)data, 0);

[Bug tree-optimization/110702] [12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue for this seems to be that create_mem_ref gets

  type = unsigned long
  offset = 0
  elements = {
    [0] = &e *
0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffd, 
    [1] = (sizetype) a.9_30 * 232, 
    [2] = ivtmp.28_44 * 4
  }

via get_computation_aff and addr_to_parts fills out no suitable symbol/base

$113 = {symbol = <tree 0x0>, base = <plus_expr 0x7ffff73b30f0>, 
  index = <nop_expr 0x7ffff73af9a0>, step = <integer_cst 0x7ffff71e4000>, 
  offset = <tree 0x0>}

so we hit

  else /* !POINTER_TYPE_P */
    {
      base = build_int_cst (build_pointer_type (type), 0);
      index2 = addr->base;

in create_mem_ref_raw.

But get_address_cost sees the address split as aff_inv

  type = unsigned long
  offset = 0
  elements = {
    [0] = &e *
0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffd, 
    [1] = (sizetype) a.9_30 * 232
  }

and aff_var

  type = unsigned long
  offset = 0
  elements = {
    [0] = ivtmp.28 * 4
  }

and eventually ends up with parts

$108 = {symbol = <tree 0x0>, base = <integer_cst 0x7ffff71e4150>, 
  index = <integer_cst 0x7ffff71e4150>, step = <integer_cst 0x7ffff73b05e8>, 
  offset = <tree 0x0>}

so the address we cost is different from the address we eventually generate
(the address we cost doesn't contain all parts - we ignore aff_var).

[Bug tree-optimization/110702] [12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:13dfb01e5c30c3bd09333ac79d6ff96a617fea67

commit r14-2951-g13dfb01e5c30c3bd09333ac79d6ff96a617fea67
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Aug 3 13:11:12 2023 +0200

    tree-optimization/110702 - avoid zero-based memory references in IVOPTs

    Sometimes IVOPTs chooses a weird induction variable which downstream
    leads to issues.  Most of the times we can fend those off during costing
    by rejecting the candidate but it looks like the address description
    costing synthesizes is different from what we end up generating so
    the following fixes things up at code generation time.  Specifically
    we avoid the create_mem_ref_raw fallback which uses a literal zero
    address base with the actual base in index2.  For the case in question
    we have the address

      type = unsigned long
      offset = 0
      elements = {
        [0] = &e * -3,
        [1] = (sizetype) a.9_30 * 232,
        [2] = ivtmp.28_44 * 4
      }

    from which we code generate the problematical

      _3 = MEM[(long int *)0B + ivtmp.36_9 + ivtmp.28_44 * 4];

    which references the object at address zero.  The patch below
    recognizes the fallback after the fact and transforms the
    TARGET_MEM_REF memory reference into a LEA for which this form
    isn't problematic:

      _24 = &MEM[(long int *)0B + ivtmp.36_34 + ivtmp.28_44 * 4];
      _3 = *_24;

    hereby avoiding the correctness issue.  We'd later conclude the
    program terminates at the null pointer dereference and make the
    function pure, miscompling the main function of the testcase.

            PR tree-optimization/110702
            * tree-ssa-loop-ivopts.cc (rewrite_use_address): When
            we created a NULL pointer based access rewrite that to
            a LEA.

            * gcc.dg/torture/pr110702.c: New testcase.

[Bug tree-optimization/110702] [12/13 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[12/13/14 Regression] Wrong |[12/13 Regression] Wrong
                   |code at -O1 on              |code at -O1 on
                   |x86_64-linux-gnu            |x86_64-linux-gnu
                   |(regression since GCC-12.2) |(regression since GCC-12.2)
           Priority|P3                          |P2
      Known to work|                            |14.0

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.

[Bug tree-optimization/110702] [12/13 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:5ca9aea695396266b7eb7d2a065e6f2e9546047e

commit r13-7752-g5ca9aea695396266b7eb7d2a065e6f2e9546047e
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Aug 3 13:11:12 2023 +0200

    tree-optimization/110702 - avoid zero-based memory references in IVOPTs

    Sometimes IVOPTs chooses a weird induction variable which downstream
    leads to issues.  Most of the times we can fend those off during costing
    by rejecting the candidate but it looks like the address description
    costing synthesizes is different from what we end up generating so
    the following fixes things up at code generation time.  Specifically
    we avoid the create_mem_ref_raw fallback which uses a literal zero
    address base with the actual base in index2.  For the case in question
    we have the address

      type = unsigned long
      offset = 0
      elements = {
        [0] = &e * -3,
        [1] = (sizetype) a.9_30 * 232,
        [2] = ivtmp.28_44 * 4
      }

    from which we code generate the problematical

      _3 = MEM[(long int *)0B + ivtmp.36_9 + ivtmp.28_44 * 4];

    which references the object at address zero.  The patch below
    recognizes the fallback after the fact and transforms the
    TARGET_MEM_REF memory reference into a LEA for which this form
    isn't problematic:

      _24 = &MEM[(long int *)0B + ivtmp.36_34 + ivtmp.28_44 * 4];
      _3 = *_24;

    hereby avoiding the correctness issue.  We'd later conclude the
    program terminates at the null pointer dereference and make the
    function pure, miscompling the main function of the testcase.

            PR tree-optimization/110702
            * tree-ssa-loop-ivopts.cc (rewrite_use_address): When
            we created a NULL pointer based access rewrite that to
            a LEA.

            * gcc.dg/torture/pr110702.c: New testcase.

    (cherry picked from commit 13dfb01e5c30c3bd09333ac79d6ff96a617fea67)

[Bug tree-optimization/110702] [12 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aegges at web dot de

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

[Bug tree-optimization/110702] [12 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:56d6989705189970b842ba1bdb1759d432b0d9e7

commit r12-10009-g56d6989705189970b842ba1bdb1759d432b0d9e7
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Aug 3 13:11:12 2023 +0200

    tree-optimization/110702 - avoid zero-based memory references in IVOPTs

    Sometimes IVOPTs chooses a weird induction variable which downstream
    leads to issues.  Most of the times we can fend those off during costing
    by rejecting the candidate but it looks like the address description
    costing synthesizes is different from what we end up generating so
    the following fixes things up at code generation time.  Specifically
    we avoid the create_mem_ref_raw fallback which uses a literal zero
    address base with the actual base in index2.  For the case in question
    we have the address

      type = unsigned long
      offset = 0
      elements = {
        [0] = &e * -3,
        [1] = (sizetype) a.9_30 * 232,
        [2] = ivtmp.28_44 * 4
      }

    from which we code generate the problematical

      _3 = MEM[(long int *)0B + ivtmp.36_9 + ivtmp.28_44 * 4];

    which references the object at address zero.  The patch below
    recognizes the fallback after the fact and transforms the
    TARGET_MEM_REF memory reference into a LEA for which this form
    isn't problematic:

      _24 = &MEM[(long int *)0B + ivtmp.36_34 + ivtmp.28_44 * 4];
      _3 = *_24;

    hereby avoiding the correctness issue.  We'd later conclude the
    program terminates at the null pointer dereference and make the
    function pure, miscompling the main function of the testcase.

            PR tree-optimization/110702
            * tree-ssa-loop-ivopts.cc (rewrite_use_address): When
            we created a NULL pointer based access rewrite that to
            a LEA.

            * gcc.dg/torture/pr110702.c: New testcase.

    (cherry picked from commit 13dfb01e5c30c3bd09333ac79d6ff96a617fea67)

[Bug tree-optimization/110702] [12 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |12.3.1
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.