[Bug c++/104513] New: [12 Regression] goto cdtor_label failures on arm since r12-5256

[Bug c++/104513] New: [12 Regression] goto cdtor_label failures on arm since r12-5256

[jakub at gcc dot gnu.org]

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

            Bug ID: 104513
           Summary: [12 Regression] goto cdtor_label failures on arm since
                    r12-5256
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

struct A {
  int a1;
  short a2;
  short a3;
  long a4;
  constexpr A() : a1(), a2(), a3(), a4() { return; }
};
is rejected since r12-5256-g37326651b439bac55d96fb5a43f4daf25e401eda
on arm with:
mptPathString.ii: In constructor ‘constexpr A::A()’:
mptPathString.ii:6:44: error: ‘goto’ is not a constant expression
    6 |   constexpr A() : a1(), a2(), a3(), a4() { return; }
      |                                            ^~~~~~
for -std=c++14 and higher.
Also,
struct S { constexpr S (int x) : s (x) {} constexpr ~S () { s = 5; return; s =
6; } int s; };
constexpr S s = 42;
is rejected with -std=c++20 and higher on all arches incorrectly, but this one
for much longer (GCC 10+).
finish_return_stmt does:
      if (DECL_DESTRUCTOR_P (current_function_decl)
          || (DECL_CONSTRUCTOR_P (current_function_decl)
              && targetm.cxx.cdtor_returns_this ()))
        {
          /* Similarly, all destructors must run destructors for
             base-classes before returning.  So, all returns in a
             destructor get sent to the DTOR_LABEL; finish_function emits
             code to return a value there.  */
          return finish_goto_stmt (cdtor_label);
        }
and so I think we need to mark the goto or label somehow to tell
potential_constant_expression that this is an artificial goto which is ok.

[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Target|                            |armv7hl-linux-gnueabi
                 CC|                            |jason at gcc dot gnu.org
   Target Milestone|---                         |12.0

[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
--- gcc/cp/constexpr.cc.jj      2022-02-11 13:52:32.697425776 +0100
+++ gcc/cp/constexpr.cc 2022-02-12 13:51:21.000274390 +0100
@@ -9364,7 +9364,7 @@ potential_constant_expression_1 (tree t,
       {
        tree *target = &TREE_OPERAND (t, 0);
        /* Gotos representing break and continue are OK.  */
-       if (breaks (target) || continues (target))
+       if (breaks (target) || continues (target) || returns (target))
          {
            *jump_target = *target;
            return true;
fixes it, but am not sure if it is the right thing for constexpr dtors for
classes with base classes.

[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
   Last reconfirmed|                            |2022-02-12

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52426
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52426&action=edit
gcc12-pr104513.patch

That seems to work fine, the base dtors are invoked from try ... finally as the
testcase in the patch shows.

[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 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:02a981a8e512934a990d1427d14e8e884409fade

commit r12-7230-g02a981a8e512934a990d1427d14e8e884409fade
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Feb 14 16:56:15 2022 +0100

    c++: Don't reject GOTO_EXPRs to cdtor_label in
potential_constant_expression_1 [PR104513]

    return in ctors on targetm.cxx.cdtor_returns_this () target like arm
    is emitted as GOTO_EXPR cdtor_label where at cdtor_label it emits
    RETURN_EXPR with the this.
    Similarly, in all dtors regardless of targetm.cxx.cdtor_returns_this ()
    a return is emitted similarly.

    potential_constant_expression_1 was rejecting these gotos and so we
    incorrectly rejected these testcases, but actual cxx_eval* is apparently
    handling these just fine.  I was a little bit worried that for the
    destruction of bases we wouldn't evaluate something we should, but as the
    testcase shows, that is evaluated through try ... finally and there is
    nothing after the cdtor_label.  For arm there is RETURN_EXPR this; but we
    don't really care about the return value from ctors and dtors during the
    constexpr evaluation.

    I must say I don't see much the point of cdtor_labels at all, I'd think
    that with try ... finally around it for non-arm we could just RETURN_EXPR
    instead of the GOTO_EXPR and the try/finally gimplification would DTRT,
    and we could just add the right return value for the arm case.

    2022-02-14  Jakub Jelinek  <jakub@redhat.com>

            PR c++/104513
            * constexpr.cc (potential_constant_expression_1) <case GOTO_EXPR>:
            Don't punt if returns (target).

            * g++.dg/cpp1y/constexpr-104513.C: New test.
            * g++.dg/cpp2a/constexpr-dtor12.C: New test.

[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 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:14f79acb6214108ce8e44a767e7eeabb456440fe

commit r11-9605-g14f79acb6214108ce8e44a767e7eeabb456440fe
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Feb 14 16:56:15 2022 +0100

    c++: Don't reject GOTO_EXPRs to cdtor_label in
potential_constant_expression_1 [PR104513]

    return in ctors on targetm.cxx.cdtor_returns_this () target like arm
    is emitted as GOTO_EXPR cdtor_label where at cdtor_label it emits
    RETURN_EXPR with the this.
    Similarly, in all dtors regardless of targetm.cxx.cdtor_returns_this ()
    a return is emitted similarly.

    potential_constant_expression_1 was rejecting these gotos and so we
    incorrectly rejected these testcases, but actual cxx_eval* is apparently
    handling these just fine.  I was a little bit worried that for the
    destruction of bases we wouldn't evaluate something we should, but as the
    testcase shows, that is evaluated through try ... finally and there is
    nothing after the cdtor_label.  For arm there is RETURN_EXPR this; but we
    don't really care about the return value from ctors and dtors during the
    constexpr evaluation.

    I must say I don't see much the point of cdtor_labels at all, I'd think
    that with try ... finally around it for non-arm we could just RETURN_EXPR
    instead of the GOTO_EXPR and the try/finally gimplification would DTRT,
    and we could just add the right return value for the arm case.

    2022-02-14  Jakub Jelinek  <jakub@redhat.com>

            PR c++/104513
            * constexpr.c (potential_constant_expression_1) <case GOTO_EXPR>:
            Don't punt if returns (target).

            * g++.dg/cpp1y/constexpr-104513.C: New test.
            * g++.dg/cpp2a/constexpr-dtor12.C: New test.

    (cherry picked from commit 02a981a8e512934a990d1427d14e8e884409fade)

[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 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:48ec754a6e157b47ea9bb1c43b0fabab511dbe65

commit r10-10680-g48ec754a6e157b47ea9bb1c43b0fabab511dbe65
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Feb 14 16:56:15 2022 +0100

    c++: Don't reject GOTO_EXPRs to cdtor_label in
potential_constant_expression_1 [PR104513]

    return in ctors on targetm.cxx.cdtor_returns_this () target like arm
    is emitted as GOTO_EXPR cdtor_label where at cdtor_label it emits
    RETURN_EXPR with the this.
    Similarly, in all dtors regardless of targetm.cxx.cdtor_returns_this ()
    a return is emitted similarly.

    potential_constant_expression_1 was rejecting these gotos and so we
    incorrectly rejected these testcases, but actual cxx_eval* is apparently
    handling these just fine.  I was a little bit worried that for the
    destruction of bases we wouldn't evaluate something we should, but as the
    testcase shows, that is evaluated through try ... finally and there is
    nothing after the cdtor_label.  For arm there is RETURN_EXPR this; but we
    don't really care about the return value from ctors and dtors during the
    constexpr evaluation.

    I must say I don't see much the point of cdtor_labels at all, I'd think
    that with try ... finally around it for non-arm we could just RETURN_EXPR
    instead of the GOTO_EXPR and the try/finally gimplification would DTRT,
    and we could just add the right return value for the arm case.

    2022-02-14  Jakub Jelinek  <jakub@redhat.com>

            PR c++/104513
            * constexpr.c (potential_constant_expression_1) <case GOTO_EXPR>:
            Don't punt if returns (target).

            * g++.dg/cpp1y/constexpr-104513.C: New test.
            * g++.dg/cpp2a/constexpr-dtor12.C: New test.

    (cherry picked from commit 02a981a8e512934a990d1427d14e8e884409fade)

[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 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:87cd4bc02f602226922e6c8099a2f4687664bed9

commit r9-10128-g87cd4bc02f602226922e6c8099a2f4687664bed9
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Feb 14 16:56:15 2022 +0100

    c++: Don't reject GOTO_EXPRs to cdtor_label in
potential_constant_expression_1 [PR104513]

    return in ctors on targetm.cxx.cdtor_returns_this () target like arm
    is emitted as GOTO_EXPR cdtor_label where at cdtor_label it emits
    RETURN_EXPR with the this.
    Similarly, in all dtors regardless of targetm.cxx.cdtor_returns_this ()
    a return is emitted similarly.

    potential_constant_expression_1 was rejecting these gotos and so we
    incorrectly rejected these testcases, but actual cxx_eval* is apparently
    handling these just fine.  I was a little bit worried that for the
    destruction of bases we wouldn't evaluate something we should, but as the
    testcase shows, that is evaluated through try ... finally and there is
    nothing after the cdtor_label.  For arm there is RETURN_EXPR this; but we
    don't really care about the return value from ctors and dtors during the
    constexpr evaluation.

    I must say I don't see much the point of cdtor_labels at all, I'd think
    that with try ... finally around it for non-arm we could just RETURN_EXPR
    instead of the GOTO_EXPR and the try/finally gimplification would DTRT,
    and we could just add the right return value for the arm case.

    2022-02-14  Jakub Jelinek  <jakub@redhat.com>

            PR c++/104513
            * constexpr.c (potential_constant_expression_1) <case GOTO_EXPR>:
            Don't punt if returns (target).

            * g++.dg/cpp1y/constexpr-104513.C: New test.

    (cherry picked from commit 02a981a8e512934a990d1427d14e8e884409fade)