[Bug c++/111703] New: [C++20]Compiler fails when using generic lambda in specific situation

[Bug c++/111703] New: [C++20]Compiler fails when using generic lambda in specific situation

[watanabemakoto.math at gmail dot com]

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

            Bug ID: 111703
           Summary: [C++20]Compiler fails when using generic lambda in
                    specific situation
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: watanabemakoto.math at gmail dot com
  Target Milestone: ---

Consider the example:

```
#include <utility>
using P = std::pair<int, int>;
void (*f)(P);

int main(){
    [](auto) {
        P x;
        f(x);
    };
}
```

GCC 13.2.0 fails to compile the example. Compile option is `-std=c++20` .

Godbolt playground: https://godbolt.org/z/nPMb38ond

[Bug c++/111703] [12/13/14 Regression] [C++20]Compiler fails when using generic lambda in specific situation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.4

[Bug c++/111703] [12/13/14 Regression] [C++20]Compiler fails when using generic lambda in specific situation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |c++-lambda

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note I reduced a related testcase into PR 111705 but that fails even for
template functions rather than templated lamdbas (which is what generic lamdbas
are really).

[Bug c++/111703] [12/13/14 Regression] [C++20]Compiler fails when using generic lambda in specific situation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-10-05
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I should have marked this as Confirmed yesterday.

[Bug c++/111703] [12/13/14 Regression] [C++20]Compiler fails when using generic lambda in specific situation

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
FWIW a workaround is to ensure an equivalent 'f(x)' call is first checked in a
non-template context, e.g.

#include <utility>
using P = std::pair<int, int>;
void (*f)(P);

static_assert(requires(P x) { f(x); }); // work around PR111703

int main(){
    [](auto) {
        P x;
        f(x);
    };
}

[Bug c++/111703] [11/12/13/14 Regression] [C++20]Compiler fails when using generic lambda in specific situation since r11-550-gf65a3299a521a4

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|11.4.0                      |10.5.0
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org
           Keywords|needs-bisection,            |
                   |needs-reduction             |
      Known to fail|                            |11.4.0
   Target Milestone|12.4                        |11.5
             Status|NEW                         |ASSIGNED
            Summary|[12/13/14 Regression]       |[11/12/13/14 Regression]
                   |[C++20]Compiler fails when  |[C++20]Compiler fails when
                   |using generic lambda in     |using generic lambda in
                   |specific situation          |specific situation since
                   |                            |r11-550-gf65a3299a521a4

--- Comment #4 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Reduced testcase exhibitng an 11 regression:

template<class T>
constexpr bool always_true() { return true; }

struct P {
  P() = default;

  template<class T>
    requires (always_true<T>())
  constexpr P(const T&) { }

  int n, m;
};

void (*f)(P);

template<class T>
constexpr bool h() {
  P x;
  f(x);
  return true;
}

[Bug c++/111703] [11/12/13/14 Regression] [C++20]Compiler fails when using generic lambda in specific situation since r11-550-gf65a3299a521a4

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:6665a8572c8f24bd55c6081c91f461442c94dcfb

commit r14-5502-g6665a8572c8f24bd55c6081c91f461442c94dcfb
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Nov 15 12:03:16 2023 -0500

    c++: constantness of local var in constexpr fn [PR111703, PR112269]

    potential_constant_expression was incorrectly treating most local
    variables from a constexpr function as constant because it wasn't
    considering the 'now' parameter.  This patch fixes this by relaxing
    its var_in_maybe_constexpr_fn checks accordingly, which turns out to
    partially fix two recently reported regressions:

    PR111703 is a regression caused by r11-550-gf65a3299a521a4 for restricting
    constexpr evaluation during warning-dependent folding.  The mechanism is
    intended to restrict only constant evaluation of the instantiated
    non-dependent expression, but it also ends up restricting constant
    evaluation occurring during instantiation of the expression, in particular
    when instantiating the converted argument 'x' (a VIEW_CONVERT_EXPR) into
    a copy constructor call.  This seems like a flaw in the mechanism, though
    I don't know if we want to fix the mechanism or get rid of it completely
    since the original testcases which motivated the mechanism are fixed more
    simply by r13-1225-gb00b95198e6720.  In any case, this patch partially
    fixes this by making us correctly treat 'x' as non-constant which prevents
    the problematic warning-dependent folding from occurring at all.

    PR112269 is caused by r14-4796-g3e3d73ed5e85e7 for merging tsubst_copy
    into tsubst_copy_and_build.  tsubst_copy used to exit early when 'args'
    was empty, behavior which that commit deliberately didn't preserve.
    This early exit masked the fact that COMPLEX_EXPR wasn't handled by
    tsubst at all, and is a tree code that apparently we could see during
    warning-dependent folding on some targets.  A complete fix is to add
    handling for this tree code in tsubst_expr, but this patch should fix
    the reported testsuite failures since the COMPLEX_EXPRs that crop up
    in <complex> are considered non-constant expressions after this patch.

            PR c++/111703
            PR c++/112269

    gcc/cp/ChangeLog:

            * constexpr.cc (potential_constant_expression_1) <case VAR_DECL>:
            Only consider var_in_maybe_constexpr_fn if 'now' is false.
            <case INDIRECT_REF>: Likewise.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/concepts-fn8.C: New test.

[Bug c++/111703] [11/12/13/14 Regression] [C++20]Compiler fails when using generic lambda in specific situation since r11-550-gf65a3299a521a4

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:0077c0fb19981c108a01cd15af9b2d6d478c183b

commit r14-5531-g0077c0fb19981c108a01cd15af9b2d6d478c183b
Author: Patrick Palka <ppalka@redhat.com>
Date:   Thu Nov 16 09:32:07 2023 -0500

    c++: constantness of call to function pointer [PR111703]

    potential_constant_expression for CALL_EXPR tests FUNCTION_POINTER_TYPE_P
    on the callee rather than on the type of the callee, which means we
    always pass want_rval=any when recursing and so may fail to identify a
    non-constant function pointer callee as such.  Fixing this turns out to
    further work around PR111703.

            PR c++/111703
            PR c++/107939

    gcc/cp/ChangeLog:

            * constexpr.cc (potential_constant_expression_1) <case CALL_EXPR>:
            Fix FUNCTION_POINTER_TYPE_P test.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/concepts-fn8.C: Extend test.
            * g++.dg/diagnostic/constexpr4.C: New test.

[Bug c++/111703] [11/12/13 Regression] [C++20]Compiler fails when using generic lambda in specific situation since r11-550-gf65a3299a521a4

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12/13/14 Regression]    |[11/12/13 Regression]
                   |[C++20]Compiler fails when  |[C++20]Compiler fails when
                   |using generic lambda in     |using generic lambda in
                   |specific situation since    |specific situation since
                   |r11-550-gf65a3299a521a4     |r11-550-gf65a3299a521a4

--- Comment #7 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Should be sufficiently fixed on trunk so far

[Bug c++/111703] [11/12/13 Regression] [C++20]Compiler fails when using generic lambda in specific situation since r11-550-gf65a3299a521a4

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:dd57446bd90c3225ce45e8818c5b00f2e86a9607

commit r13-8097-gdd57446bd90c3225ce45e8818c5b00f2e86a9607
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Nov 15 12:03:16 2023 -0500

    c++: constantness of local var in constexpr fn [PR111703, PR112269]

    potential_constant_expression was incorrectly treating most local
    variables from a constexpr function as constant because it wasn't
    considering the 'now' parameter.  This patch fixes this by relaxing
    its var_in_maybe_constexpr_fn checks accordingly, which turns out to
    partially fix two recently reported regressions:

    PR111703 is a regression caused by r11-550-gf65a3299a521a4 for restricting
    constexpr evaluation during warning-dependent folding.  The mechanism is
    intended to restrict only constant evaluation of the instantiated
    non-dependent expression, but it also ends up restricting constant
    evaluation occurring during instantiation of the expression, in particular
    when instantiating the converted argument 'x' (a VIEW_CONVERT_EXPR) into
    a copy constructor call.  This seems like a flaw in the mechanism, though
    I don't know if we want to fix the mechanism or get rid of it completely
    since the original testcases which motivated the mechanism are fixed more
    simply by r13-1225-gb00b95198e6720.  In any case, this patch partially
    fixes this by making us correctly treat 'x' as non-constant which prevents
    the problematic warning-dependent folding from occurring at all.

    PR112269 is caused by r14-4796-g3e3d73ed5e85e7 for merging tsubst_copy
    into tsubst_copy_and_build.  tsubst_copy used to exit early when 'args'
    was empty, behavior which that commit deliberately didn't preserve.
    This early exit masked the fact that COMPLEX_EXPR wasn't handled by
    tsubst at all, and is a tree code that apparently we could see during
    warning-dependent folding on some targets.  A complete fix is to add
    handling for this tree code in tsubst_expr, but this patch should fix
    the reported testsuite failures since the COMPLEX_EXPRs that crop up
    in <complex> are considered non-constant expressions after this patch.

            PR c++/111703
            PR c++/112269

    gcc/cp/ChangeLog:

            * constexpr.cc (potential_constant_expression_1) <case VAR_DECL>:
            Only consider var_in_maybe_constexpr_fn if 'now' is false.
            <case INDIRECT_REF>: Likewise.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/concepts-fn8.C: New test.

    (cherry picked from commit 6665a8572c8f24bd55c6081c91f461442c94dcfb)

[Bug c++/111703] [11/12/13 Regression] [C++20]Compiler fails when using generic lambda in specific situation since r11-550-gf65a3299a521a4

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:cc4cbf38e842cf023e2bdc63a51ef836d7726d8e

commit r13-8098-gcc4cbf38e842cf023e2bdc63a51ef836d7726d8e
Author: Patrick Palka <ppalka@redhat.com>
Date:   Thu Nov 16 09:32:07 2023 -0500

    c++: constantness of call to function pointer [PR111703]

    potential_constant_expression for CALL_EXPR tests FUNCTION_POINTER_TYPE_P
    on the callee rather than on the type of the callee, which means we
    always pass want_rval=any when recursing and so may fail to identify a
    non-constant function pointer callee as such.  Fixing this turns out to
    further work around PR111703.

            PR c++/111703
            PR c++/107939

    gcc/cp/ChangeLog:

            * constexpr.cc (potential_constant_expression_1) <case CALL_EXPR>:
            Fix FUNCTION_POINTER_TYPE_P test.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/concepts-fn8.C: Extend test.
            * g++.dg/diagnostic/constexpr4.C: New test.

    (cherry picked from commit 0077c0fb19981c108a01cd15af9b2d6d478c183b)

[Bug c++/111703] [11/12/13 Regression] [C++20]Compiler fails when using generic lambda in specific situation since r11-550-gf65a3299a521a4

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:6a31302a6c8bec9af3c93f736c2b1a76e9a530e2

commit r12-10016-g6a31302a6c8bec9af3c93f736c2b1a76e9a530e2
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Nov 15 12:03:16 2023 -0500

    c++: constantness of local var in constexpr fn [PR111703, PR112269]

    potential_constant_expression was incorrectly treating most local
    variables from a constexpr function as constant because it wasn't
    considering the 'now' parameter.  This patch fixes this by relaxing
    its var_in_maybe_constexpr_fn checks accordingly, which turns out to
    partially fix two recently reported regressions:

    PR111703 is a regression caused by r11-550-gf65a3299a521a4 for restricting
    constexpr evaluation during warning-dependent folding.  The mechanism is
    intended to restrict only constant evaluation of the instantiated
    non-dependent expression, but it also ends up restricting constant
    evaluation occurring during instantiation of the expression, in particular
    when instantiating the converted argument 'x' (a VIEW_CONVERT_EXPR) into
    a copy constructor call.  This seems like a flaw in the mechanism, though
    I don't know if we want to fix the mechanism or get rid of it completely
    since the original testcases which motivated the mechanism are fixed more
    simply by r13-1225-gb00b95198e6720.  In any case, this patch partially
    fixes this by making us correctly treat 'x' as non-constant which prevents
    the problematic warning-dependent folding from occurring at all.

    PR112269 is caused by r14-4796-g3e3d73ed5e85e7 for merging tsubst_copy
    into tsubst_copy_and_build.  tsubst_copy used to exit early when 'args'
    was empty, behavior which that commit deliberately didn't preserve.
    This early exit masked the fact that COMPLEX_EXPR wasn't handled by
    tsubst at all, and is a tree code that apparently we could see during
    warning-dependent folding on some targets.  A complete fix is to add
    handling for this tree code in tsubst_expr, but this patch should fix
    the reported testsuite failures since the COMPLEX_EXPRs that crop up
    in <complex> are considered non-constant expressions after this patch.

            PR c++/111703
            PR c++/112269

    gcc/cp/ChangeLog:

            * constexpr.cc (potential_constant_expression_1) <case VAR_DECL>:
            Only consider var_in_maybe_constexpr_fn if 'now' is false.
            <case INDIRECT_REF>: Likewise.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/concepts-fn8.C: New test.

    (cherry picked from commit 6665a8572c8f24bd55c6081c91f461442c94dcfb)

[Bug c++/111703] [11/12/13 Regression] [C++20]Compiler fails when using generic lambda in specific situation since r11-550-gf65a3299a521a4

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:c9cb7e3d75d494a6591887a99d0d3f7f7a307b2e

commit r12-10017-gc9cb7e3d75d494a6591887a99d0d3f7f7a307b2e
Author: Patrick Palka <ppalka@redhat.com>
Date:   Thu Nov 16 09:32:07 2023 -0500

    c++: constantness of call to function pointer [PR111703]

    potential_constant_expression for CALL_EXPR tests FUNCTION_POINTER_TYPE_P
    on the callee rather than on the type of the callee, which means we
    always pass want_rval=any when recursing and so may fail to identify a
    non-constant function pointer callee as such.  Fixing this turns out to
    further work around PR111703.

            PR c++/111703
            PR c++/107939

    gcc/cp/ChangeLog:

            * constexpr.cc (potential_constant_expression_1) <case CALL_EXPR>:
            Fix FUNCTION_POINTER_TYPE_P test.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/concepts-fn8.C: Extend test.
            * g++.dg/diagnostic/constexpr4.C: New test.

    (cherry picked from commit 0077c0fb19981c108a01cd15af9b2d6d478c183b)