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) Honza
