http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
David Edelsohn dje at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-10
09:43:16 UTC ---
(In reply to comment #3)
It says above them In most cases, these
builtins are considered a full barrier. and only __sync_lock_test_and_set
and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
--- Comment #5 from David Edelsohn dje at gcc dot gnu.org 2012-01-10 14:39:16
UTC ---
I understand that fixing __sync_* is a hassle. This is why I opened a separate
bug for libstdc++.
While __sync_* is deprecated in favor of __atomic_*, use of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-10
14:48:54 UTC ---
(In reply to comment #5)
I understand that fixing __sync_* is a hassle. This is why I opened a
separate
bug for libstdc++.
While __sync_* is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-10
15:29:09 UTC ---
(In reply to comment #3)
It says above them In most cases, these
builtins are considered a full barrier. and only __sync_lock_test_and_set
and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
--- Comment #8 from David Edelsohn dje at gcc dot gnu.org 2012-01-10 18:08:23
UTC ---
For the way that programmers use __sync_* builtins, release or acquire-release
semantics are sufficient. As we see in libstdc++, release semantics are overly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
--- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-10
18:20:00 UTC ---
(In reply to comment #8)
For the way that programmers use __sync_* builtins, release or acquire-release
semantics are sufficient.
Are you claiming you know
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
--- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-10
18:22:01 UTC ---
(In reply to comment #8)
IBM should have the freedom to choose memory
models that benefit its architectures.
I meant to add that the new __atomic builtins
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
--- Comment #11 from David Edelsohn dje at gcc dot gnu.org 2012-01-10
18:33:56 UTC ---
Jonathan,
I understand that the new __atomic_* builtins provide that flexibility.
I also am pointing out that GCC followed Intel semantics and Intel chose
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
Andrew Macleod amacleod at redhat dot com changed:
What|Removed |Added
CC||amacleod at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
--- Comment #14 from David Edelsohn dje at gcc dot gnu.org 2012-01-10
20:25:57 UTC ---
Jakub,
The POWER implementation of __sync_* was not written intentionally to violate
the documentation. I don't think those of us who implemented the feature
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-01-09
15:45:06 UTC ---
(In reply to comment #1)
The docs of __sync_* say
This builtin is not a full barrier, but rather an @dfn{acquire barrier}.
This means that references
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
--- Comment #3 from David Edelsohn dje at gcc dot gnu.org 2012-01-09 16:49:10
UTC ---
It says above them In most cases, these
builtins are considered a full barrier. and only __sync_lock_test_and_set and
__sync_lock_release specify different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51766
David Edelsohn dje at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
16 matches
Mail list logo
