Re: Functions that are CSEable but not pure

[Jason Merrill <jason at redhat dot com>]

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