From: Uros Bizjak <ubizjak@gmail.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
Andrew MacLeod <amacleod@redhat.com>,
Mike Stump <mikestump@comcast.net>,
stanshebs@earthlink.net, Jason Merrill <jason@redhat.com>,
Richard Henderson <rth@redhat.com>, "jh@suse.cz" <jh@suse.cz>,
Jakub Jelinek <jakub@redhat.com>
Subject: Re: Implement C11 _Atomic
Date: Thu, 07 Nov 2013 17:16:00 -0000 [thread overview]
Message-ID: <CAFULd4aL9dR=tRXs17CaKK=Jxb=f5KSo1kt9VdHcWZx1dLV3sg@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1311052316480.30260@digraph.polyomino.org.uk>
On Wed, Nov 6, 2013 at 12:21 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> This patch, relative to trunk and based on work done on the C11-atomic
> branch, adds support for C11 _Atomic. It is intended to include all
> the required language support.
>
> It does not include the <stdatomic.h> header; there's a version on the
> branch, but it needs further review against the standard and test
> coverage adding to the testsuite before I can propose it for mainline.
>
> Support for atomic types having bigger alignment than the
> corresponding non-atomic types is limited: it includes the code to
> increase the alignment of types whose size is exactly 1, 2, 4, 8 or 16
> to that of the corresponding integer type [*], but not anything for
> target-specific alignment increases. There's code for target-specific
> alignment on the branch (and I intend to merge trunk back to the
> branch once this patch is on trunk, so it's easy to tell what the
> changes still left on the branch are), should any target maintainers
> wish to have such alignment. Note however that ideally libstdc++
> atomics would be ABI-compatible with C atomics, requiring them to get
> the same alignment; the branch has an "atomic" attribute for that
> purpose, but I think further work on the C++ front-end changes would
> be needed for them to be ready for mainline.
>
> [*] The c-common.c code to resolve size-generic atomic built-in
> functions to size-specific ones assumes that types are naturally
> aligned (and so resolves to calls to the size-specific functions that
> require natural alignment) without checking it. If users should be
> able to use the size-generic functions on types with lesser alignment,
> e.g. _Complex double (8-byte rather than 16-byte aligned), rather than
> just on their _Atomic variants, this is of course a bug in the code
> resolving those built-in functions. (The libatomic functions properly
> check for alignment at runtime.) But it seems reasonable enough
> anyway to make _Atomic _Complex double 16-byte aligned.
>
> Full use of _Atomic requires linking with libatomic, if you're doing
> any atomic operations that aren't fully expanded inline; arguably
> libatomic should be linked in by default with --as-needed (given that
> previously ordinary C code didn't require the user to link any
> libraries explicitly unless they directly called library functions),
> but that's independent of this patch. Correct handling of atomic
> compound assignment for floating-point types also requires built-in
> support for floating-point environment manipulation operations roughly
> equivalent to feholdexcept, feclearexcept and feupdateenv (built-ins
> are used to avoid introducing libm dependencies, which generic C code
> not actually calling libm library functions shouldn't require); this
> patch includes such support for x86 [*], and I expect other
> architectures to be simpler. If you don't have a libatomic port, the
> execution tests for _Atomic simply won't be run; if you have libatomic
> but not the floating-point support, the tests will be run but
> c11-atomic-exec-5.c will fail (assuming the library features are
> present for that test to run at all - it also requires pthreads).
>
> [*] This could be optimized if desired by passing the types in
> question to the target hook so it can generate code for only one of
> x87 and SSE in most cases, much like an optimization present in glibc
> when it internally does feholdexcept / fesetenv / feupdateenv
> sequences.
>
> _Atomic support is currently disabled for Objective-C and OpenMP. For
> both (but mainly OpenMP), the relevant parser code needs checking to
> determine where convert_lvalue_to_rvalue calls need inserting to
> ensure that accesses to atomic variables involve atomic loads. For
> Objective-C, there are also various special cases of compound
> assignment that need special handling for atomics just as standard C
> compound assignment is handled differently for atomics, as well as
> some TYPE_MAIN_VARIANT calls to check for correctness for atomics; see
> the comment on the relevant sorry () call for details. OpenMP should
> also have TYPE_MAIN_VARIANT uses checked as well as a use of
> TYPE_QUALS_NO_ADDR_SPACE for a diagnostic in
> c_parser_omp_declare_reduction (where the diagnostic refers to a
> particular list of qualifiers).
>
> Bootstrapped with no regressions on x86_64-unknown-linux-gnu. OK to
> commit (the various non-front-end pieces)?
>
> gcc:
> 2013-11-05 Andrew MacLeod <amacleod@redhat.com>
> Joseph Myers <joseph@codesourcery.com>
>
> * tree-core.h (enum cv_qualifier): Add TYPE_QUAL_ATOMIC.
> (enum tree_index): Add TI_ATOMICQI_TYPE, TI_ATOMICHI_TYPE,
> TI_ATOMICSI_TYPE, TI_ATOMICDI_TYPE and TI_ATOMICTI_TYPE.
> (struct tree_base): Add atomic_flag field.
> * tree.h (TYPE_ATOMIC): New accessor macro.
> (TYPE_QUALS, TYPE_QUALS_NO_ADDR_SPACE): Add TYPE_QUAL_ATOMIC.
> (TYPE_QUALS_NO_ADDR_SPACE_NO_ATOMIC): New macro.
> (atomicQI_type_node, atomicHI_type_node, atomicSI_type_node)
> (atomicDI_type_node, atomicTI_type_node): New macros for type
> nodes.
> * tree.c (set_type_quals): Set TYPE_ATOMIC.
> (find_atomic_core_type): New function.
> (build_qualified_type): Adjust alignment for qualified types.
> (build_atomic_base): New function
> (build_common_tree_nodes): Build atomicQI_type_node,
> atomicHI_type_node, atomicSI_type_node, atomicDI_type_node and
> atomicTI_type_node.
> * print-tree.c (print_node): Print atomic qualifier.
> * tree-pretty-print.c (dump_generic_node): Print atomic type
> attribute.
> * target.def (atomic_assign_expand_fenv): New hook.
> * doc/tm.texi.in (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New @hook.
> * doc/tm.texi: Regenerate.
> * targhooks.c (default_atomic_assign_expand_fenv): New function.
> * targhooks.h (default_atomic_assign_expand_fenv): Declare.
> * sync-builtins.def (__atomic_feraiseexcept): New built-in
> function.
> * config/i386/i386-builtin-types.def (VOID_FTYPE_PUSHORT): New
> function type.
> * config/i386/i386.c (enum ix86_builtins): Add
> IX86_BUILTIN_FNSTENV, IX86_BUILTIN_FLDENV, IX86_BUILTIN_FNSTSW and
> IX86_BUILTIN_FNCLEX.
> (bdesc_special_args): Add __builtin_ia32_fnstenv,
> __builtin_ia32_fldenv, __builtin_ia32_fnstsw and
> __builtin_ia32_fnclex.
> (ix86_expand_builtin): Handle the new built-in functions.
> (ix86_atomic_assign_expand_fenv): New function.
> (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New macro.
> * config/i386/i386.md (UNSPECV_FNSTENV, UNSPECV_FLDENV)
> (UNSPECV_FNSTSW, UNSPECV_FNCLEX): New unspecs.
> (fnstenv, fldenv, fnstsw, fnclex): New insns.
The x86 part of the patch is OK.
Uros.
next prev parent reply other threads:[~2013-11-07 16:40 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-06 0:44 Joseph S. Myers
2013-11-06 22:42 ` Andrew MacLeod
2013-11-07 17:16 ` Uros Bizjak [this message]
2013-11-07 17:24 ` Jakub Jelinek
2013-11-07 18:10 ` Uros Bizjak
2013-11-07 18:44 ` Joseph S. Myers
2013-11-07 18:47 ` Uros Bizjak
2013-11-07 18:55 ` Joseph S. Myers
[not found] ` <CAFULd4ZrAEECG+pptH8cRaWznioaM9VXS4TetpEvkWj--n7H1w@mail.gmail.com>
2013-11-07 21:02 ` Joseph S. Myers
2013-11-07 21:08 ` Uros Bizjak
2013-11-07 22:25 ` Uros Bizjak
2013-11-07 22:43 ` Joseph S. Myers
2013-11-08 10:09 ` Uros Bizjak
2013-11-08 13:33 ` Joseph S. Myers
2013-11-21 13:19 ` Hans-Peter Nilsson
2013-11-21 18:03 ` Andrew MacLeod
2013-11-21 18:20 ` Hans-Peter Nilsson
2013-11-21 18:30 ` Andrew MacLeod
2013-11-21 18:49 ` Joseph S. Myers
2013-11-21 18:58 ` Andrew MacLeod
2013-11-21 19:24 ` Hans-Peter Nilsson
2013-11-22 2:57 ` Hans-Peter Nilsson
2013-11-22 3:03 ` Andrew MacLeod
2013-11-22 3:32 ` Hans-Peter Nilsson
2013-11-22 3:32 ` Joseph S. Myers
2013-11-22 19:12 ` Andrew MacLeod
2013-11-22 20:01 ` Hans-Peter Nilsson
2013-11-08 13:28 Dominique Dhumieres
2013-11-08 13:34 ` Joseph S. Myers
2013-11-08 13:43 ` Dominique Dhumieres
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='CAFULd4aL9dR=tRXs17CaKK=Jxb=f5KSo1kt9VdHcWZx1dLV3sg@mail.gmail.com' \
--to=ubizjak@gmail.com \
--cc=amacleod@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=jason@redhat.com \
--cc=jh@suse.cz \
--cc=joseph@codesourcery.com \
--cc=mikestump@comcast.net \
--cc=rth@redhat.com \
--cc=stanshebs@earthlink.net \
/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).