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 target/65697] __atomic memory barriers not strong enough for __sync builtins Date: Thu, 09 Apr 2015 11:51:00 -0000 [thread overview] Message-ID: <bug-65697-4-xEi9R0wpEC@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-65697-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 --- Comment #10 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Matthew Wahab from comment #7) > (In reply to torvald from comment #5) > > (In reply to Matthew Wahab from comment #0) > > > > I don't think that's a precise characterization. The difference discussed > > in that thread is that seq-cst fences have a stronger effect than seq-cst > > stores. This is not really a question of MEMMODEL_SEQ_CST but what you > > apply it to. > > Ok, my point was just that an __sync operation has a stronger barrier that > an __atomic operation. > I think that is just an interpretation problem or flaw in my documentation. It was never meant to indicate any difference between __sync and MEMMODEL_SEQ_CST. Have you tried it on a gcc before __atomic and __sync were merged? probably GCC 4.7 and earlier. The code should be identical. Of course, changes to the machine description patterns could result in differences I suppose... but the intent is that SEQ_CST and __sync are the same... hence the code base was merged. The intention was also to deprecate __sync so I wouldn't put too much thought into it.
next prev parent reply other threads:[~2015-04-09 11:51 UTC|newest] Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-04-08 11:25 [Bug target/65697] New: " matthew.wahab at arm dot com 2015-04-08 11:33 ` [Bug target/65697] " matthew.wahab at arm dot com 2015-04-08 16:16 ` jakub at gcc dot gnu.org 2015-04-09 9:53 ` matthew.wahab at arm dot com 2015-04-09 10:08 ` torvald at gcc dot gnu.org 2015-04-09 10:11 ` torvald at gcc dot gnu.org 2015-04-09 10:47 ` matthew.wahab at arm dot com 2015-04-09 11:10 ` redi at gcc dot gnu.org 2015-04-09 11:25 ` matthew.wahab at arm dot com 2015-04-09 11:51 ` amacleod at redhat dot com [this message] 2015-04-09 14:03 ` matthew.wahab at arm dot com 2015-04-10 15:09 ` jgreenhalgh at gcc dot gnu.org 2015-04-15 10:16 ` aph at gcc dot gnu.org 2015-04-15 11:11 ` mwahab at gcc dot gnu.org 2015-04-15 11:54 ` jakub at gcc dot gnu.org 2015-04-15 12:43 ` aph at gcc dot gnu.org 2015-04-15 13:01 ` mwahab at gcc dot gnu.org 2015-04-15 14:10 ` aph at gcc dot gnu.org 2015-04-15 14:33 ` mwahab at gcc dot gnu.org 2015-04-15 14:49 ` aph at gcc dot gnu.org 2015-04-15 15:49 ` torvald at gcc dot gnu.org 2015-04-15 20:05 ` torvald at gcc dot gnu.org 2015-04-15 20:49 ` jgreenhalgh at gcc dot gnu.org 2015-04-15 22:13 ` torvald at gcc dot gnu.org 2015-04-16 3:45 ` amacleod at redhat dot com 2015-04-16 8:11 ` mwahab at gcc dot gnu.org 2015-04-16 8:50 ` mwahab at gcc dot gnu.org 2015-04-16 9:01 ` jgreenhalgh at gcc dot gnu.org 2015-04-16 9:18 ` mwahab at gcc dot gnu.org 2015-04-16 11:37 ` amacleod at redhat dot com 2015-04-16 11:54 ` torvald at gcc dot gnu.org 2015-04-16 12:13 ` mwahab at gcc dot gnu.org 2015-04-16 13:27 ` jgreenhalgh at gcc dot gnu.org 2015-04-17 15:38 ` torvald at gcc dot gnu.org 2015-04-17 15:48 ` torvald at gcc dot gnu.org 2015-04-17 18:00 ` amacleod at redhat dot com 2015-04-20 13:42 ` mwahab at gcc dot gnu.org 2015-04-20 15:17 ` mwahab at gcc dot gnu.org 2015-04-21 18:51 ` rth at gcc dot gnu.org 2015-04-28 15:32 ` jgreenhalgh at gcc dot gnu.org 2015-04-29 8:47 ` mwahab at gcc dot gnu.org 2015-04-29 12:20 ` jgreenhalgh at gcc dot gnu.org 2015-04-29 13:26 ` mwahab at gcc dot gnu.org 2015-04-29 16:04 ` amacleod at redhat dot com 2015-04-30 8:20 ` mwahab at gcc dot gnu.org 2015-05-01 12:53 ` torvald at gcc dot gnu.org 2015-05-06 14:25 ` amacleod at redhat dot com 2015-05-06 15:58 ` mwahab at gcc dot gnu.org 2015-05-07 13:25 ` mwahab at gcc dot gnu.org 2015-05-08 8:01 ` mwahab at gcc dot gnu.org 2015-05-11 13:44 ` jgreenhalgh at gcc dot gnu.org 2015-05-11 15:58 ` mwahab at gcc dot gnu.org 2015-05-12 20:02 ` amacleod at redhat dot com 2015-06-01 15:19 ` mwahab at gcc dot gnu.org 2015-06-01 15:21 ` mwahab at gcc dot gnu.org 2015-06-01 15:25 ` mwahab at gcc dot gnu.org 2015-06-11 7:35 ` ramana at gcc dot gnu.org 2015-06-29 16:04 ` mwahab at gcc dot gnu.org 2015-06-29 16:09 ` mwahab at gcc dot gnu.org 2015-06-29 16:12 ` mwahab at gcc dot gnu.org 2015-08-05 11:21 ` mwahab at gcc dot gnu.org 2015-08-05 11:30 ` mwahab at gcc dot gnu.org 2015-08-05 11:41 ` mwahab at gcc dot gnu.org 2015-08-05 11:49 ` mwahab at gcc dot gnu.org 2015-08-05 13:28 ` mwahab at gcc dot gnu.org 2015-08-05 13:40 ` mwahab at gcc dot gnu.org 2015-08-05 13:43 ` mwahab at gcc dot gnu.org 2015-09-30 3:07 ` ramana at gcc dot gnu.org 2015-10-05 8:08 ` mwahab at gcc dot gnu.org 2015-10-05 8:30 ` ramana 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-65697-4-xEi9R0wpEC@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).