On 10/05/2012 04:46 AM, Richard Guenther wrote:
Ok, so then let me make another example to try breaking a valid program with the thread_local wrapper being pure:
There is also my example earlier in the thread.
i; if (init_count != 1) __builtin_abort (); is that valid?
I believe so; that is an odr-use of i, so it needs to be initialized.
Thus my question is - is a valid program allowed to access side-effects of the dynamic TLS initializer by not going through the TLS variable?
I think so.
Preventing DCE but not CSE for const/pure functions can be for example done by using the looping-const-or-pure flag (but that also tells the compiler that this function may not return, so it is very specific about the kind of possible side-effect to be preserved). The very specific nature of thread_local TLS init semantics ('somewhen before') is hard to make use of, so if we want to change looping-const-or-pure to something like const-or-pure-with-side-effects we should constrain things more.
That would be fine with me. Jason