[Bug c++/115754] New: C++26 ICE on constexpr new

[jakub at gcc dot gnu.org]

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

            Bug ID: 115754
           Summary: C++26 ICE on constexpr new
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
                CC: jason at gcc dot gnu.org, unassigned at gcc dot gnu.org
        Depends on: 115744
            Blocks: 110338
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #115744 +++

While working on the PR115744 patch, I've noticed that vanilla trunk or GCC 14
ICE on

namespace std
{
  using size_t = decltype (sizeof 0);

  template <typename T>
  struct allocator
  {
    constexpr allocator () noexcept {}

    constexpr T *allocate (size_t n)
    { return static_cast<T *> (::operator new (n * sizeof(T))); }

    constexpr void
    deallocate (T *p, size_t n)
    { ::operator delete (p); }
  };
}

constexpr void *
operator new (std::size_t, void *p) noexcept
{ return p; }

constexpr bool
foo ()
{
  std::allocator<int> a;
  auto b = a.allocate (1);
  ::new (b) int ();
  a.deallocate (b, 1);
  return true;
}

constexpr bool a = foo ();

with -std=c++26.  Of course, the C++26 constexpr placement new support isn't
there and users shouldn't be declaring placement operator new themselves,
especially with constexpr when it is not, but still we shouldn't ICE.

Filing separately in case we want to backport it.

The fix for this in the WIP patch was the
@@ -8103,7 +8103,10 @@ cxx_eval_constant_expression (const cons
        tree oldop = TREE_OPERAND (t, 0);

        tree op = cxx_eval_constant_expression (ctx, oldop,
-                                               lval,
+                                               (VOID_TYPE_P (TREE_TYPE (t))
+                                                || (tcode == VIEW_CONVERT_EXPR
+                                                    && lval == vc_glvalue))
+                                               ? lval : vc_prvalue,
                                                non_constant_p, overflow_p);
        if (*non_constant_p)
          return t;
hunk in constexpr.cc, if lval is vc_discard but we aren't really discarding the
result,
I think the void * -> something * cast code at least but most likely various
other checks rely on op being actually an rvalue.  If this is a (void) cast,
discarding it is fine, we won't process anything.  And I think
VIEW_CONVERT_EXPR can be around various VAR_DECLs on the lhs, so I think we
also need at least vc_glvalue handling for that.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338
[Bug 110338] Implement C++26 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115744
[Bug 115744] [C++26] P2747R2 - constexpr placement new