public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/51766] [4.7 regression] sync_fetch_and_xxx atomicity Date: Tue, 10 Jan 2012 19:14:00 -0000 [thread overview] Message-ID: <bug-51766-4-21MyQEsMZY@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-51766-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766 Andrew Macleod <amacleod at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amacleod at redhat dot com --- Comment #13 from Andrew Macleod <amacleod at redhat dot com> 2012-01-10 19:13:44 UTC --- I don't think it matters what the original rationale was for implementing __sync. They are documented as being seq-cst. I would argue that power implementing them not as seq-cst is not truly compliant. It shouldn't be too difficult to write a test case using __sync which expects seq-cst as documented that would pass on all targets except power. It may be that power-specific programmers have been taking advantage of this, but doesn't it has to have the potential to break generic code?... (lucky TM only needed relaxed atomics!) That said... it would be possible to simply have an optional macro with a default definition of #define __SYNC_LEGACY_MODE MEMMODEL_SEQ_CST and if a port like power wants something different, it can define #define __SYNC_LEGACY_MODE MEMMODEL_ACQ_REL then use that value instead of MEMMODEL_SEQ_CST for legacy __sync routines. Would that satisfy all your requirements? shouldn't really need any other changes then. Although as Jakub says, it should then be clearly documented.
next prev parent reply other threads:[~2012-01-10 19:14 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-01-05 15:01 [Bug middle-end/51766] New: " dje at gcc dot gnu.org 2012-01-05 15:02 ` [Bug middle-end/51766] " dje at gcc dot gnu.org 2012-01-09 15:40 ` rguenth at gcc dot gnu.org 2012-01-09 15:45 ` redi at gcc dot gnu.org 2012-01-09 16:51 ` dje at gcc dot gnu.org 2012-01-10 9:43 ` rguenth at gcc dot gnu.org 2012-01-10 14:40 ` dje at gcc dot gnu.org 2012-01-10 14:49 ` rguenth at gcc dot gnu.org 2012-01-10 15:31 ` redi at gcc dot gnu.org 2012-01-10 18:09 ` dje at gcc dot gnu.org 2012-01-10 18:20 ` redi at gcc dot gnu.org 2012-01-10 18:24 ` redi at gcc dot gnu.org 2012-01-10 18:34 ` dje at gcc dot gnu.org 2012-01-10 18:47 ` jakub at gcc dot gnu.org 2012-01-10 19:14 ` amacleod at redhat dot com [this message] 2012-01-10 20:26 ` dje at gcc dot gnu.org 2012-01-12 20:41 ` dje at gcc dot gnu.org
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=bug-51766-4-21MyQEsMZY@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /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: linkBe 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).