[Bug target/55966] __atomic_fetch_* generate wrong code for HLE

2024-04-08 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED

[Bug target/55966] __atomic_fetch_* generate wrong code for HLE

2013-01-14 Thread andi-gcc at firstfloor dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 --- Comment #9 from Andi Kleen 2013-01-14 22:34:16 UTC --- Also i need to look more closely, but most likely the C++ atomic code should be changed to avoid this situation. This would give much better code on x86 in any case even without el

[Bug target/55966] __atomic_fetch_* generate wrong code for HLE

2013-01-14 Thread andi-gcc at firstfloor dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 --- Comment #8 from Andi Kleen 2013-01-14 22:32:06 UTC --- forbid = give warning and drop bit It's a hint, but in a good implementation it should not be silently dropped or code generated that has no chance to elide. It's a quality of im

[Bug target/55966] __atomic_fetch_* generate wrong code for HLE

2013-01-14 Thread amacleod at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com ---

[Bug target/55966] __atomic_fetch_* generate wrong code for HLE

2013-01-14 Thread andi-gcc at firstfloor dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 --- Comment #6 from Andi Kleen 2013-01-14 22:05:38 UTC --- Hmm that's true. x86 doesn't have xand, x_or, x_xor, only xadd Maybe cmpxchg is the only way? For some special cases it can be done (like and single bit-> btr, or single bit ->

[Bug target/55966] __atomic_fetch_* generate wrong code for HLE

2013-01-14 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 --- Comment #5 from Uros Bizjak 2013-01-14 21:25:13 UTC --- Following testcase will expand to a cmpxchg loop: int hle_and (int *p, int v) { return __atomic_fetch_and_4 (p, v, __ATOMIC_ACQUIRE | __ATOMIC_HLE_ACQUIRE); }

[Bug target/55966] __atomic_fetch_* generate wrong code for HLE

2013-01-14 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 --- Comment #4 from Uros Bizjak 2013-01-14 21:22:35 UTC --- The problem is, that in failed case maybe_emit_op() gets target register to return the result to, so with after=false, it expands via optab->mem_fetch_before. Unfortunately, at

[Bug target/55966] __atomic_fetch_* generate wrong code for HLE

2013-01-14 Thread andi-gcc at firstfloor dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 Andi Kleen changed: What|Removed |Added Attachment #29163|0 |1 is obsolete|

[Bug target/55966] __atomic_fetch_* generate wrong code for HLE

2013-01-14 Thread andi-gcc at firstfloor dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 --- Comment #2 from Andi Kleen 2013-01-14 19:52:03 UTC --- Created attachment 29163 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29163 preprocessed testcase

[Bug target/55966] __atomic_fetch_* generate wrong code for HLE

2013-01-14 Thread andi-gcc at firstfloor dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966 --- Comment #1 from Andi Kleen 2013-01-14 19:06:02 UTC --- Here's a test case. This requires the libstdc++ HLE patch from http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00673.html g++ -std=gnu++0x #include #define ACQ memory_order_a