[Bug libstdc++/116473] New: std::ranges::to vs constexpr

[Bug libstdc++/116473] New: std::ranges::to vs constexpr

[terra at gnome dot org]

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

            Bug ID: 116473
           Summary: std::ranges::to vs constexpr
           Product: gcc
           Version: 14.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: terra at gnome dot org
  Target Milestone: ---

Created attachment 58987
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58987&action=edit
Preprocessed source code

I *think* the following ought to work with the "constexpr".  It works fine
without and in that case generates code with 3 run-time calls to operator new
and operator delete each.


# cat ttt-ranges-to.C

#include <ranges>
#include <vector>

int
oink(void)
{
    constexpr auto v = std::views::iota(1,5) |
std::ranges::to<std::vector<int>>();
    return v.front();
}


# /usr/local/products/gcc/14.1.0/bin/g++ -std=c++23 -c ttt-ranges-to.C
In file included from
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/string:43,
                 from
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/bits/locale_classes.h:40,
                 from
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/bits/ios_base.h:41,
                 from
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/streambuf:43,
                 from
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/bits/streambuf_iterator.h:35,
                 from
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/iterator:66,
                 from
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/ranges:43,
                 from ttt-ranges-to.C:1:
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/bits/allocator.h: In function
‘int oink()’:
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/bits/allocator.h:193:52:
error: ‘std::ranges::views::__adaptor::operator|(_Range&&, _Self&&) [with _Self
= _Partial<std::ranges::__detail::_To<std::vector<int> > >; _Range =
std::ranges::iota_view<int, int>](std::ranges::to<std::vector<int> >())’ is not
a constant expression because it refers to a result of ‘operator new’
  193 |             return static_cast<_Tp*>(::operator new(__n));
      |                                      ~~~~~~~~~~~~~~^~~~~

[Bug libstdc++/116473] std::ranges::to vs constexpr

[de34 at live dot cn]

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

Jiang An <de34 at live dot cn> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |de34 at live dot cn

--- Comment #1 from Jiang An <de34 at live dot cn> ---
Currrently, a non-empty std::vector can't be a constexpr variable, because
storage dynamically allocated in the evaluation of a constant expression must
be deallocated later in the same evaluation.

The following works (https://godbolt.org/z/aEozPcEM8):
```
#include <ranges>
#include <vector>

constexpr int one = []{
    auto v = std::views::iota(1,5) | std::ranges::to<std::vector<int>>();
    return v.front();
}();
static_assert(one == 1);
```

[Bug libstdc++/116473] Better diagnostic for dynamic allocation that isn't freed by constant expression

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-08-28
           Keywords|rejects-valid               |diagnostic
            Summary|std::ranges::to vs          |Better diagnostic for
                   |constexpr                   |dynamic allocation that
                   |                            |isn't freed by constant
                   |                            |expression

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Agreed. But maybe we could improve the "because it refers to a result of
operator new" diagnostic.

The problem isn't that the pipeline expression refers to the result of operator
new, it's that it doesn't deallocate it before the end of the constant
expression.