[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #16 from Iain Buclaw --- Fix downstreamed.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #15 from GCC Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:2dde675ff48600188d3e892d191a2345bad2e6ae commit r14-8934-g2dde675ff48600188d3e892d191a2345bad2e6ae Author: Iain Buclaw Date: Mon Feb 12 16:46:33 2024 +0100 d: Merge dmd, druntime 11240a9663 D front-end changes: - Import latest fixes from dmd v2.107.0. D runtime changes: - Import latest fixes from druntime v2.107.0. Included in the merge are the fix for PR113772, and new testsuite directives to enable fixing PR104739. PR d/113772 gcc/d/ChangeLog: * dmd/MERGE: Merge upstream dmd 11240a9663. * d-builtins.cc (build_frontend_type): Update for new front-end interface. * types.cc (same_type_p): Likewise. libphobos/ChangeLog: * libdruntime/MERGE: Merge upstream druntime 11240a9663.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #14 from Matthias Klose --- the proposed patch also fixes the arm-linux-gnueabi build (armv5t)
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 Andrew Pinski changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #13 from Andrew Pinski --- *** Bug 113820 has been marked as a duplicate of this bug. ***
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 Marc Poulhiès changed: What|Removed |Added CC||dkm at gcc dot gnu.org --- Comment #12 from Marc Poulhiès --- FWIW, I think we are having the same issue when building our nightly riscv32 cross on compiler explorer: https://github.com/compiler-explorer/compiler-explorer/issues/6102
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #11 from Iain Buclaw --- (In reply to Iain Sandoe from comment #10) > (In reply to Iain Buclaw from comment #8) > > Created attachment 57329 [details] > > The quick fix to the lock-free test > > > > The immediate thing that can be changed is turning the test into a > > `__traits(compiles)` one, which would turn the error into a `false` value. > > This works for me on both powerpc64-linux and a powerpc-darwin9 cross. > > NOTE: I expect a reduced testsuite on powerpc-darwin since we build > "--with-libphobos-druntime-only" however, I am a bit surprised that > powerpc64-linux has roughly half the number of tests (590 c.f. 1100) of > x86_64-linux; is this expected? (independent of this fix, this was the case > before too). Yes, powerpc64-linux has phobos disabled by default in libphobos/configure.tgt.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-02-05 Status|UNCONFIRMED |NEW --- Comment #10 from Iain Sandoe --- (In reply to Iain Buclaw from comment #8) > Created attachment 57329 [details] > The quick fix to the lock-free test > > The immediate thing that can be changed is turning the test into a > `__traits(compiles)` one, which would turn the error into a `false` value. This works for me on both powerpc64-linux and a powerpc-darwin9 cross. NOTE: I expect a reduced testsuite on powerpc-darwin since we build "--with-libphobos-druntime-only" however, I am a bit surprised that powerpc64-linux has roughly half the number of tests (590 c.f. 1100) of x86_64-linux; is this expected? (independent of this fix, this was the case before too).
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #9 from Iain Buclaw --- (In reply to Iain Buclaw from comment #8) > Created attachment 57329 [details] > The quick fix to the lock-free test > > The immediate thing that can be changed is turning the test into a > `__traits(compiles)` one, which would turn the error into a `false` value. I wonder though whether maybe the D compiler could push out some manifest constants into the gcc.builtins module similar to the __GCC_ATOMIC_LLONG_LOCK_FREE macros.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #8 from Iain Buclaw --- Created attachment 57329 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57329=edit The quick fix to the lock-free test The immediate thing that can be changed is turning the test into a `__traits(compiles)` one, which would turn the error into a `false` value.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #7 from Iain Buclaw --- (In reply to Iain Sandoe from comment #6) > (In reply to Iain Buclaw from comment #4) > > Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time > > > > /* If it isn't always lock free, don't generate a result. */ > > if (fold_builtin_atomic_always_lock_free (arg0, arg1) == > > boolean_true_node) > > return boolean_true_node; > > > ^ but this does fall back to a libcall to the relevant libatomic function, > (you can verify that with a simple C routine).. and given that both darwin > and linux powerpc have libatomic impls. this still should not give an > "unimplemented" response. The diagnostic is misleading. I gather it assumes "unimplemented" because there is no function body for CTFE to evaluate after the attempt to expand via gcc builtins.cc failed.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #6 from Iain Sandoe --- (In reply to Iain Buclaw from comment #4) > Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time > /* If it isn't always lock free, don't generate a result. */ > if (fold_builtin_atomic_always_lock_free (arg0, arg1) == boolean_true_node) > return boolean_true_node; ^ but this does fall back to a libcall to the relevant libatomic function, (you can verify that with a simple C routine).. and given that both darwin and linux powerpc have libatomic impls. this still should not give an "unimplemented" response.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #5 from Iain Sandoe ---
(In reply to Iain Buclaw from comment #4)
> Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time
> values one can get out of this built-in are "true" and "defer to run-time"
>
> ---
> /* Return a one or zero if it can be determined that object ARG1 of size ARG
>is lock free on this architecture. */
>
> static tree
> fold_builtin_atomic_is_lock_free (tree arg0, tree arg1)
> {
> if (!flag_inline_atomics)
> return NULL_TREE;
>
> /* If it isn't always lock free, don't generate a result. */
> if (fold_builtin_atomic_always_lock_free (arg0, arg1) == boolean_true_node)
> return boolean_true_node;
>
> return NULL_TREE;
> }
> ---
>
> The upstream contributor who tested this on x86 likely didn't get this
> because it's all lock-free.
indeed x86_64 and i686 both build fine .. but "it's all lock-free" is not
entirely true - x86-64 is only lock free up to 16bytes, so it might be a bug
waiting to happen there too.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #4 from Iain Buclaw ---
Looking at gcc/builtins.cc, I have a bad feeling that the only compile-time
values one can get out of this built-in are "true" and "defer to run-time"
---
/* Return a one or zero if it can be determined that object ARG1 of size ARG
is lock free on this architecture. */
static tree
fold_builtin_atomic_is_lock_free (tree arg0, tree arg1)
{
if (!flag_inline_atomics)
return NULL_TREE;
/* If it isn't always lock free, don't generate a result. */
if (fold_builtin_atomic_always_lock_free (arg0, arg1) == boolean_true_node)
return boolean_true_node;
return NULL_TREE;
}
---
The upstream contributor who tested this on x86 likely didn't get this because
it's all lock-free.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #3 from Iain Sandoe --- extern pure nothrow @nogc @safe bool __atomic_always_lock_free(uint, shared(const(void))*); extern pure nothrow @nogc @safe bool __atomic_is_lock_free(uint, shared(const(void))*); perhaps there's a parameter type mismatch or sth?
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #2 from Iain Buclaw --- (In reply to Iain Sandoe from comment #0) > I am now seeing this on both Darwin and Linux BE powerpc. > > The message is somewhat odd, since AFAICS from the core druntime code that > pulls in builtins.def which pulls in sync-builtins.def - which defines this > builtin. > > If I check the C compiler manually, then the builtin works as expected - > inline for 1,2,4 bytes and out-of-line call to the atomic library for 8+ > (32b PPC). Yes, that's correct. The contents of the builtins module can be dumped with: ``` // builtins.d module gcc.builtins; ``` gdc -H builtins.d && cat builtins.di I can check this shortly.
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 --- Comment #1 from Iain Buclaw --- Isn't __atomic_is_lock_free tied to the __GCC_ATOMIC_XXX_T_LOCK_FREE macros?
[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |14.0
