From: Joseph Myers <joseph@codesourcery.com>
To: Iain Sandoe <idsandoe@googlemail.com>
Cc: Jonathan Wakely <jwakely.gcc@gmail.com>,
Jim Wilson <jimw@sifive.com>, GCC Development <gcc@gcc.gnu.org>
Subject: Re: gcc vs clang for non-power-2 atomic structures
Date: Fri, 23 Aug 2019 16:14:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.21.1908231558130.10989@digraph.polyomino.org.uk> (raw)
In-Reply-To: <1B1B7543-E830-43C6-B996-7FE51E4540E1@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]
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
<https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html>. 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
next prev parent reply other threads:[~2019-08-23 16:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-22 23:56 Jim Wilson
2019-08-23 7:21 ` Iain Sandoe
2019-08-23 9:36 ` Jonathan Wakely
2019-08-23 10:13 ` Iain Sandoe
2019-08-23 11:17 ` Jonathan Wakely
2019-08-23 16:14 ` Joseph Myers [this message]
2019-08-23 18:49 ` Jim Wilson
2019-08-23 18:59 ` Iain Sandoe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.1908231558130.10989@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=gcc@gcc.gnu.org \
--cc=idsandoe@googlemail.com \
--cc=jimw@sifive.com \
--cc=jwakely.gcc@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).