[Bug tree-optimization/39612] [4.4/4.5/4.6/4.7 Regression] LIM inserts loads from uninitialized local memory

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

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

--- Comment #17 from Zdenek Dvorak <rakdver at gcc dot gnu.org> 2012-01-17 11:01:45 UTC ---
> > LSM will move inter[1] to a temporary variable regardless of the locks, which
> > will cause race conditions with other threads (and whether loop header is
> > copied or not is irrelevant).
> 
> I think for the explicit lock code we are safe because we consider
> the lock/unlock calls to alias inter[] so we cannot SM it.  

This is not necessary to be the case, if you for some reason implement your own
version of locking (and especially if lock/unlock get inlined).  Still, this
probably would not happen in practice.

> In the
> light of the C++11 memory model we probably have to do something
> about even non-volatile accesses.
> 
> I suppose we cannot easily detect at the moment if the loop has
> its header copied, thus, is do {} while style?  We're using
> ref_always_accessed_p for the trapping insns issue, we could
> extend that to cover all global memory accesses - but I suppose
> that would pessimize things if ref_always_accessed_p isn't
> very good.

Having header copied or not is actually irrelevant for the problem in question.
 You will get the same thing in

do
  {
    if (maybe)
      inter[1] = bla;
  }
while (something);

So, extending the use of ref_always_accessed_p would be the thing you want to
do; probably not by default, since this only affects badly written (no
volatile) multithreaded programs, but having that option could be useful
(of course, this should be on by default for c++, if it is the required
behavior).