From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7397 invoked by alias); 17 Jan 2012 10:49:04 -0000 Received: (qmail 7387 invoked by uid 22791); 17 Jan 2012 10:49:03 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_KD X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Jan 2012 10:48:16 +0000 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/39612] [4.4/4.5/4.6/4.7 Regression] LIM inserts loads from uninitialized local memory Date: Tue, 17 Jan 2012 11:03:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.4.7 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-01/txt/msg01877.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612 --- Comment #16 from 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 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.