From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55714 invoked by alias); 23 Aug 2019 16:14:36 -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 55706 invoked by uid 89); 23 Aug 2019 16:14:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=*is*, everywhere X-HELO: esa1.mentor.iphmx.com Received: from esa1.mentor.iphmx.com (HELO esa1.mentor.iphmx.com) (68.232.129.153) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 Aug 2019 16:14:32 +0000 IronPort-SDR: ycECLODs1D1wmeP4UpgZLoiPnbQeUQsknoAQM2kbhmInhyEMVv8ZsttGCLXIUTZrRXbccnJLtO 9NI2z7K/nLAuj4Y50suwIkW1B1nxdNeROhSTA/wF4bN1iAQbgoP+LoBXDoErBAUq8qWy77DywT pT9vCtERY7VmAlEhp39VDpmMZvd+OGaj3I6J/HJPxr5QTMS5q4n/g5iaAoDUsMAs8E8xSYeo9J ANLag+PfqC9LhzpwYqX2fo6hpYoppYhzzqeV3I+3xw6Rsgnoc/LQLRW+c9RAW5P+0NwHtEwMjy CBI= Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 23 Aug 2019 08:14:30 -0800 IronPort-SDR: OWWo3CALZWx4jPNoj/s62LxhWpjEXnxXKs4ciiiP7EUGQIOd2alfNzquQf1ZdN37OStpK1cQlc INC6uFA3A1NV/0H34KxLFOJcnYTW6+GeHqcA0dKrAXIUs0GLx78thFbupdXLl95xpC+B9+hmTu tSBcRSnXZ8Zbw1sQEYM6+61zH+oGzbv52YqsxJDpiX1SejgrZNrcG6/rzSvZmtKRfQCkGA5gMJ LokAlWctk5m1fSdzMRyzKyshVFHTvVDRu9O+68HFHjBG7Nw7AeFQDc95tqgsmLpwPQAZo19G27 u7c= Date: Fri, 23 Aug 2019 16:14:00 -0000 From: Joseph Myers To: Iain Sandoe CC: Jonathan Wakely , Jim Wilson , GCC Development Subject: Re: gcc vs clang for non-power-2 atomic structures In-Reply-To: <1B1B7543-E830-43C6-B996-7FE51E4540E1@googlemail.com> Message-ID: References: <4B203FA6-1E0F-4DA2-B86E-D51A0105138E@googlemail.com> <1B1B7543-E830-43C6-B996-7FE51E4540E1@googlemail.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1152306461-1628965438-1566576865=:10989" Return-Path: joseph@codesourcery.com X-SW-Source: 2019-08/txt/msg00198.txt.bz2 ---1152306461-1628965438-1566576865=:10989 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Content-length: 1868 On Fri, 23 Aug 2019, Iain Sandoe wrote: > absolutely, it’s the psABI that’s lacking here - the compilers (as commented > by Richard Smith in a referenced thread) should not be making ABI up… With over 50 target architectures supported in GCC, most of which probably don't have anyone maintaining a psABI for them, you don't get support for new language features that require an ABI without making some reasonable default choice that allows the features to work everywhere and then letting architecture maintainers liaise with ABI maintainers in the case where such exist. (ABIs for atomics have the further tricky issue that there can be multiple choices for how to map the memory model onto a given architecture; see . So it's not just a matter of type sizes and alignment.) There *is* a clear GCC bug (bug 65146) in the specific case of _Atomic long long / _Atomic double in structures on 32-bit x86; those need to be forced to 8-byte alignment when atomic as they are outside structures. Size / alignment for _Atomic versions of types whose size isn't (2, 4, 8, 16) bytes is another matter; the GCC default (don't change size / alignment when making atomic) seems perfectly reasonable, but where psABIs specify something we do of course need to follow it (and the choice may be OS-specific, not just processor-specific, where the ABI is defined by the default compiler for some OS). Note: it's likely some front-end code, and stdatomic.h, might have to change to handle the possibility of atomic types being larger than non-atomic, as those end up using type-generic atomic load / store built-in functions, and those certainly expect pointers to arguments of the same size (when one argument is the atomic type and one non-atomic). -- Joseph S. Myers joseph@codesourcery.com ---1152306461-1628965438-1566576865=:10989--