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

Reply via email to