From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88609 invoked by alias); 24 Jan 2017 21:30:34 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 88483 invoked by uid 89); 24 Jan 2017 21:30:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:9892f3c, H*f:sk:9892f3c X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Jan 2017 21:30:23 +0000 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0OLJw9B008361 for ; Tue, 24 Jan 2017 16:30:21 -0500 Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by mx0a-001b2d01.pphosted.com with ESMTP id 286aq4j7hj-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 24 Jan 2017 16:30:21 -0500 Received: from localhost by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 24 Jan 2017 14:30:20 -0700 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 24 Jan 2017 14:30:19 -0700 Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id EAF0719D8047; Tue, 24 Jan 2017 14:29:33 -0700 (MST) Received: from b03ledav006.gho.boulder.ibm.com (b03ledav006.gho.boulder.ibm.com [9.17.130.237]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v0OLUIET10813826; Tue, 24 Jan 2017 14:30:18 -0700 Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 72BBCC6047; Tue, 24 Jan 2017 14:30:18 -0700 (MST) Received: from otta.rchland.ibm.com (unknown [9.10.86.64]) by b03ledav006.gho.boulder.ibm.com (Postfix) with ESMTP id 37C3FC604C; Tue, 24 Jan 2017 14:30:18 -0700 (MST) Subject: Re: -mcx16 vs. not using CAS for atomic loads To: Richard Henderson , Torvald Riegel References: <1484850210.5606.587.camel@redhat.com> <1485248932.4311.96.camel@redhat.com> <9892f3cf-3b6e-e280-d243-f3c36f685d42@redhat.com> Cc: GCC , Bin Fan From: Peter Bergner Date: Tue, 24 Jan 2017 21:30:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <9892f3cf-3b6e-e280-d243-f3c36f685d42@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17012421-0016-0000-0000-000005F66768 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006492; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000200; SDB=6.00812174; UDB=6.00396060; IPR=6.00589591; BA=6.00005085; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014031; XFM=3.00000011; UTC=2017-01-24 21:30:20 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17012421-0017-0000-0000-000036C797D9 Message-Id: <8e49371d-36eb-7cae-355b-849c94de4302@vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-01-24_17:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701240129 X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00220.txt.bz2 On 1/24/17 3:06 PM, Richard Henderson wrote: > The only possible concern I see might be with simulators that force HTM > failure, for the purpose of forcibly testing fallback paths. I guess we'd have > to continue to fall back to the lock path for that case. IIRC, this was the path that valgrind was going to use all of the time, because actually implementing the HTM instructions was too hard. Peter