[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #8)
> But I'm worried about larger TUs where not all dynamic initialization can be
> optimized into constants.  E.g. if there remain any function calls where the
> alias analysis could think they can read or modify the vars or their
> subobjects etc., we'd need to punt.

Would we?  If the variable isn't const, it's OK for later initializers to
modify its value, I wouldn't think that would prevent us from turning its
initializer into a constant value.

> Perhaps we could when generating these functions wrap the dynamic
> initialization of each var by calls into some new IFN that would take
> address of the variable and for alias analysis say it reads it but doesn't
> modify and doesn't escape the address.  In C++ one can't read the var in
> other initializers until it has been constructed, right?  So the opening IFN
> would stand as the first stmt that may read or write the variable and
> similarly everything after the closing IFN would be considered unrelated
> code to that.

This seems like a more general issue: after a variable declared const has
completed its initialization, it can't be modified.  Would this be useful to
mark, kind of like we use a clobber for end of life?

> Not sure if we can reliably detect that the variable was declared read-only
> and isn't TREE_READONLY only because it has dynamic initialization (and that
> it is safe to optimize it into a .rodata var).

Can't you just look at the type?