| Summary: | __atomic_always_lock_free inconsistent with __GCC_ATOMIC_INT_LOCK_FREE et al. on crisv32 and hppa | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Hans-Peter Nilsson <hp> |
| Component: | target | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | amacleod, danglin, dave.anglin, dushistov, egallager, jeffreyalaw, law, nick.mayerhofer, schwab, sjames |
| Priority: | P3 | ||
| Version: | 4.8.0 | ||
| Target Milestone: | --- | ||
| See Also: |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54003 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83638 |
||
| Host: | Target: | crisv32-axis-linux-gnu, "crisv32-elf -munaligned-atomic-may-use-library", hppa*-* | |
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | ||
| Attachments: |
Testcase suitable for gcc.dg/torture
Patch using can_compare_and_swap_p but with multiple problems |
||
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. 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.) Created attachment 27842 [details] 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. 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/msg00007.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 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 $ 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 (In reply to Hans-Peter Nilsson from comment #6) > 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.) oh ok, I missed that part at first; retitling to include the targets. > > > Can you try again? > > Not for a couple of weeks, sorry. > > brgds, H-P I guess I'll put it back in UNCONFIRMED instead of leaving it in WAITING... (In reply to Hans-Peter Nilsson from comment #0) > Created attachment 27820 [details] > Testcase suitable for gcc.dg/torture > > See attached test-case, which fails for crisv32-axis-linux-gnu and > "crisv32-elf -munaligned-atomic-may-use-library" and likely for e.g. m68k > coldfire and definitely for hppa*-* (only library, no patterns). cc-ing maintainers for those targets The test passes on hppa. The hppa-linux target has a kernel helper to implement compare and swap. The hpux target isn't "lock free". There is a debate as to whether the linux implementation Is "lock free" or not. See PR83638. |
Created attachment 27820 [details] Testcase suitable for gcc.dg/torture Also affecting C++ and libstdc++. The definition of the macros in the __GCC_ATOMIC_CHAR_LOCK_FREE, __GCC_ATOMIC_INT_LOCK_FREE family is inconsistent with __atomic_always_lock_free. The latter implies that library calls are always lock-free while the macros just check for presence of certain patterns. They should call a common function. See attached test-case, which fails for crisv32-axis-linux-gnu and "crisv32-elf -munaligned-atomic-may-use-library" and likely for e.g. m68k coldfire and definitely for hppa*-* (only library, no patterns).