https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88677
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 7 Jan 2019, hubicka at ucw dot cz wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88677 > > --- Comment #9 from Jan Hubicka <hubicka at ucw dot cz> --- > > https://gcc.gnu > > -> You can't simply remove this flag. You could set it to true > > conservatively. > > Or we could stop marking globals that need constructing TREE_READONLY. > > I see, I was under impression that we already drop TREE_READONLY for > them. But it is bit more subtle and thus I was indeed to quick to drop > streaming here. In: > > struct c { int a; c() { a=1; } }; > const c cc; > const int dd=1; > extern const c ee; > int foo() { return ee.a; } > > I get: > const c ee/8 (const c ee) @0x7f68d301ee80 > Type: variable > Visibility: external public > References: > Referring: _Z3foov/5 (read) > Availability: not-ready > Varpool flags: read-only > const int dd/4 (const int dd) @0x7f68d301ec80 > Type: variable definition analyzed > Visibility: force_output no_reorder > Aux: @0x7f68d316c450 > References: > Referring: > Availability: not-ready > Varpool flags: initialized read-only const-value-known > const c cc/3 (const c cc) @0x7f68d301e900 > Type: variable definition analyzed > Visibility: force_output no_reorder > Aux: @0x7f68d301ec80 > References: > Referring: _Z41__static_initialization_and_destruction_0ii/6 (addr) > Availability: not-ready > Varpool flags: > > So EE is indeed read-only, but CC is not. > I guess it is because constructor to CC is output locally and we clear > the flag, while constructor of EE is output externally. What is utility > of this information? Can we realy in some context that value of EE did > not change? > > It seems to me that it is completely useless info, so I would be in > favor of dropping TREE_READONLY flag probably at cgraph > construction time (because I suppose it is relevant to front-end) I guess the FE needs the info. But yes, dropping TREE_READONLY for TYPE_NEEDS_CONSTRUCTION decls at some point may make sense. Generally it would be nice to know (for alias analysis) that an object is not written to via a pointer. For const globals with a constructor such writes can only happen inside the global ctor function(s). Not sure if IPA reference could be of help here, it is really language stuff. There's also const_cast and mutable where things get into murky territorry...
