[Bug c/54006] __atomic_always_lock_free inconsistent with __GCC_ATOMIC_INT_LOCK_FREE et al.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54006 --- Comment #6 from Hans-Peter Nilsson --- On Fri, 28 Jul 2017, egallager at gcc dot gnu.org wrote: > Testcase compiles, runs, and exits with 0 for me on i386-apple-darwin9.8.0. I'm not sure how that target is relevant? (I forgot to set a target and can't edit the bug at present other than replying by email, but see the original description for a list of targets where the test was known to fail or expected to fail. Note also that the test is brittle and may be undesirably optimized to always pass.) > Can you try again? Not for a couple of weeks, sorry. brgds, H-P
[Bug c/54006] __atomic_always_lock_free inconsistent with __GCC_ATOMIC_INT_LOCK_FREE et al.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54006 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-07-28 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Eric Gallager --- Testcase compiles, runs, and exits with 0 for me on i386-apple-darwin9.8.0. Can you try again? $ /usr/local/bin/gcc -o 54006.exe 54006.c $ ./54006.exe $ echo $? 0 $
[Bug c/54006] __atomic_always_lock_free inconsistent with __GCC_ATOMIC_INT_LOCK_FREE et al.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54006 Nick nick.mayerho...@rise-world.com changed: What|Removed |Added CC||nick.mayerhofer@rise-world. ||com --- Comment #4 from Nick nick.mayerho...@rise-world.com --- FYI: There is also a debian bug [1], an entry in the debian mailing list [2], a related bug in the nghttp2 project [3] (with a cpp code-based workaround [4]) and a similar looking entry at stackoverflow [5]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727621 [2] https://lists.debian.org/debian-arm/2013/12/msg7.html [3] https://github.com/tatsuhiro-t/nghttp2/issues/86 [4] https://github.com/tatsuhiro-t/nghttp2/commit/ba92935f64627f77d3b9a1439766d83dc0c9f679 [5] http://stackoverflow.com/questions/22036396/stdpromise-error-on-cross-compiling
[Bug c/54006] __atomic_always_lock_free inconsistent with __GCC_ATOMIC_INT_LOCK_FREE et al.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54006 --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-07-20 04:06:41 UTC --- FWIW, cpp_atomic_builtins is called before the target TARGET_INIT_LIBFUNCS is called (at least on the 4.7 branch) so using can_compare_and_swap_p as the / in the common function (as is needed) requires moving some initialization bits to avoid a SEGV. There be dragons there. (Not that they shouldn't be slayed, just beware.)
[Bug c/54006] __atomic_always_lock_free inconsistent with __GCC_ATOMIC_INT_LOCK_FREE et al.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54006 --- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-07-20 04:16:20 UTC --- Created attachment 27842 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27842 Patch using can_compare_and_swap_p but with multiple problems Besides the SEGV due to the initialization problem aleady mentioned, this patch codifies the assumption that atomic intrinsic library functions (i.e. libgcc-style) aren't lock-free, which is wrong but at least consistent with the conceptual patch in PR54003.
[Bug c/54006] __atomic_always_lock_free inconsistent with __GCC_ATOMIC_INT_LOCK_FREE et al.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54006 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-07-17 22:44:11 UTC --- By the macros just check for presence of certain patterns I mean the code defining those macros, in c-family/c-cppbuiltin.c:cpp_atomic_builtins.
