* [Bug tree-optimization/116588] wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0
2024-09-03 19:03 [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
@ 2024-09-03 19:25 ` pinskia at gcc dot gnu.org
2024-09-04 8:44 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-09-03 19:25 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug tree-optimization/116588] wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0
2024-09-03 19:03 [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
2024-09-03 19:25 ` [Bug tree-optimization/116588] " pinskia at gcc dot gnu.org
@ 2024-09-04 8:44 ` jakub at gcc dot gnu.org
2024-09-06 14:05 ` amacleod at redhat dot com
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-09-04 8:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug tree-optimization/116588] wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0
2024-09-03 19:03 [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
2024-09-03 19:25 ` [Bug tree-optimization/116588] " pinskia at gcc dot gnu.org
2024-09-04 8:44 ` jakub at gcc dot gnu.org
@ 2024-09-06 14:05 ` amacleod at redhat dot com
2024-09-07 17:58 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: amacleod at redhat dot com @ 2024-09-06 14:05 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug tree-optimization/116588] wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0
2024-09-03 19:03 [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
` (2 preceding siblings ...)
2024-09-06 14:05 ` amacleod at redhat dot com
@ 2024-09-07 17:58 ` cvs-commit at gcc dot gnu.org
2024-09-09 6:56 ` [Bug tree-optimization/116588] [14 Regression] " rguenth at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-09-07 17:58 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [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
2024-09-03 19:03 [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
` (3 preceding siblings ...)
2024-09-07 17:58 ` cvs-commit at gcc dot gnu.org
@ 2024-09-09 6:56 ` rguenth at gcc dot gnu.org
2024-09-09 7:13 ` zsojka at seznam dot cz
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-09-09 6:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [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
2024-09-03 19:03 [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
` (4 preceding siblings ...)
2024-09-09 6:56 ` [Bug tree-optimization/116588] [14 Regression] " rguenth at gcc dot gnu.org
@ 2024-09-09 7:13 ` zsojka at seznam dot cz
2024-09-09 7:22 ` jakub at gcc dot gnu.org
2024-09-09 7:43 ` cvs-commit at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: zsojka at seznam dot cz @ 2024-09-09 7:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [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
2024-09-03 19:03 [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
` (5 preceding siblings ...)
2024-09-09 7:13 ` zsojka at seznam dot cz
@ 2024-09-09 7:22 ` jakub at gcc dot gnu.org
2024-09-09 7:43 ` cvs-commit at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-09-09 7:22 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 9+ messages in thread* [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
2024-09-03 19:03 [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
` (6 preceding siblings ...)
2024-09-09 7:22 ` jakub at gcc dot gnu.org
@ 2024-09-09 7:43 ` cvs-commit at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-09-09 7:43 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread