https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #43 from admin_public at liblfds dot org ---
> I tested CMPXCHG16B with inline assembly on an i7-1165G7 (Dell XPS 13 9305)
> and it turned out to be much slower than CMPXCHG, even slower than a pair of
> calls to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #42 from LIU Hao ---
(In reply to Yongwei Wu from comment #27)
> Anyone can show a valid use case for a non-lock-free version of 128-bit
> atomic_compare_exchange?
>
> I am trying to use it in a data structure intended to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #41 from LIU Hao ---
There should have been an option, long ago since GCC 7, which may be called
-mcx16-just-emit-the-god-damn-cmpxchg16b-for-me-if-it-does-not-work-its-not-your-fault
`__sync_*` are not an option as 1) they do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #40 from admin_public at liblfds dot org ---
On 03/11/2022 12:04, jakub at gcc dot gnu.org wrote:
> --- Comment #38 from Jakub Jelinek ---
> Please see PR104688 . We got a response from Intel, where they guaranteed
> atomicity of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #39 from Florian Weimer ---
(In reply to Jakub Jelinek from comment #38)
> Please see PR104688 . We got a response from Intel, where they guaranteed
> atomicity of certain 16-byte load instructions for Intel CPUs with AVX
> support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #36 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #35 from Niall Douglas ---
(In reply to Jonathan Wakely from comment #34)
> > Perhaps I ought to open a separate issue here, as my specific problem is
> > that std::atomic<__int128>::compare_exchange_weak() is not using cmpxchg16b?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #34 from Jonathan Wakely ---
(In reply to Niall Douglas from comment #33)
> Re: your original point, I cannot say anything about _Atomic. However, for
> std::atomic<__int128>, as __int128 is not an integral type it seems
That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #33 from Niall Douglas ---
(In reply to Andrew Pinski from comment #31)
>
> Again the problem is stuff like:
> static const _Atomic __int128_t t = 2000;
>
> __int128_t g(void)
> {
> return t;
> }
>
> DOES NOT WORK if you use CAS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
liblfds admin changed:
What|Removed |Added
CC||liblfds_gccbz at winterflaw
dot ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #31 from Andrew Pinski ---
(In reply to Niall Douglas from comment #30)
> I got bit by this GCC regression today at work. Consider
> https://godbolt.org/z/M9fd7nhdh where std::atomic<__int128> is compare
> exchanged with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
Niall Douglas changed:
What|Removed |Added
CC||s_gccbugzilla at nedprod dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #29 from Yongwei Wu ---
As usual, test results are always elusive. I have to add yet another important
piece of information. The very bad performance result does not occur on Linux,
but only on macOS (Homebrew versions of GCC and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #28 from Yongwei Wu ---
OK, somewhat answering myself. I was not aware of the fact that 128-bit atomic
read has to be implemented using cmpxchg16b as well, thus defeating some
non-CAS usage scenarios.
The natural question is: which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
Yongwei Wu changed:
What|Removed |Added
CC||wuyongwei at gmail dot com
--- Comment #27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #26 from Florian Weimer ---
(In reply to Florian Weimer from comment #23)
> Ahh, I think this bug here is specific to __uint128 (with the C front end at
> least)
>
> The C translation of the C++ reproducer from comment 20:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #25 from Avi Kivity ---
PR 94649.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #24 from Avi Kivity ---
I'll file a new PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #23 from Florian Weimer ---
Ahh, I think this bug here is specific to __uint128 (with the C front end at
least)
The C translation of the C++ reproducer from comment 20:
struct a
{
long _Alignas(16) x;
long y;
};
_Bool
cmpxchg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #22 from Avi Kivity ---
Perhaps PR 84522 should be reopened and unmarked as a duplicate. While the
reproducer there is a C API, it is the C equivalent of
().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #21 from Florian Weimer ---
(In reply to Avi Kivity from comment #20)
> Note that clang generates cmpxchg16b when the conditions are ripe:
>
> https://godbolt.org/z/j9Whgh
I believe this is a different, C++-specific issue. The C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #20 from Avi Kivity ---
Note that clang generates cmpxchg16b when the conditions are ripe:
https://godbolt.org/z/j9Whgh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
rockeet changed:
What|Removed |Added
CC||rockeet at gmail dot com
--- Comment #19 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #18 from Ruslan Nikolaev ---
(In reply to andysem from comment #17)
> I'll clarify why I think load() should be allowed to issue writes on the
> memory. According to [atomics.types.operations]/18 in N4713,
> compare_exchange_*() is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #17 from andysem at mail dot ru ---
I'll clarify why I think load() should be allowed to issue writes on the
memory. According to [atomics.types.operations]/18 in N4713,
compare_exchange_*() is a load operation if the comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #16 from Florian Weimer ---
(In reply to andysem from comment #12)
> Is read-only memory a valid use case for __atomic intrinsics anyway? These
> intrinsics are primarily targeted to implement std::atomic,
I strongly disagree about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #15 from crc at winterflaw dot net ---
On 29/03/18 19:23, andysem at mail dot ru wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
>
> --- Comment #14 from andysem at mail dot ru ---
>> On Intel, all CAS operations always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #14 from andysem at mail dot ru ---
> On Intel, all CAS operations always write, even if thr compare failed.
I understand that. The question is whether this is allowed behavior for
atd::atomic::load() operation according to the C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #13 from toby at winterflaw dot net ---
On 29 Mar 2018, andysem at mail dot ru wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
>
>--- Comment #12 from andysem at mail dot ru ---
>Is read-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #12 from andysem at mail dot ru ---
Is read-only memory a valid use case for __atomic intrinsics anyway? These
intrinsics are primarily targeted to implement std::atomic, but does the
standard guarantee these operations (primarily,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
Florian Weimer changed:
What|Removed |Added
Status|RESOLVED|NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
Andrew Pinski changed:
What|Removed |Added
CC||nruslan_devel at yahoo dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
andysem at mail dot ru changed:
What|Removed |Added
CC||andysem at mail dot ru
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #8 from Alexander Monakov ---
Well, at least it's not too late to update the compiler manual, so I've
submitted a patch: https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02080.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #7 from Jonathan Wakely ---
Since this makes libatomic required for DCAS on x86_64 it should probably have
been documented at https://gcc.gnu.org/gcc-7/changes.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #5 from Jonathan Wakely ---
Yes, I didn't say it's lock-free, but the code can be compiled and linked.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #4 from admin_public at liblfds dot org ---
I've had a look at the libatomic source code. Obviously, it's problematic to
be sure you're understanding a large code base correctly when you go to it for
the first time and you're looking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #3 from Jonathan Wakely ---
libatomic provides a definition for __atomic_compare_exchange_16 when the
native instruction isn't available.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #2 from admin_public at liblfds dot org ---
Am I right in understanding your comment to mean 128 bit CAS is no longer
supported for x86_64?
I publish a library of lock-free data structures, liblfds. It has some users,
include AT,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
Andrew Pinski changed:
What|Removed |Added
Component|c |target
--- Comment #1 from Andrew
42 matches
Mail list logo