https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108702
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|ipa |c++
Priority|P3 |P1
CC| |jason at gcc dot gnu.org
Target Milestone|--- |13.0
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems the reason why the above testcase works and stmtexpr19.C doesn't is in
make_rtl_for_nonlocal_decl's
7732 /* We defer emission of local statics until the corresponding
7733 DECL_EXPR is expanded. But with constexpr its function might
never
7734 be expanded, so go ahead and tell cgraph about the variable now.
*/
7735 defer_p = ((DECL_FUNCTION_SCOPE_P (decl)
7736 && !var_in_maybe_constexpr_fn (decl))
7737 || DECL_VIRTUAL_P (decl));
while in stmtexpr19.C the inner decl isn't in constexpr fn, it is in a
statement expression inside of a static variable initializer.
The initializer evaluates to constant expression (ADDR_EXPR of inner), so the
statement expression disappears and so there is no DECL_EXPR for the inner var
nor any reasonable spot to stick it to.
I think the options are somehow discover these before they are folded away and
mark them some way, so that we don't defer_p them or otherwise arrange for
rest_of_decl_compilation to be done on them later, or, as statement expressions
are a GNU extension, simply declare that such variables in statement
expressions cause it to be not a constant expression, only DECL_EXPRs of
var_in_maybe_constexpr_fn (decl) would be accepted.
Or, do we ever need to defer_p the static variables we are talking about here
(i.e. constexpr ones or ones with constant initializers, for which it really
doesn't matter where exactly we initialize them because they are initialized in
.rodata already.
