On Thu, Nov 28, 2024 at 1:52 PM Jakub Jelinek <ja...@redhat.com> wrote:
>
> Hi!
>
> The PR14311 commit which added support for __sync_* builtins documented that
> there is a warning if a particular operation cannot be implemented.
> But that commit nor anything later on implemented such warning, it was
> always silent generation of the mentioned calls (which can in most cases
> result in linker errors of course because those functions aren't implemented
> anywhere, in libatomic or elsewhere in code shipped in gcc).
>
> So, the following patch just adjust the documentation to match the
> implementation.
>
> Ok for trunk?
OK
> 2024-11-28 Jakub Jelinek <ja...@redhat.com>
>
> PR target/117642
> * doc/extend.texi: Remove documentation of warning for unimplemented
> __sync_* operations, such warning has never been implemented.
>
> --- gcc/doc/extend.texi.jj 2024-11-28 11:48:15.232659061 +0100
> +++ gcc/doc/extend.texi 2024-11-28 13:33:05.986713542 +0100
> @@ -13562,16 +13562,11 @@ builtins (@pxref{__atomic Builtins}). T
> code which should use the @samp{__atomic} builtins instead.
>
> Not all operations are supported by all target processors. If a particular
> -operation cannot be implemented on the target processor, a warning is
> -generated and a call to an external function is generated. The external
> -function carries the same name as the built-in version,
> -with an additional suffix
> +operation cannot be implemented on the target processor, a call to an
> +external function is generated. The external function carries the same name
> +as the built-in version, with an additional suffix
> @samp{_@var{n}} where @var{n} is the size of the data type.
>
> -@c ??? Should we have a mechanism to suppress this warning? This is almost
> -@c useful for implementing the operation under the control of an external
> -@c mutex.
> -
> In most cases, these built-in functions are considered a @dfn{full barrier}.
> That is,
> no memory operand is moved across the operation, either forward or
>
> Jakub
>
