From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31611 invoked by alias); 13 Jan 2015 15:20:37 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 30413 invoked by uid 89); 13 Jan 2015 15:20:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 13 Jan 2015 15:20:24 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0DFKLNH032757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 13 Jan 2015 10:20:21 -0500 Received: from [10.36.6.253] (vpn1-6-253.ams2.redhat.com [10.36.6.253]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0DFKIC2019019; Tue, 13 Jan 2015 10:20:19 -0500 Subject: Re: [PATCH] PR59448 - Promote consume to acquire From: Torvald Riegel To: Andrew MacLeod Cc: gcc-patches , Richard Biener , Jeff Law , "Joseph S. Myers" , filter-gcc@preshing.com In-Reply-To: <54B53203.6030304@redhat.com> References: <54B53203.6030304@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 13 Jan 2015 15:20:00 -0000 Message-ID: <1421162418.23151.49.camel@triegel.csb> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00883.txt.bz2 On Tue, 2015-01-13 at 09:56 -0500, Andrew MacLeod wrote: > The problem with the patch in the PR is the memory model is immediately > promoted from consume to acquire. This happens *before* any of the > memmodel checks are made. If a consume is illegally specified (such as > in a compare_exchange), it gets promoted to acquire and the compiler > doesn't report the error because it never sees the consume. The only issue I can think of in compare_exchange is if the program specifies memory_order_consume for the success path but memory_order_acquire for the failure path, which is disallowed by the standard. However, I don't see a reason why the standard's requirement is anything but a performance check in our particular case. The only case we prevent the compiler from reporting is a consume-on-success / acquire-on-failure combination. But we upgrade the former to acquire, so we can't even cause libatomic (or similar) to issue too weak barriers due to libatomic relying on the standard's requirement. Thus, if there's no easy way to upgrade to acquire after the sanity checks, I think this isn't critical enough to hold up the patch from being committed. memory_order_consume is clearly a feature for experts.