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.
