[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2023-12-10 Thread admin_public at liblfds dot org via Gcc-bugs
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2023-12-10 Thread lh_mouse at 126 dot com via Gcc-bugs
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2023-11-15 Thread lh_mouse at 126 dot com via Gcc-bugs
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2022-11-03 Thread admin_public at liblfds dot org via Gcc-bugs
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2022-11-03 Thread fw at gcc dot gnu.org via Gcc-bugs
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.

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2022-11-03 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2022-11-03 Thread lh_mouse at 126 dot com via Gcc-bugs
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2021-05-07 Thread s_gccbugzilla at nedprod dot com via Gcc-bugs
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?

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2021-05-07 Thread redi at gcc dot gnu.org via Gcc-bugs
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2021-05-07 Thread s_gccbugzilla at nedprod dot com via Gcc-bugs
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2021-05-06 Thread liblfds_gccbz at winterflaw dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 liblfds admin changed: What|Removed |Added CC||liblfds_gccbz at winterflaw dot ne

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2021-05-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2021-05-06 Thread s_gccbugzilla at nedprod dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 Niall Douglas changed: What|Removed |Added CC||s_gccbugzilla at nedprod dot com ---

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2021-03-16 Thread wuyongwei at gmail dot com via Gcc-bugs
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2021-03-13 Thread wuyongwei at gmail dot com via Gcc-bugs
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2021-03-13 Thread wuyongwei at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 Yongwei Wu changed: What|Removed |Added CC||wuyongwei at gmail dot com --- Comment #27

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2020-04-18 Thread fw at gcc dot gnu.org
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: > >

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2020-04-18 Thread a...@cloudius-systems.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 --- Comment #25 from Avi Kivity --- PR 94649.

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2020-04-18 Thread a...@cloudius-systems.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 --- Comment #24 from Avi Kivity --- I'll file a new PR.

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2020-04-18 Thread fw at gcc dot gnu.org
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2020-04-18 Thread a...@cloudius-systems.com
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 ().

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2020-04-18 Thread fw at gcc dot gnu.org
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2020-04-18 Thread a...@cloudius-systems.com
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2020-01-28 Thread rockeet at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 rockeet changed: What|Removed |Added CC||rockeet at gmail dot com --- Comment #19 from

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2018-04-05 Thread nruslan_devel at yahoo dot com
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2018-03-29 Thread andysem at mail dot ru
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2018-03-29 Thread fw at gcc dot gnu.org
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2018-03-29 Thread crc at winterflaw dot net
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2018-03-29 Thread andysem at mail dot ru
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++

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2018-03-29 Thread toby at winterflaw dot net
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2018-03-29 Thread andysem at mail dot ru
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,

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2018-03-29 Thread fw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 Florian Weimer changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed|

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2018-02-25 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 Andrew Pinski changed: What|Removed |Added CC||nruslan_devel at yahoo dot com ---

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2017-09-02 Thread andysem at mail dot ru
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 ---

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2017-05-26 Thread amonakov at gcc dot gnu.org
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2017-05-26 Thread redi at gcc dot gnu.org
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2017-05-26 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2017-05-25 Thread redi at gcc dot gnu.org
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.

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2017-05-25 Thread admin_public at liblfds dot org
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

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2017-05-25 Thread redi at gcc dot gnu.org
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.

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2017-05-25 Thread admin_public at liblfds dot org
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,

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

2017-05-25 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 Andrew Pinski changed: What|Removed |Added Component|c |target --- Comment #1 from Andrew