c++: constant non-copy-init is manifestly constant [PR108243]
commitcbaa1d9c218d9c0b5e34e510a462ff4e299a0f3f
authorPatrick Palka <ppalka@redhat.com>
Thu, 2 Mar 2023 19:03:21 +0000 (2 14:03 -0500)
committerPatrick Palka <ppalka@redhat.com>
Thu, 2 Mar 2023 19:03:21 +0000 (2 14:03 -0500)
treefdea0865f0d6bb42ef6b39e6c06d943f9064fd32
parent20bd258d0fa09837b3a93478ef92d8789cbcd442
c++: constant non-copy-init is manifestly constant [PR108243]

According to [basic.start.static]/2 and [expr.const]/2, a variable
with static storage duration initialized with a constant initializer
has constant initialization, and such an initializer is manifestly
constant-evaluated.

For copy initialization, we're already getting this right because in
that case check_initializer would consistently call store_init_value,
which for TREE_STATIC variables calls fold_non_dependent_init with
m_c_e=true.

But for direct (or default) initialization, check_initializer doesn't
always call store_init_value.  We instead however always call
maybe_constant_init from expand_default_init[1], albeit with m_c_e=false
which means we don't get the "manifestly constant-evaluated" part right
for non-copy-init.

This patch fixes this by setting m_c_e=true in maybe_constant_init for
static storage duration variables, mainly for benefit of the call
to maybe_constant_init from expand_default_init.

[1]: this maybe_constant_init call isn't reached in the copy-init
case because there init is a CONSTRUCTOR rather than a TREE_LIST,
and so we exit early from expand_default_init, returning an INIT_EXPR.
This INIT_EXPR is ultimately what causes us to consistently hit the
store_init_value code path from check_initializer in the copy-init case.

PR c++/108243

gcc/cp/ChangeLog:

* constexpr.cc (maybe_constant_init_1): Override
manifestly_const_eval to true if is_static.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/is-constant-evaluated14.C: New test.
gcc/cp/constexpr.cc
gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated14.C [new file with mode: 0644]