From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38351 invoked by alias); 22 Dec 2016 14:29:08 -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 38337 invoked by uid 89); 22 Dec 2016 14:29:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_05,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=V207, interoperate, lpq, weigand 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; Thu, 22 Dec 2016 14:29:05 +0000 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uBMENiGe027306 for ; Thu, 22 Dec 2016 09:29:04 -0500 Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108]) by mx0a-001b2d01.pphosted.com with ESMTP id 27gbaj5ys8-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 22 Dec 2016 09:29:04 -0500 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 22 Dec 2016 14:29:01 -0000 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 22 Dec 2016 14:28:57 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 37C0D17D8056; Thu, 22 Dec 2016 14:31:38 +0000 (GMT) Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id uBMESvg42425320; Thu, 22 Dec 2016 14:28:57 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 43DBD52045; Thu, 22 Dec 2016 13:27:33 +0000 (GMT) Received: from oc8523832656.ibm.com (unknown [9.152.213.198]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id 337975203F; Thu, 22 Dec 2016 13:27:33 +0000 (GMT) Received: by oc8523832656.ibm.com (Postfix, from userid 500) id C5B931032A2; Thu, 22 Dec 2016 15:28:56 +0100 (CET) Subject: Re: GCC libatomic ABI specification draft To: szabolcs.nagy@arm.com (Szabolcs Nagy) Date: Thu, 22 Dec 2016 14:29:00 -0000 From: "Ulrich Weigand" Cc: triegel@redhat.com (Torvald Riegel), nd@arm.com, paubert@iram.es (Gabriel Paubert), bin.x.fan@oracle.com (Bin Fan@Work), gcc@gcc.gnu.org (gcc@gcc.gnu.org), Andreas.Krebbel@de.ibm.com, dje.gcc@gmail.com, segher@kernel.crashing.org In-Reply-To: <58593903.4020508@arm.com> from "Szabolcs Nagy" at Dec 20, 2016 01:58:27 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16122214-0008-0000-0000-000003C3F5EA X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16122214-0009-0000-0000-00001BE06B9B Message-Id: <20161222142856.C5B931032A2@oc8523832656.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-12-22_11:,, 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-1612220241 X-SW-Source: 2016-12/txt/msg00136.txt.bz2 Szabolcs Nagy wrote: > On 20/12/16 13:26, Ulrich Weigand wrote: > > I may have missed the context of the discussion, but just on the > > specific ISA question here: both Power and z not only have the > > 16-byte CAS (or load-and-reserve/store-conditional), but they also both > > have specific 16-byte atomic load and store instructions (lpq/stpq > > on z, lq/stq on Power). > > > > Those are available on any system supporting z/Architecture (z900 and up), > > and on any Power system supporting the V2.07 ISA (POWER8 and up). GCC > > does in fact use those instructions to implement atomic operations on > > 16-byte data types on those machines. > > that's a bug. > > at least i don't see how gcc makes sure the libatomic > calls can interoperate with inlined atomics. Hmm, interesting. On z, there is no issue with ISA levels, since *all* 64-bit platforms support the 16-byte atomics (and on non-64-bit platforms, 16-byte data types are not supported at all). However, there still seems to be a problem, but this time related to alignment issues. We do have the 16-byte atomic instructions, but they only work on 16-byte aligned data. This is a problem in particular since the default alignment of 16-byte data types is still 8 bytes on our platform (since the ABI only guarantees 8-byte stack alignment). That's why the libatomic configure check thinks it cannot use the atomic instructions when building on z, and generates code that uses the separate lock. However, *if* a particular object can be proven by the compiler to be 16-byte aligned, it will emit the inline atomic instruction. This means there is indeed a bug if that same object is also operated on via the library routine. Andreas suggested that the best way to fix this would be to add a runtime alignment check to the libatomic routines and also use the atomic instructions in the library whenever the object actually happens to be correctly aligned. It seems that this should indeed fix the problem (and also use the most efficient way in all cases). Not sure about Power -- adding David and Segher on CC ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com