[Bug tree-optimization/116588] New: wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0

[Bug tree-optimization/116588] New: wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0

[zsojka at seznam dot cz]

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

            Bug ID: 116588
           Summary: wrong code with -O2 -fno-vect-cost-model
                    -fno-tree-dominator-opts -fno-tree-fre
                    --param=vrp-block-limit=0
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu
            Target: x86_64-pc-linux-gnu

Created attachment 59046
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59046&action=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -O2 -fno-vect-cost-model -fno-tree-dominator-opts
-fno-tree-fre --param=vrp-block-limit=0 testcase.c -DDEBUG
$ ./a.out 
00000000a07f00008710400000000000
$ ./a.out 
000000000f7f00008710400000000000
$ ./a.out 
b08159c7a27f00008710400000000000
$ ./a.out 
b0a1cc0ded7f00008710400000000000

$ valgrind -q --track-origins=yes ./a.out
==22934== Use of uninitialised value of size 8
==22934==    at 0x48FCC79: _itoa_word (in /lib64/libc.so.6)
==22934==    by 0x4906858: __printf_buffer (in /lib64/libc.so.6)
==22934==    by 0x4908880: __vfprintf_internal (in /lib64/libc.so.6)
==22934==    by 0x48FDC95: printf (in /lib64/libc.so.6)
==22934==    by 0x4010B2: main (testcase.c:19)
==22934==  Uninitialised value was created by a stack allocation
==22934==    at 0x4011C0: foo (testcase.c:6)
...

The output is different on each invocation.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r15-3427-20240903182055-gf0ab3de6ec0-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r15-3427-20240903182055-gf0ab3de6ec0-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240903 (experimental) (GCC)

[Bug tree-optimization/116588] wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
             Target|x86_64-pc-linux-gnu         |x86_64-pc-linux-gnu
                   |                            |aarch64-linux-gnu
   Last reconfirmed|                            |2024-09-03

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

[Bug tree-optimization/116588] wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |amacleod at redhat dot com,
                   |                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Can't be bisected due to the --param=vrp-block-limit=0 dependency, and that has
been only introduced in r15-1622, which already fails.
Seems like vrp2 issue.
Before vectorization, we have:
  <bb 3> [local count: 1073741824]:
  # _33 = PHI <2(12), _34(14)>
  _35 = _33 - _26;
  _36 = _35 - _27;
  _37 = VIEW_CONVERT_EXPR<unsigned long[3]>(e)[_35];
  _38 = _37 << _25;
  _39 = VIEW_CONVERT_EXPR<unsigned long[3]>(e)[_36];
  _40 = _39 >> _28;
  _41 = _38 | _40;
  bitint.2[_33] = _41;
  _34 = _33 + 18446744073709551615;
  _42 = (ssizetype) _32;
  _43 = (ssizetype) _34;
  if (_42 <= _43)
    goto <bb 14>; [0.05%]
  else
    goto <bb 6>; [99.95%]

  <bb 14> [local count: 536864]:
  goto <bb 3>; [100.00%]
loop which in this testcase should iterate exactly once because it is shift
left by 128 bits, so _35 and _36 are 0 and _33 is 2.
Then vectorizer vectorizes this loop (for some strange reason with a single
scalar
iteration first and then 2 iterations at a time).
Before vrp2 we have:
  <bb 2> [local count: 1073741824]:
  c.0_1 = c;
  _2 = (unsigned int) c.0_1;
  _3 = 128 - _2;
  # RANGE [irange] unsigned int [0, +INF] MASK 0x3f VALUE 0x0
  _25 = _3 & 63;
  # RANGE [irange] unsigned int [0, +INF] MASK 0x3ffffff VALUE 0x0
  _29 = _3 >> 6;
  # RANGE [irange] sizetype [0, +INF] MASK 0x3ffffff VALUE 0x0
  _26 = (sizetype) _29;
  _31 = _25 != 0;
  # RANGE [irange] sizetype [0, 1] MASK 0x1 VALUE 0x0
  _27 = (sizetype) _31;
  # RANGE [irange] sizetype [0, +INF] MASK 0x7ffffff VALUE 0x0
  _32 = _27 + _26;
  if (_32 <= 2)
    goto <bb 3>; [80.00%]
  else
    goto <bb 7>; [20.00%]

  <bb 3> [local count: 858993464]:
  _30 = -_25;
  # RANGE [irange] unsigned int [0, +INF] MASK 0x3f VALUE 0x0
  _28 = _30 & 63;
  _63 = -_32;
  _105 = 2 - _32;
  if (_105 <= 1)
    goto <bb 5>; [10.00%]
  else
    goto <bb 4>; [90.00%]
where _2 is 0 (but compiler doesn't know that), so _26 is 2 and _27 is 0 and
_32 is 2.
bb 4 contains the single scalar iteration + vectorized loop, bb 5 scalar loop.
And as _105 should be 2 - 2 = 0, _105 <= 1 should be true at runtime.
But somehow vrp2 determines that it is always false:
Global Exported: _105 = [irange] unsigned long [0, 2]
Folding statement: _105 = 2 - _32;
Not folded
Folding statement: if (_105 <= 1)

Visiting conditional with predicate: if (_105 <= 1)

With known ranges
        _105: [irange] unsigned long [0, 2]

Predicate evaluates to: DON'T KNOW
Simplified relational if (_105 <= 1)
 into if (_105 != 2)

Folded into: if (0 != 0)

The [0, 2] range for _105 is reasonable, at runtime it should be 0, simplifying
_105 <= 1 into _105 != 2 is reasonable too, but how it determined from that
that it is 0 != 0 is unclear.

[Bug tree-optimization/116588] wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0

[amacleod at redhat dot com]

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

--- Comment #3 from Andrew Macleod <amacleod at redhat dot com> ---
Its happening in tree-ssa-propagate.cc after the simplification:

      /* If this is a control statement the propagator left edges
         unexecuted on force the condition in a way consistent with
         that.  See PR66945 for cases where the propagator can end
         up with a different idea of a taken edge than folding
         (once undefined behavior is involved).  */
      if (gimple_code (stmt) == GIMPLE_COND)
        {
          if ((EDGE_SUCC (bb, 0)->flags & EDGE_EXECUTABLE)
              ^ (EDGE_SUCC (bb, 1)->flags & EDGE_EXECUTABLE))
            {
              if (((EDGE_SUCC (bb, 0)->flags & EDGE_TRUE_VALUE) != 0)
                  == ((EDGE_SUCC (bb, 0)->flags & EDGE_EXECUTABLE) != 0))
                gimple_cond_make_true (as_a <gcond *> (stmt));
              else
                gimple_cond_make_false (as_a <gcond *> (stmt));
              gimple_set_modified (stmt, true);

It appears that EDGE_EXECUTABLE is incorrect..
Thats as far as I have gotten so far.

[Bug tree-optimization/116588] wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Macleod <amacleod@gcc.gnu.org>:

https://gcc.gnu.org/g:506417dbc8b1cbc1133a5322572cf94b671aadf6

commit r15-3529-g506417dbc8b1cbc1133a5322572cf94b671aadf6
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Fri Sep 6 11:42:14 2024 -0400

    Before running fast VRP, make sure all edges have EXECUTABLE set.

            PR tree-optimization/116588
            gcc/
            * tree-vrp.cc (execute_fast_vrp): Start with all edges executable.
            gcc/testsuite/
            * gcc.dg/pr116588.c: New.

[Bug tree-optimization/116588] [14 Regression] wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|15.0                        |
            Summary|wrong code with -O2         |[14 Regression] wrong code
                   |-fno-vect-cost-model        |with -O2
                   |-fno-tree-dominator-opts    |-fno-vect-cost-model
                   |-fno-tree-fre               |-fno-tree-dominator-opts
                   |--param=vrp-block-limit=0   |-fno-tree-fre
                   |                            |--param=vrp-block-limit=0
   Target Milestone|---                         |14.3
      Known to work|                            |15.0

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
latent on the branch, the pass exists there as well.

[Bug tree-optimization/116588] [14 Regression] wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0

[zsojka at seznam dot cz]

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

--- Comment #6 from Zdenek Sojka <zsojka at seznam dot cz> ---
Is the -DDEBUG in dg-options correct? I think the testcase won't fail at
runtime when -DDEBUG is used.

[Bug tree-optimization/116588] [14 Regression] wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Zdenek Sojka from comment #6)
> Is the -DDEBUG in dg-options correct? I think the testcase won't fail at
> runtime when -DDEBUG is used.

It is not.  main body should be just
  if (foo (0))
    __builtin_abort ();
Even if it aborted, there is no need to keep debugging printouts in most of the
testcases (there are exceptions like the struct-layout-1.exp tests where one
can expect frequent debugging).

[Bug tree-optimization/116588] [14 Regression] wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from GCC 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:765875e2c18b8f4c346b754a19e287efaec531a5

commit r15-3542-g765875e2c18b8f4c346b754a19e287efaec531a5
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Sep 9 09:37:26 2024 +0200

    testsuite: Fix up pr116588.c test [PR116588]

    The test as committed without the tree-vrp.cc change only FAILs with
    FAIL: gcc.dg/pr116588.c scan-tree-dump-not vrp2 "0 != 0"
    The DEBUG code in there was just to make it easier to debug, but doesn't
    actually fail when the test is miscompiled.
    We don't need such debugging code in simple tests like that, but it is
    useful if they abort when miscompiled.

    With this patch without the tree-vrp.cc change I see
    FAIL: gcc.dg/pr116588.c execution test
    FAIL: gcc.dg/pr116588.c scan-tree-dump-not vrp2 "0 != 0"
    and with it it passes.

    2024-09-09  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/116588
            * gcc.dg/pr116588.c: Remove -DDEBUG from dg-options.
            (main): Remove debugging code and simplify.