From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1531 invoked by alias); 29 Oct 2011 15:09:24 -0000 Received: (qmail 1515 invoked by uid 22791); 29 Oct 2011 15:09:22 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,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; Sat, 29 Oct 2011 15:09:08 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9TF98mn024669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 29 Oct 2011 11:09:08 -0400 Received: from [10.11.10.48] (vpn-10-48.rdu.redhat.com [10.11.10.48]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p9TF97MJ010425; Sat, 29 Oct 2011 11:09:07 -0400 Message-ID: <4EAC1712.3080905@redhat.com> Date: Sat, 29 Oct 2011 17:28:00 -0000 From: Andrew MacLeod User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc13 Thunderbird/3.1.10 MIME-Version: 1.0 To: Richard Henderson CC: gcc-patches@gcc.gnu.org, jakub@redhat.com Subject: Re: [cxx-mem-model][PATCH 0/9] Convert i386 to new atomic optabs. References: <1319774858-9181-1-git-send-email-rth@redhat.com> In-Reply-To: <1319774858-9181-1-git-send-email-rth@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2011-10/txt/msg02759.txt.bz2 On 10/28/2011 12:07 AM, Richard Henderson wrote: > This exposed a wealth of problems in code that has heretofore never > been tested. The fourth patch makes certain that all expansions of > compare-and-swap go through a single routine. > > I've tested the whole series with and without the last patch. So > that I've tested both the sync_ and atomic_ paths. I've not attempted > to test if both are present. I rather assume that'll never be the > case for any target. Excellent. The code is written to always check first for the new atomic patterns, and use them if present. If it works with either one present, it should be fine with both, should it ever happen... but we can leave that until some person actually decides that needs to happen :-) Thanks for exercising and fixing that untested code path. now other targets should be easier to convert too. Andrew