From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12039 invoked by alias); 17 Jan 2012 11:03:42 -0000 Received: (qmail 12030 invoked by uid 22791); 17 Jan 2012 11:03:40 -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 11:02:53 +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 11:08: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/msg01879.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612 --- Comment #17 from Zdenek Dvorak 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).