From patchwork Fri Aug 31 16:51:26 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Henderson X-Patchwork-Id: 181032 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id D1BA32C0385 for ; Sat, 1 Sep 2012 04:22:09 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1347042131; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=L8eFyrrLCOblh3qm/Wr7aw0XKy8=; b=R0y3oW2jk80SP1P pEfY1iNpuYthyvZKlLNCxvKDshrBBaaa3fnIYBqcWuPHuBv8xmOEJpnE9oqdVnWF Ty1TEunKR4XOW233qpDwRJn6zl2KCIRrqhM/JCkPj7QaosKJ3r/YUAk6aR0XweN4 GORfXKr1nyyW5SM/9wpbNbVaPmOM= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=vWlCvJAAyF+D/xBZXtpXPu4Q/M3epku3bugYuTYM4GzfsI47seZ4FvmRbyP/Wy GihjsE89wBx6xsPdai0FLYpSE13ub9uRQlSHFnrOcR9EsAZFrqtRfpsxMOQiJBsB pAV69nrHPwQJ9YyAxwwYmmcRSf2uttTgfleC9di0zd2Lw=; Received: (qmail 9188 invoked by alias); 31 Aug 2012 18:22:01 -0000 Received: (qmail 9178 invoked by uid 22791); 31 Aug 2012 18:22:00 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD, SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 31 Aug 2012 18:21:41 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q7VILViB013649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 31 Aug 2012 14:21:41 -0400 Received: from pebble.twiddle.home (vpn-9-3.rdu.redhat.com [10.11.9.3]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q7VGpLf5020281; Fri, 31 Aug 2012 12:51:22 -0400 Message-ID: <5040EB8E.6090403@redhat.com> Date: Fri, 31 Aug 2012 09:51:26 -0700 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: GCC Patches CC: Andrew MacLeod , Jeff Law , Vladimir Makarov Subject: Re: bug wrt gcc 4.7 and the C++11 memory model References: <1331644794.2986.10033.camel@triegel.csb> <7F6D7AF8-0FDE-4369-83AF-213C44FE95FE@inria.fr> <1343811659.20102.1056.camel@triegel.csb> <4F4828A3-0DA5-48! 51-B42D-94529F776152@inria.fr> <1343814602.20102.1078.camel@triegel.csb> <1DFF37FC-07FD-4162-8097-DB6D1F3C0E0D@inria.fr> <1344500459.20102.5644.camel@triegel.csb> <5023B15B.8000205@redhat.com> <1344535222.20102.5661.camel@triegel.csb> <50240C33.90909@redhat! .com> <50240DEA.1010703@redhat.com> <502571AB.1070804@redhat.com> <5027CB12.7020106@redhat.com> <50285E37.7030700@redhat.com> <5036721E.8040903@redhat.com> <503683F4.50700@redhat.com> <50368E95.2020708@redhat.com> <50378A96.5000106@redha! t.com> <50379E60.7080301@redh! at.com> <503FDB3E.7080900@redhat.com> <503FF052.5040402@redhat.com> <503FF18F.1090606@red! hat.com> <5040B28F.7040301@redhat.com> In-Reply-To: <5040B28F.7040301@redhat.com> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On 2012-08-31 05:48, Andrew MacLeod wrote: > On 08/30/2012 07:04 PM, Richard Henderson wrote: >> Actually, we already have a memory barrier feature in rtl: >> >> ALIAS_SET_MEMORY_BARRIER >> >> but since we already set that in get_builtin_sync_mem, we'll need >> to figure out why that's no longer working. >> >> As far as I can tell from reading alias.c, we should already be >> indicating that such memories alias... >> >> What was the testcase again? I seem to have lost the top of the thread... >> >> > > #include > using namespace std; > > atomic_uint a_8; > int32_t g_70; > int32_t g_141; > > int main (int, char *[]) { > a_8.load () & a_8.load (); > g_141 = g_70 != 0; > } > > or equivalently > > int a_8; > int g_70; > int g_141; > > int main () > { > __atomic_load_n (&a_8, __ATOMIC_SEQ_CST) & __atomic_load_n (&a_8, __ATOMIC_SEQ_CST); > g_141 = g_70 != 0; > } Fixed as follows. This seems to be the only entry point in alias.c that didn't take ALIAS_SET_MEMORY_BARRIER into account. Getting the above into a test case is tricky, and I havn't figured out how to match it. Full testing still underway, but I expect it to pass. r~ * alias.c (read_dependence): Account for ALIAS_SET_MEMORY_BARRIER. diff --git a/gcc/alias.c b/gcc/alias.c index e9d701f..5848e75 100644 --- a/gcc/alias.c +++ b/gcc/alias.c @@ -2132,7 +2132,12 @@ memrefs_conflict_p (int xsize, rtx x, int ysize, rtx y, HOST_WIDE_INT c) int read_dependence (const_rtx mem, const_rtx x) { - return MEM_VOLATILE_P (x) && MEM_VOLATILE_P (mem); + if (MEM_VOLATILE_P (x) && MEM_VOLATILE_P (mem)) + return true; + if (MEM_ALIAS_SET (x) == ALIAS_SET_MEMORY_BARRIER + || MEM_ALIAS_SET (mem) == ALIAS_SET_MEMORY_BARRIER) + return true; + return false; } /* Returns nonzero if something about the mode or address format MEM1