* [Bug target/104307] [11/12 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2
2022-01-31 14:37 [Bug target/104307] New: [11/12 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2 asolokha at gmx dot com
@ 2022-01-31 14:38 ` asolokha at gmx dot com
2022-01-31 16:34 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: asolokha at gmx dot com @ 2022-01-31 14:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104307
--- Comment #1 from Arseny Solokha <asolokha at gmx dot com> ---
(In reply to Arseny Solokha from comment #0)
> w/ -Os -funroll-loops:
It's an obvious copy-paste error, of course. It fails the check w/ -mavx512f
-O2.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug target/104307] [11/12 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2
2022-01-31 14:37 [Bug target/104307] New: [11/12 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2 asolokha at gmx dot com
2022-01-31 14:38 ` [Bug target/104307] " asolokha at gmx dot com
@ 2022-01-31 16:34 ` jakub at gcc dot gnu.org
2022-01-31 16:43 ` [Bug middle-end/104307] " jakub at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-01-31 16:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104307
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2022-01-31
Priority|P3 |P2
Target Milestone|--- |11.3
CC| |jakub at gcc dot gnu.org
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/104307] [11/12 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2
2022-01-31 14:37 [Bug target/104307] New: [11/12 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2 asolokha at gmx dot com
2022-01-31 14:38 ` [Bug target/104307] " asolokha at gmx dot com
2022-01-31 16:34 ` jakub at gcc dot gnu.org
@ 2022-01-31 16:43 ` jakub at gcc dot gnu.org
2022-01-31 16:53 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-01-31 16:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104307
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r11-2577-g229752afe3156a3990dacaedb94c76846cebf132 but I think the
real bug is caused by r11-2362-g55c9695cbe91c406805ac0cd342949f32f13b779
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug middle-end/104307] [11/12 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2
2022-01-31 14:37 [Bug target/104307] New: [11/12 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2 asolokha at gmx dot com
` (2 preceding siblings ...)
2022-01-31 16:43 ` [Bug middle-end/104307] " jakub at gcc dot gnu.org
@ 2022-01-31 16:53 ` jakub at gcc dot gnu.org
2022-02-01 15:06 ` [Bug tree-optimization/104307] " cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-01-31 16:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104307
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52320
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52320&action=edit
gcc12-pr104307.patch
Untested fix.
Just the first part of the hunk is needed for this bug, I'm actually not 100%
sure about the rhs2/rhs3 case, but it feels it isn't right (it would e.g. try
to expand_vector_condition the same stmt multiple times).
I must say I don't understand the pushing of all uses into a vector, wouldn't
it make more sense to push there just the VEC_COND_EXPRs with such lhs?
Then we e.g. wouldn't need to do any expand_vector_condition calls if we have
1000 VEC_COND_EXPR uses and then a different use.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/104307] [11/12 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2
2022-01-31 14:37 [Bug target/104307] New: [11/12 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2 asolokha at gmx dot com
` (3 preceding siblings ...)
2022-01-31 16:53 ` jakub at gcc dot gnu.org
@ 2022-02-01 15:06 ` cvs-commit at gcc dot gnu.org
2022-02-01 15:10 ` [Bug tree-optimization/104307] [11 " jakub at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-02-01 15:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104307
--- Comment #4 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:e9bf6d6b0e1d67df6dcee042fbe37ab72c3a38d7
commit r12-6962-ge9bf6d6b0e1d67df6dcee042fbe37ab72c3a38d7
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Feb 1 16:02:54 2022 +0100
veclower: Fix up -fcompare-debug issue in expand_vector_comparison
[PR104307]
The following testcase fails -fcompare-debug, because
expand_vector_comparison
since r11-1786-g1ac9258cca8030745d3c0b8f63186f0adf0ebc27 sets
vec_cond_expr_only when it sees some use other than VEC_COND_EXPR that uses
the lhs in its condition.
Obviously we should ignore debug stmts when doing so, e.g. by not pushing
them to uses.
That would be a 2 liner change, but while looking at it, I'm also worried
about VEC_COND_EXPRs that would use the lhs in more than one operand,
like VEC_COND_EXPR <lhs, lhs, something> or VEC_COND_EXPR <lhs, something,
lhs>
(sure, they ought to be folded, but what if they weren't). Because if
something like that happens, then FOR_EACH_IMM_USE_FAST would push the same
stmt multiple times and expand_vector_condition can return true even when
it modifies it (for vector bool masking).
And lastly, it seems quite wasteful to safe_push statements that will just
cause vec_cond_expr_only = false; and break; in the second loop, both for
cases like 1000 immediate non-VEC_COND_EXPR uses and for cases like
999 VEC_COND_EXPRs with lhs in cond followed by a single non-VEC_COND_EXPR
use. So this patch only pushes VEC_COND_EXPRs there.
2022-02-01 Jakub Jelinek <jakub@redhat.com>
PR middle-end/104307
* tree-vect-generic.cc (expand_vector_comparison): Don't push debug
stmts to uses vector, just set vec_cond_expr_only to false for
non-VEC_COND_EXPRs instead of pushing them into uses. Treat
VEC_COND_EXPRs that use lhs not just in rhs1, but rhs2 or rhs3 too
like non-VEC_COND_EXPRs.
* gcc.target/i386/pr104307.c: New test.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/104307] [11 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2
2022-01-31 14:37 [Bug target/104307] New: [11/12 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2 asolokha at gmx dot com
` (4 preceding siblings ...)
2022-02-01 15:06 ` [Bug tree-optimization/104307] " cvs-commit at gcc dot gnu.org
@ 2022-02-01 15:10 ` jakub at gcc dot gnu.org
2022-02-19 8:02 ` cvs-commit at gcc dot gnu.org
2022-02-19 8:08 ` jakub at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-01 15:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104307
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[11/12 Regression] |[11 Regression]
|'-fcompare-debug' failure |'-fcompare-debug' failure
|(length) w/ -mavx512f -O2 |(length) w/ -mavx512f -O2
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/104307] [11 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2
2022-01-31 14:37 [Bug target/104307] New: [11/12 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2 asolokha at gmx dot com
` (5 preceding siblings ...)
2022-02-01 15:10 ` [Bug tree-optimization/104307] [11 " jakub at gcc dot gnu.org
@ 2022-02-19 8:02 ` cvs-commit at gcc dot gnu.org
2022-02-19 8:08 ` jakub at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-02-19 8:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104307
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:c81d1a061e5cfab6bd276c5be4cd6161b11e6d44
commit r11-9596-gc81d1a061e5cfab6bd276c5be4cd6161b11e6d44
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Feb 1 16:02:54 2022 +0100
veclower: Fix up -fcompare-debug issue in expand_vector_comparison
[PR104307]
The following testcase fails -fcompare-debug, because
expand_vector_comparison
since r11-1786-g1ac9258cca8030745d3c0b8f63186f0adf0ebc27 sets
vec_cond_expr_only when it sees some use other than VEC_COND_EXPR that uses
the lhs in its condition.
Obviously we should ignore debug stmts when doing so, e.g. by not pushing
them to uses.
That would be a 2 liner change, but while looking at it, I'm also worried
about VEC_COND_EXPRs that would use the lhs in more than one operand,
like VEC_COND_EXPR <lhs, lhs, something> or VEC_COND_EXPR <lhs, something,
lhs>
(sure, they ought to be folded, but what if they weren't). Because if
something like that happens, then FOR_EACH_IMM_USE_FAST would push the same
stmt multiple times and expand_vector_condition can return true even when
it modifies it (for vector bool masking).
And lastly, it seems quite wasteful to safe_push statements that will just
cause vec_cond_expr_only = false; and break; in the second loop, both for
cases like 1000 immediate non-VEC_COND_EXPR uses and for cases like
999 VEC_COND_EXPRs with lhs in cond followed by a single non-VEC_COND_EXPR
use. So this patch only pushes VEC_COND_EXPRs there.
2022-02-01 Jakub Jelinek <jakub@redhat.com>
PR middle-end/104307
* tree-vect-generic.c (expand_vector_comparison): Don't push debug
stmts to uses vector, just set vec_cond_expr_only to false for
non-VEC_COND_EXPRs instead of pushing them into uses. Treat
VEC_COND_EXPRs that use lhs not just in rhs1, but rhs2 or rhs3 too
like non-VEC_COND_EXPRs.
* gcc.target/i386/pr104307.c: New test.
(cherry picked from commit e9bf6d6b0e1d67df6dcee042fbe37ab72c3a38d7)
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/104307] [11 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2
2022-01-31 14:37 [Bug target/104307] New: [11/12 Regression] '-fcompare-debug' failure (length) w/ -mavx512f -O2 asolokha at gmx dot com
` (6 preceding siblings ...)
2022-02-19 8:02 ` cvs-commit at gcc dot gnu.org
@ 2022-02-19 8:08 ` jakub at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-19 8:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104307
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 11.3+ too.
^ permalink raw reply [flat|nested] 9+ messages in thread