[Bug c++/98672] New: constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression

[Bug c++/98672] New: constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression

[ryan_greenblatt at brown dot edu]

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

            Bug ID: 98672
           Summary: constexpr function - for loop with return statement
                    doesn't get recognized as constexpr subexpression
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ryan_greenblatt at brown dot edu
  Target Milestone: ---

https://godbolt.org/z/bEaWhj

```
void not_constexpr() {}

static constexpr int constexpr_loop() {
  for (int i = 0; i < 1; ++i) {
    return i;
  }

  // builds fine with just this:
  // __builtin_unreachable();
  // but not with this:
  not_constexpr();
}

constexpr unsigned i = constexpr_loop();
```
fails with c++14/17/20 on all versions of gcc I tried

[Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression

[jakub at gcc dot gnu.org]

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.

[Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression

[cvs-commit at gcc dot gnu.org]

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.

[Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression

[jakub at gcc dot gnu.org]

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.

[Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression

[cvs-commit at gcc dot gnu.org]

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.

[Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression

[cvs-commit at gcc dot gnu.org]

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)

[Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression

[jakub at gcc dot gnu.org]

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.

[Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression

[pinskia at gcc dot gnu.org]

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

[Bug c++/98672] constexpr function - for loop with return statement doesn't get recognized as constexpr subexpression

[pinskia at gcc dot gnu.org]

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. ***