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?