* [PATCH] correct documentation of attribute ifunc (PR 81882)
@ 2017-08-17 19:26 Martin Sebor
2017-08-17 23:41 ` Alexander Monakov
0 siblings, 1 reply; 5+ messages in thread
From: Martin Sebor @ 2017-08-17 19:26 UTC (permalink / raw)
To: Gcc Patch List
[-- Attachment #1: Type: text/plain, Size: 193 bytes --]
The attached patch adjusts the documentation of attribute ifunc
to avoid warnings (in C) and errors (in C++) due to the resolver
returning a pointer to a function of incompatible type.
Martin
[-- Attachment #2: gcc-81882.diff --]
[-- Type: text/x-patch, Size: 1716 bytes --]
PR c/81882 - attribute ifunc documentation uses invalid code
gcc/ChangeLog:
PR c/81882
* doc/extend.texi (attribute ifunc): Avoid relying on ill-formed
code (in C++) or code that triggers warnings.
Index: gcc/doc/extend.texi
===================================================================
--- gcc/doc/extend.texi (revision 251156)
+++ gcc/doc/extend.texi (working copy)
@@ -2783,21 +2783,24 @@ The @code{ifunc} attribute is used to mark a funct
function using the STT_GNU_IFUNC symbol type extension to the ELF
standard. This allows the resolution of the symbol value to be
determined dynamically at load time, and an optimized version of the
-routine can be selected for the particular processor or other system
+routine to be selected for the particular processor or other system
characteristics determined then. To use this attribute, first define
the implementation functions available, and a resolver function that
returns a pointer to the selected implementation function. The
implementation functions' declarations must match the API of the
-function being implemented, the resolver's declaration is be a
-function returning pointer to void function returning void:
+function being implemented. The resolver should be declared to
+be a function returning a pointer to a function taking no arguments
+and returning a pointer to a function of the same type as the
+implementation. For example:
@smallexample
void *my_memcpy (void *dst, const void *src, size_t len)
@{
@dots{}
+ return dst;
@}
-static void (*resolve_memcpy (void)) (void)
+static void* (*resolve_memcpy (void))(void *, const void *, size_t)
@{
return my_memcpy; // we'll just always select this routine
@}
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] correct documentation of attribute ifunc (PR 81882)
2017-08-17 19:26 [PATCH] correct documentation of attribute ifunc (PR 81882) Martin Sebor
@ 2017-08-17 23:41 ` Alexander Monakov
2017-08-17 23:44 ` Martin Sebor
0 siblings, 1 reply; 5+ messages in thread
From: Alexander Monakov @ 2017-08-17 23:41 UTC (permalink / raw)
To: Martin Sebor; +Cc: Gcc Patch List
On Thu, 17 Aug 2017, Martin Sebor wrote:
> returns a pointer to the selected implementation function. The
> implementation functions' declarations must match the API of the
> -function being implemented, the resolver's declaration is be a
> -function returning pointer to void function returning void:
> +function being implemented. The resolver should be declared to
> +be a function returning a pointer to a function taking no arguments
> +and returning a pointer to a function of the same type as the
> +implementation. For example:
The new wording is wrong (extra level of pointer-to-function).
I suggest removing this part altogether, it's not useful at all,
anyone writing the resolver can deduce what the return type should be
based on the fact that a pointer to the implementation is returned.
(fwiw a simple 'void *' as return type would work in practice too)
Alexander
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] correct documentation of attribute ifunc (PR 81882)
2017-08-17 23:41 ` Alexander Monakov
@ 2017-08-17 23:44 ` Martin Sebor
2017-08-18 8:27 ` Andreas Schwab
2017-09-06 23:05 ` Joseph Myers
0 siblings, 2 replies; 5+ messages in thread
From: Martin Sebor @ 2017-08-17 23:44 UTC (permalink / raw)
To: Alexander Monakov; +Cc: Gcc Patch List
[-- Attachment #1: Type: text/plain, Size: 2003 bytes --]
On 08/17/2017 01:26 PM, Alexander Monakov wrote:
> On Thu, 17 Aug 2017, Martin Sebor wrote:
>
>> returns a pointer to the selected implementation function. The
>> implementation functions' declarations must match the API of the
>> -function being implemented, the resolver's declaration is be a
>> -function returning pointer to void function returning void:
>> +function being implemented. The resolver should be declared to
>> +be a function returning a pointer to a function taking no arguments
>> +and returning a pointer to a function of the same type as the
>> +implementation. For example:
>
> The new wording is wrong (extra level of pointer-to-function).
You're right, that's a silly typo. Thanks for catching it!
Here's what I meant to write:
The resolver should be declared to be a function taking no
arguments and returning a pointer to a function of the same
type as the implementation.
Attached is an updated patch with the corrected wording.
> I suggest removing this part altogether, it's not useful at all,
> anyone writing the resolver can deduce what the return type should be
> based on the fact that a pointer to the implementation is returned.
I suppose that would work too. If there's preference for
this approach I'm happy to remove the last sentence.
> (fwiw a simple 'void *' as return type would work in practice too)
Well, yes, it would work, but only about as well as the current
wording and example do. I.e., it triggers (pedantic) warnings
in C and errors in C++. To get around the errors, the usual
approach (despite what the manual says about returning a pointer
to a function) is to return void* and cast the address of the
function to it. It would be helpful if users could avoid the
cast while at the same time having incompatibilities detected
for them.
(FWIW, I noticed this problem while testing an improvement
to have GCC do just that: detect invalid conversions in these
kinds of attributes (alias and ifunc) under bug 81854.)
Martin
[-- Attachment #2: gcc-81882.diff --]
[-- Type: text/x-patch, Size: 1681 bytes --]
PR c/81882 - attribute ifunc documentation uses invalid code
gcc/ChangeLog:
PR c/81882
* doc/extend.texi (attribute ifunc): Avoid relying on ill-formed
code (in C++) or code that triggers warnings.
Index: gcc/doc/extend.texi
===================================================================
--- gcc/doc/extend.texi (revision 251156)
+++ gcc/doc/extend.texi (working copy)
@@ -2783,21 +2783,23 @@ The @code{ifunc} attribute is used to mark a funct
function using the STT_GNU_IFUNC symbol type extension to the ELF
standard. This allows the resolution of the symbol value to be
determined dynamically at load time, and an optimized version of the
-routine can be selected for the particular processor or other system
+routine to be selected for the particular processor or other system
characteristics determined then. To use this attribute, first define
the implementation functions available, and a resolver function that
returns a pointer to the selected implementation function. The
implementation functions' declarations must match the API of the
-function being implemented, the resolver's declaration is be a
-function returning pointer to void function returning void:
+function being implemented. The resolver should be declared to
+be a function taking no arguments and returning a pointer to
+a function of the same type as the implementation. For example:
@smallexample
void *my_memcpy (void *dst, const void *src, size_t len)
@{
@dots{}
+ return dst;
@}
-static void (*resolve_memcpy (void)) (void)
+static void* (*resolve_memcpy (void))(void *, const void *, size_t)
@{
return my_memcpy; // we'll just always select this routine
@}
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] correct documentation of attribute ifunc (PR 81882)
2017-08-17 23:44 ` Martin Sebor
@ 2017-08-18 8:27 ` Andreas Schwab
2017-09-06 23:05 ` Joseph Myers
1 sibling, 0 replies; 5+ messages in thread
From: Andreas Schwab @ 2017-08-18 8:27 UTC (permalink / raw)
To: Martin Sebor; +Cc: Alexander Monakov, Gcc Patch List
On Aug 17 2017, Martin Sebor <msebor@gmail.com> wrote:
> -static void (*resolve_memcpy (void)) (void)
> +static void* (*resolve_memcpy (void))(void *, const void *, size_t)
Please use consistent spacing.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] correct documentation of attribute ifunc (PR 81882)
2017-08-17 23:44 ` Martin Sebor
2017-08-18 8:27 ` Andreas Schwab
@ 2017-09-06 23:05 ` Joseph Myers
1 sibling, 0 replies; 5+ messages in thread
From: Joseph Myers @ 2017-09-06 23:05 UTC (permalink / raw)
To: Martin Sebor; +Cc: Alexander Monakov, Gcc Patch List
This patch is OK with the spacing in the function prototype fixed as noted
to follow normal GNU standards.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-09-06 23:05 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-17 19:26 [PATCH] correct documentation of attribute ifunc (PR 81882) Martin Sebor
2017-08-17 23:41 ` Alexander Monakov
2017-08-17 23:44 ` Martin Sebor
2017-08-18 8:27 ` Andreas Schwab
2017-09-06 23:05 ` Joseph Myers
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).