[Bug c++/96223] New: DR 1787 and indeterminate values in constexpr context

["mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 96223
           Summary: DR 1787 and indeterminate values in constexpr context
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Use -std=c++20:

// DR 1787

#include <cstddef>

constexpr int
fn1 ()
{
  unsigned char foo;
  unsigned char u = foo; // OK: u has an indeterminate value
  return u; // UB: copy-init -> standard conversion to int
}

constexpr int
fn2 ()
{
  unsigned char foo;
  int i = foo; // UB
  return 0;
}

constexpr int
fn3 ()
{
  unsigned char foo;
  char8_t u = foo; // UB: char8_t not an unsigned ordinary character type
  return 0;
}

constexpr int
fn4 ()
{
  std::byte foo;
  std::byte b = foo; // OK
  return 0;
}

constexpr int w1 = fn1 ();
constexpr int w2 = fn2 ();
constexpr int w3 = fn3 ();
constexpr int w4 = fn4 ();

DR 1787 says that if an indeterminate value is produced by an evaluation, the
behavior is undefined except in certain cases.  In fn1 and fn4 we issue errors
even for some of the "certain cases" (the lines marked with OK) and I think
it's a bug.  Uninitialized variables in a constexpr context are OK since C++20
P1331R2.