[Bug d/113772] New: [14 Regression] atomic.d compile error since recent upstream imports.

[Bug d/113772] New: [14 Regression] atomic.d compile error since recent upstream imports.

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

            Bug ID: 113772
           Summary: [14 Regression] atomic.d compile error since recent
                    upstream imports.
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: build
          Severity: normal
          Priority: P3
         Component: d
          Assignee: ibuclaw at gdcproject dot org
          Reporter: iains at gcc dot gnu.org
  Target Milestone: ---
            Target: powerpc64-linux, powerpc-darwin

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).

=====

/home/iains/gcc-master/src/libphobos/libdruntime/core/internal/atomic.d:612:53:
error: cannot evaluate unimplemented builtin ‘__atomic_is_lock_free’ at compile
time
  612 |     enum IsAtomicLockFree(T) = __atomic_is_lock_free(T.sizeof, null);
      |                                                     ^
../../../../../src/libphobos/libdruntime/core/stdc/stdatomic.d:65:30: error:
template instance ‘core.internal.atomic.IsAtomicLockFree!ulong’ error
instantiating
   65 |     ATOMIC_LLONG_LOCK_FREE = IsAtomicLockFree!ulong ? 2 : 0,

======

I wonder if that enum should also be guarded by
"static if (GNU_Have_Atomics || GNU_Have_LibAtomic)"

although that ought to make no difference since both the platforms mentioned
have support for libatomic.

-------

work-around:

    version (PPC)
    {
        enum IsAtomicLockFree(T) = T.sizeof <= 4;
    }
    else
    {
        enum IsAtomicLockFree(T) = __atomic_is_lock_free(T.sizeof, null);
    }

[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0

[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

--- Comment #1 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
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.

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

--- Comment #2 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(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.

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---

        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.

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

--- Comment #4 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
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.

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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.

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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.

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

--- Comment #7 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(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.

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

--- Comment #8 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
Created attachment 57329
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57329&action=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.

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

--- Comment #9 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(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.

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-02-05
             Status|UNCONFIRMED                 |NEW

--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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.

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

--- Comment #11 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(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.

[dkm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

Marc Poulhiès <dkm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dkm at gcc dot gnu.org

--- Comment #12 from Marc Poulhiès <dkm at gcc dot gnu.org> ---
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.

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doko at gcc dot gnu.org

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 113820 has been marked as a duplicate of this bug. ***

[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.

[doko at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

--- Comment #14 from Matthias Klose <doko at gcc dot gnu.org> ---
the proposed patch also fixes the arm-linux-gnueabi build (armv5t)

[Bug d/113772] [14 Regression] atomic.d compile error since recent upstream imports.

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

--- Comment #15 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain Buclaw <ibuclaw@gcc.gnu.org>:

https://gcc.gnu.org/g:2dde675ff48600188d3e892d191a2345bad2e6ae

commit r14-8934-g2dde675ff48600188d3e892d191a2345bad2e6ae
Author: Iain Buclaw <ibuclaw@gdcproject.org>
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.

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772

Iain Buclaw <ibuclaw at gdcproject dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #16 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
Fix downstreamed.