docs: Fix up __sync_* documentation [PR117642]
Checks
Commit Message
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?
2024-11-28 Jakub Jelinek <jakub@redhat.com>
PR target/117642
* doc/extend.texi: Remove documentation of warning for unimplemented
__sync_* operations, such warning has never been implemented.
Jakub
Comments
On Thu, Nov 28, 2024 at 1:52 PM Jakub Jelinek <jakub@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 <jakub@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
>
@@ -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