From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4190 invoked by alias); 17 Jan 2012 10:19:55 -0000 Received: (qmail 4177 invoked by uid 22791); 17 Jan 2012 10:19:53 -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:19:07 +0000 From: "rakdver at gcc dot gnu.org" 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 10:40: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: rakdver at gcc dot gnu.org 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/msg01873.txt.bz2 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. > 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).