[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]

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.

> 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).