[Bug middle-end/51752] trans-mem: publication safety violated

["rth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51752

--- Comment #5 from Richard Henderson <rth at gcc dot gnu.org> 2012-02-09 17:39:51 UTC ---
(In reply to comment #4)
> But isn't with
> 
>   __transaction_atomic
>     {
>       for (i = 0; i < 10; i++)
>         if (x[i])
>           x[i] += data;
>     }
> 
> and
> 
>   __transaction_atomic { x[9] = 1; }
> 
> occuring concurrently the loop transaction terminated?

The problem we want to fix is not wrt x[], but data.

Consider x[0..10] == 0, and another thread with

  while (1)
    __transaction_atomic { data += 1; }

If we hoist data in the first transaction, then we're very
likely to restart the transaction based on stale contents
of data, even when we ought not have touched data at all.

I.e. we can wind up looping even when we ought to be making
forward progress.

> We don't hoist out of the transaction region (well, as far
> as I can see - the transaction region seems to be specified in a very
> weak way, without virtual operands or any IL barrier or such).

It was supposed to have virtual operands.  It really did at one
time, but that seems to have gotten lost.  I noticed this with
another PR a week or so ago, but havn't gotten around to fixing it.