[Bug c++/96575] New: std::ranges::sort is not usable as a 'constexpr' function when saving its return value in lambda function

[Bug c++/96575] New: std::ranges::sort is not usable as a 'constexpr' function when saving its return value in lambda function

[hewillk at gmail dot com]

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

            Bug ID: 96575
           Summary: std::ranges::sort is not usable as a 'constexpr'
                    function when saving its return value in lambda
                    function
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hewillk at gmail dot com
  Target Milestone: ---

(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 [=] {

[Bug c++/96575] std::ranges::sort is not usable as a 'constexpr' function when saving its return value in lambda function

[hewillk at gmail dot com]

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

--- Comment #1 from 康桓瑋 <hewillk at gmail dot com> ---
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)

[Bug c++/96575] std::ranges::sort is not usable as a 'constexpr' function when saving its return value in lambda function

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
                 CC|                            |ppalka at gcc dot gnu.org
   Last reconfirmed|                            |2020-10-08
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Confirmed. Taking a look.

[Bug c++/96575] std::ranges::sort is not usable as a 'constexpr' function when saving its return value in lambda function

[cvs-commit at gcc dot gnu.org]

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

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

[Bug c++/96575] std::ranges::sort is not usable as a 'constexpr' function when saving its return value in lambda function

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |11.0
             Status|ASSIGNED                    |RESOLVED

--- Comment #4 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Thanks for the report.  The testcase was triggering a bug in the constexpr
evaluator, which should now been fixed.