* [Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression
2021-01-14 9:17 [Bug c++/98672] New: constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression ryan_greenblatt at brown dot edu
@ 2021-01-14 11:48 ` jakub at gcc dot gnu.org
2021-01-21 16:23 ` cvs-commit at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-14 11:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98672
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2021-01-14
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 49964
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49964&action=edit
gcc11-pr98672.patch
Untested fix.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression
2021-01-14 9:17 [Bug c++/98672] New: constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression ryan_greenblatt at brown dot edu
2021-01-14 11:48 ` [Bug c++/98672] " jakub at gcc dot gnu.org
@ 2021-01-21 16:23 ` cvs-commit at gcc dot gnu.org
2021-01-21 16:28 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-01-21 16:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98672
--- Comment #2 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:0fb7aa205afebe178c06683037ccd4c41104337a
commit r11-6840-g0fb7aa205afebe178c06683037ccd4c41104337a
Author: Jakub Jelinek <jakub@redhat.com>
Date: Thu Jan 21 17:20:24 2021 +0100
c++: Fix up potential_constant_expression_1 FOR/WHILE_STMT handling
[PR98672]
The following testcase is rejected even when it is valid.
The problem is that potential_constant_expression_1 doesn't have the
accurate *jump_target tracking cxx_eval_* has, and when the loop has
a condition that isn't guaranteed to be always true, the body isn't walked
at all. That is mostly a correct conservative behavior, except that it
doesn't detect if there are any return statements in the body, which means
the loop might return instead of falling through to the next statement.
We already have code for return stmt discovery in code snippets we don't
try to evaluate for switches, so this patch reuses that for FOR_STMT
and WHILE_STMT bodies.
Note, I haven't touched FOR_EXPR, with statement expressions it could
have return stmts in it too, or it could have break or continue statements
that wouldn't bind to the current loop but to something outer. That
case is clearly mishandled by potential_constant_expression_1 even
when the condition is missing or is always true, and it wouldn't surprise
me
if cxx_eval_* didn't handle it right either, so I'm deferring that to
separate PR for later. We'd need proper test coverage for all of that.
> Hmm, IF_STMT probably also needs to check the else clause, if the
condition
> isn't a known constant.
You're right, I thought it was ok because it recurses with tf_none, but
if the then branch is potentially constant and only else returns, continues
or breaks, then as the enhanced testcase shows we were mishandling it too.
2021-01-21 Jakub Jelinek <jakub@redhat.com>
PR c++/98672
* constexpr.c (check_for_return_continue_data): Add break_stmt
member.
(check_for_return_continue): Also look for BREAK_STMT. Handle
SWITCH_STMT by ignoring break_stmt from its body.
(potential_constant_expression_1) <case FOR_STMT>,
<case WHILE_STMT>: If the condition isn't constant true, check if
the loop body can contain a return stmt.
<case SWITCH_STMT>: Adjust check_for_return_continue_data
initializer.
<case IF_STMT>: If recursion with tf_none is successful,
merge *jump_target from the branches - returns with highest
priority,
breaks or continues lower. If then branch is potentially constant
and
doesn't return, check the else branch if it could return, break or
continue.
* g++.dg/cpp1y/constexpr-98672.C: New test.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression
2021-01-14 9:17 [Bug c++/98672] New: constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression ryan_greenblatt at brown dot edu
2021-01-14 11:48 ` [Bug c++/98672] " jakub at gcc dot gnu.org
2021-01-21 16:23 ` cvs-commit at gcc dot gnu.org
@ 2021-01-21 16:28 ` jakub at gcc dot gnu.org
2021-01-29 19:19 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-01-21 16:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98672
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk. I think we need to backport this at least to 10.3
eventually.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression
2021-01-14 9:17 [Bug c++/98672] New: constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression ryan_greenblatt at brown dot edu
` (2 preceding siblings ...)
2021-01-21 16:28 ` jakub at gcc dot gnu.org
@ 2021-01-29 19:19 ` cvs-commit at gcc dot gnu.org
2021-04-20 23:31 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-01-29 19:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98672
--- 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:8182cbe3fb2c2d20e8dff9d2476fb94046e560b3
commit r10-9315-g8182cbe3fb2c2d20e8dff9d2476fb94046e560b3
Author: Jakub Jelinek <jakub@redhat.com>
Date: Thu Jan 21 17:20:24 2021 +0100
c++: Fix up potential_constant_expression_1 FOR/WHILE_STMT handling
[PR98672]
The following testcase is rejected even when it is valid.
The problem is that potential_constant_expression_1 doesn't have the
accurate *jump_target tracking cxx_eval_* has, and when the loop has
a condition that isn't guaranteed to be always true, the body isn't walked
at all. That is mostly a correct conservative behavior, except that it
doesn't detect if there are any return statements in the body, which means
the loop might return instead of falling through to the next statement.
We already have code for return stmt discovery in code snippets we don't
try to evaluate for switches, so this patch reuses that for FOR_STMT
and WHILE_STMT bodies.
Note, I haven't touched FOR_EXPR, with statement expressions it could
have return stmts in it too, or it could have break or continue statements
that wouldn't bind to the current loop but to something outer. That
case is clearly mishandled by potential_constant_expression_1 even
when the condition is missing or is always true, and it wouldn't surprise
me
if cxx_eval_* didn't handle it right either, so I'm deferring that to
separate PR for later. We'd need proper test coverage for all of that.
> Hmm, IF_STMT probably also needs to check the else clause, if the
condition
> isn't a known constant.
You're right, I thought it was ok because it recurses with tf_none, but
if the then branch is potentially constant and only else returns, continues
or breaks, then as the enhanced testcase shows we were mishandling it too.
2021-01-21 Jakub Jelinek <jakub@redhat.com>
PR c++/98672
* constexpr.c (check_for_return_continue_data): Add break_stmt
member.
(check_for_return_continue): Also look for BREAK_STMT. Handle
SWITCH_STMT by ignoring break_stmt from its body.
(potential_constant_expression_1) <case FOR_STMT>,
<case WHILE_STMT>: If the condition isn't constant true, check if
the loop body can contain a return stmt.
<case SWITCH_STMT>: Adjust check_for_return_continue_data
initializer.
<case IF_STMT>: If recursion with tf_none is successful,
merge *jump_target from the branches - returns with highest
priority,
breaks or continues lower. If then branch is potentially constant
and
doesn't return, check the else branch if it could return, break or
continue.
* g++.dg/cpp1y/constexpr-98672.C: New test.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression
2021-01-14 9:17 [Bug c++/98672] New: constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression ryan_greenblatt at brown dot edu
` (3 preceding siblings ...)
2021-01-29 19:19 ` cvs-commit at gcc dot gnu.org
@ 2021-04-20 23:31 ` cvs-commit at gcc dot gnu.org
2021-04-22 14:12 ` 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 @ 2021-04-20 23:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98672
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:2fe1131465af7352be9e03773c30a3f6059af993
commit r9-9406-g2fe1131465af7352be9e03773c30a3f6059af993
Author: Jakub Jelinek <jakub@redhat.com>
Date: Thu Jan 21 17:20:24 2021 +0100
c++: Fix up potential_constant_expression_1 FOR/WHILE_STMT handling
[PR98672]
The following testcase is rejected even when it is valid.
The problem is that potential_constant_expression_1 doesn't have the
accurate *jump_target tracking cxx_eval_* has, and when the loop has
a condition that isn't guaranteed to be always true, the body isn't walked
at all. That is mostly a correct conservative behavior, except that it
doesn't detect if there are any return statements in the body, which means
the loop might return instead of falling through to the next statement.
We already have code for return stmt discovery in code snippets we don't
try to evaluate for switches, so this patch reuses that for FOR_STMT
and WHILE_STMT bodies.
Note, I haven't touched FOR_EXPR, with statement expressions it could
have return stmts in it too, or it could have break or continue statements
that wouldn't bind to the current loop but to something outer. That
case is clearly mishandled by potential_constant_expression_1 even
when the condition is missing or is always true, and it wouldn't surprise
me
if cxx_eval_* didn't handle it right either, so I'm deferring that to
separate PR for later. We'd need proper test coverage for all of that.
> Hmm, IF_STMT probably also needs to check the else clause, if the
condition
> isn't a known constant.
You're right, I thought it was ok because it recurses with tf_none, but
if the then branch is potentially constant and only else returns, continues
or breaks, then as the enhanced testcase shows we were mishandling it too.
2021-01-21 Jakub Jelinek <jakub@redhat.com>
PR c++/98672
* constexpr.c (check_for_return_continue_data): Add break_stmt
member.
(check_for_return_continue): Also look for BREAK_STMT. Handle
SWITCH_STMT by ignoring break_stmt from its body.
(potential_constant_expression_1) <case FOR_STMT>,
<case WHILE_STMT>: If the condition isn't constant true, check if
the loop body can contain a return stmt.
<case SWITCH_STMT>: Adjust check_for_return_continue_data
initializer.
<case IF_STMT>: If recursion with tf_none is successful,
merge *jump_target from the branches - returns with highest
priority,
breaks or continues lower. If then branch is potentially constant
and
doesn't return, check the else branch if it could return, break or
continue.
* g++.dg/cpp1y/constexpr-98672.C: New test.
(cherry picked from commit 8182cbe3fb2c2d20e8dff9d2476fb94046e560b3)
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression
2021-01-14 9:17 [Bug c++/98672] New: constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression ryan_greenblatt at brown dot edu
` (4 preceding siblings ...)
2021-04-20 23:31 ` cvs-commit at gcc dot gnu.org
@ 2021-04-22 14:12 ` jakub at gcc dot gnu.org
2021-08-28 21:45 ` pinskia at gcc dot gnu.org
2021-08-28 21:46 ` pinskia at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-04-22 14:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98672
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression
2021-01-14 9:17 [Bug c++/98672] New: constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression ryan_greenblatt at brown dot edu
` (5 preceding siblings ...)
2021-04-22 14:12 ` jakub at gcc dot gnu.org
@ 2021-08-28 21:45 ` pinskia at gcc dot gnu.org
2021-08-28 21:46 ` pinskia at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-08-28 21:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98672
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to work| |10.3.0, 11.1.0, 9.4.0
Known to fail| |10.2.0, 8.5.0, 9.3.0
Target Milestone|--- |9.4
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression
2021-01-14 9:17 [Bug c++/98672] New: constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression ryan_greenblatt at brown dot edu
` (6 preceding siblings ...)
2021-08-28 21:45 ` pinskia at gcc dot gnu.org
@ 2021-08-28 21:46 ` pinskia at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-08-28 21:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98672
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |r-gcc at mail dot uk
--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 96155 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 9+ messages in thread