(https://godbolt.org/z/W8zx58) #include <array> #include <algorithm> constexpr auto f(auto algo) { return [=] { // this one is okay // algo(std::array{1, 0}); // this one is also okay // auto it = algo(std::array{0, 1}); auto it = algo(std::array{1, 0}); return 0; }(); } int main() { static_assert(f(std::ranges::sort) == 0); } This fails on gcc 10.2 and trunk with: <source>:13:23: error: 'constexpr auto f(auto:16) [with auto:16 = std::ranges::__sort_fn]' called in a constant expression 13 | constexpr auto i = f(std::ranges::sort); | ~^~~~~~~~~~~~~~~~~~~ <source>:4:16: note: 'constexpr auto f(auto:16) [with auto:16 = std::ranges::__sort_fn]' is not usable as a 'constexpr' function because: 4 | constexpr auto f(auto algo) { | ^ <source>:8:8: error: call to non-'constexpr' function 'f<std::ranges::__sort_fn>::<lambda()>' 5 | return [=] { | ~~~~~ 6 | auto it = algo(std::array{1, 0}); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 7 | return 0; | ~~~~~~~~~ 8 | }(); | ~^~ <source>:5:14: note: 'f<std::ranges::__sort_fn>::<lambda()>' is not usable as a 'constexpr' function because: 5 | return [=] {
I don't know whether this is same issue or not: #include <algorithm> constexpr auto replace = [](auto old_x, auto new_x) { return [=](auto r) { return std::ranges::replace(r, old_x, new_x); }; }; // this one is ok constexpr auto f1(auto algo) { [=]() { algo(std::array{0}); return 0; }(); return true; } // this one fails with non-constant condition constexpr auto f2(auto algo) { constexpr auto it = [=]() { algo(std::array{0}); return 0; }(); return true; } static_assert(f1(replace(0, 1))); static_assert(f2(replace(0, 1))); (https://godbolt.org/z/Kaq4j5)
Confirmed. Taking a look.
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:46fdced6a9f936ae4d5b42347d7d87f69875683a commit r11-4230-g46fdced6a9f936ae4d5b42347d7d87f69875683a Author: Patrick Palka <ppalka@redhat.com> Date: Thu Oct 22 07:33:58 2020 -0400 c++: constexpr evaluation and bare EMPTY_CLASS_EXPR [PR96575] In the testcase below, folding of the initializer for 'ret' inside the instantiated f<lambda>::lambda ends up yielding an initializer for which potential_constant_expression returns false. This causes finish_function to mark the lambda as non-constexpr, which ultimately causes us to reject 'f(g)' as a call to a non-constexpr function. The initializer for 'ret' inside f<lambda>::lambda, prior to folding, is the CALL_EXPR <lambda(S)>::operator() (&cb, ({}, <<< Unknown tree: empty_class_expr >>>;)) where the second argument is a COMPOUND_EXPR whose second operand is an EMPTY_CLASS_EXPR that was formed by build_class_a. cp_fully_fold_init is able to only partially fold this initializer: it gets rid of the side-effectless COMPOUND_EXPR to obtain <lambda(S)>::operator() (&cb, <<< Unknown tree: empty_class_expr >>>) as the final initializer for 'ret'. This initializer no longer satifies potential_constant_expression due to the bare EMPTY_CLASS_EXPR which is not wrapped in a COMPOUND_EXPR. (cp_fully_fold_init first tries maybe_constant_value on the original CALL_EXPR, but constexpr evaluation punts upon seeing __builtin_is_constant_evaluated, since manifestly_const_eval is false.) To fix this, it seems we could either make cp_fold preserve the COMPOUND_EXPR trees produced by build_call_a, or we could improve the constexpr machinery to treat EMPTY_CLASS_EXPR trees as first-class citizens. Assuming it's safe to continue folding away these COMPOUND_EXPRs, the second approach seems cleaner, so this patch implements the second approach. gcc/cp/ChangeLog: PR c++/96575 * constexpr.c (cxx_eval_constant_expression) <case EMPTY_CLASS_EXPR>: Lower it to a CONSTRUCTOR. (potential_constant_expression_1) <case COMPOUND_EXPR>: Remove now-redundant handling of COMPOUND_EXPR with EMPTY_CLASS_EXPR second operand. <case EMPTY_CLASS_EXPR>: Return true instead of false. gcc/testsuite/ChangeLog: PR c++/96575 * g++.dg/cpp1z/constexpr-96575.C: New test.
Thanks for the report. The testcase was triggering a bug in the constexpr evaluator, which should now been fixed.