http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
--- Comment #16 from rguenther at suse dot de <rguenther at suse dot de> 2012-01-17 10:40:31 UTC --- On Tue, 17 Jan 2012, rakdver at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612 > > --- Comment #14 from Zdenek Dvorak <rakdver at gcc dot gnu.org> 2012-01-17 > 10:19:01 UTC --- > > > Also, the warning is at least morally right. If R <= 1, the original > > > code will > > > pass inter to foo uninitialized, which probably is not intended. So, the > > > right > > > thing to do could be issuing "may be used uninitialized" warning instead > > > of "is > > > used uninitialized" one. > > > > Yes, but the point is that without the loop header copy we insert the > > loads and stores from/to inter in a path that is executed even when > > R <= 1 and thus the loop is not executed at all, and we warn about > > the inserted loads - not about the final one. Modified testcase: > > I realize that; making the warning to point to the right line would be > somewhat > difficult, I guess. Yeah. > > For the store data-race consider > > > > int inter[3]; > > void > > f2 (int R) > > { > > int i; > > > > for (i = 1; i < R; i++) > > { > > inter[0] = 1; > > inter[1] = 1; > > inter[2] = 1; > > } > > } > > > > where inter is protected by a mutex, but only if R > 1. We still > > insert loads/stores on paths that are executed when the loop is not > > entered: > > Which is to be expected, as long as inter is not volatile. Store motion (and > cse, ...) will cause this kind of problems, this does not seem to be anything > specific to the testcase in question. If you have something like > > for (i = 1; i < R; i++) > { > lock (); > do something with inter[1] > unlock (); > } > > 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. 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.
