From: Paul E Murphy <murphyp@linux.ibm.com>
To: Sachin Monga <smonga@linux.ibm.com>, libc-alpha@sourceware.org
Subject: Re: [PATCH] Added Redirects to longdouble error functions [BZ #29033]
Date: Mon, 13 Feb 2023 17:07:56 -0600 [thread overview]
Message-ID: <fe39e07c-bf67-ac28-cca9-47125717ced6@linux.ibm.com> (raw)
In-Reply-To: <20230209174528.292568-1-smonga@linux.ibm.com>
On 2/9/23 11:45 AM, Sachin Monga via Libc-alpha wrote:
> This patch redirects the error functions to the appropriate
> longdouble variants which enables the compiler to optimize
> for the abi ieeelongdouble.
This is a tricky patch. Are there tests to verify this functions as
desired when redirecting long double? If practical, please add some.
>
> Signed-off-by: Sachin Monga <smonga@linux.ibm.com>
> ---
> misc/bits/error-ldbl.h | 53 ++++++++++++++++++++++++++++++++++++++++--
> misc/sys/cdefs.h | 6 +++++
> 2 files changed, 57 insertions(+), 2 deletions(-)
>
> diff --git a/misc/bits/error-ldbl.h b/misc/bits/error-ldbl.h
> index 599a7d6e06..73ecbe7a10 100644
> --- a/misc/bits/error-ldbl.h
> +++ b/misc/bits/error-ldbl.h
> @@ -20,5 +20,54 @@
> # error "Never include <bits/error-ldbl.h> directly; use <error.h> instead."
> #endif
>
> -__LDBL_REDIR_DECL (error)
> -__LDBL_REDIR_DECL (error_at_line)
Does this still return the expected function with usage like?
#include <error.h>
typedef void (error_func_t)(int,int,const char*,...);
error_func_t
get_error_func() {
return &error;
}
> +
> +__LDBL_REDIRECT (__error_alias, (int __status, int __errnum,
> + const char *__format, ...),
> + error)
> + __attribute__ ((__format__ (__printf__, 3, 4)));
> +__LDBL_REDIRECT (__error_noreturn, (int __status, int __errnum,
> + const char *__format, ...),
> + error)
> + __attribute__ ((__noreturn__, __format__ (__printf__, 3, 4)));
> +
> +
> +/* If we know the function will never return make sure the compiler
> + realizes that, too. */
> +__extern_always_inline void
> +error (int __status, int __errnum, const char *__format, ...)
> +{
> + if (__builtin_constant_p (__status) && __status != 0)
> + __error_noreturn (__status, __errnum, __format, __va_arg_pack ());
> + else
> + __error_alias (__status, __errnum, __format, __va_arg_pack ());
> +}
> +
> +
> +__LDBL_REDIRECT (__error_at_line_alias, (int __status, int __errnum,
> + const char *__fname,
> + unsigned int __line,
> + const char *__format, ...),
> + error_at_line)
> + __attribute__ ((__format__ (__printf__, 5, 6)));
> +__LDBL_REDIRECT (__error_at_line_noreturn, (int __status, int __errnum,
> + const char *__fname,
> + unsigned int __line,
> + const char *__format,
> + ...),
> + error_at_line)
> + __attribute__ ((__noreturn__, __format__ (__printf__, 5, 6)));
> +
> +
> +/* If we know the function will never return make sure the compiler
> + realizes that, too. */
> +__extern_always_inline void
> +error_at_line (int __status, int __errnum, const char *__fname,
> + unsigned int __line, const char *__format, ...)
> +{
> + if (__builtin_constant_p (__status) && __status != 0)
> + __error_at_line_noreturn (__status, __errnum, __fname, __line, __format,
> + __va_arg_pack ());
> + else
> + __error_at_line_alias (__status, __errnum, __fname, __line,
> + __format, __va_arg_pack ());
> +}
> diff --git a/misc/sys/cdefs.h b/misc/sys/cdefs.h
> index 66d6702123..34fdd3c24a 100644
> --- a/misc/sys/cdefs.h
> +++ b/misc/sys/cdefs.h
> @@ -245,6 +245,7 @@
> #if (defined __GNUC__ && __GNUC__ >= 2) || (__clang_major__ >= 4)
>
> # define __REDIRECT(name, proto, alias) name proto __asm__ (__ASMNAME (#alias))
> +
Trivial nit, this change seems unrelated.
> # ifdef __cplusplus
> # define __REDIRECT_NTH(name, proto, alias) \
> name proto __THROW __asm__ (__ASMNAME (#alias))
> @@ -567,6 +568,8 @@
> # define __LDBL_REDIR(name, proto) ... unused__ldbl_redir
> # define __LDBL_REDIR_DECL(name) \
> extern __typeof (name) name __asm (__ASMNAME ("__" #name "ieee128"));
> +# define __LDBL_REDIRECT(name, proto, alias) \
> + extern void name proto __asm (__ASMNAME ("__" #alias "ieee128"))
Is it possible to use the existing __REDIRECT_LDBL macro instead of
adding a new one? They seem identical save for an extra expansion with
__REDIRECT_LDBL.
>
> /* Alias name defined automatically, with leading underscores. */
> # define __LDBL_REDIR2_DECL(name) \
> @@ -605,6 +608,8 @@ _Static_assert (0, "IEEE 128-bits long double requires redirection on this platf
> extern __typeof (name) name __asm (__ASMNAME (#alias));
> # define __LDBL_REDIR_DECL(name) \
> extern __typeof (name) name __asm (__ASMNAME ("__nldbl_" #name));
> +# define __LDBL_REDIRECT(name, proto, alias) \
> + extern void name proto __asm (__ASMNAME ("__nldbl_" #alias));
> # define __REDIRECT_LDBL(name, proto, alias) \
> __LDBL_REDIR1 (name, proto, __nldbl_##alias)
> # define __REDIRECT_NTH_LDBL(name, proto, alias) \
> @@ -619,6 +624,7 @@ _Static_assert (0, "IEEE 128-bits long double requires redirection on this platf
> # define __LDBL_REDIR_NTH(name, proto) name proto __THROW
> # define __LDBL_REDIR2_DECL(name)
> # define __LDBL_REDIR_DECL(name)
> +# define __LDBL_REDIRECT(name, proto, alias)
> # ifdef __REDIRECT
> # define __REDIRECT_LDBL(name, proto, alias) __REDIRECT (name, proto, alias)
> # define __REDIRECT_NTH_LDBL(name, proto, alias) \
next prev parent reply other threads:[~2023-02-13 23:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-09 17:45 Sachin Monga
2023-02-13 23:07 ` Paul E Murphy [this message]
2023-02-20 7:17 Sachin Monga
2023-02-21 10:16 ` Florian Weimer
2023-03-04 17:45 Sachin Monga
2023-03-14 16:41 ` Paul E Murphy
2023-03-27 6:27 Sachin Monga
2023-04-13 17:48 Sachin Monga
2023-04-14 13:25 ` Sachin Monga
2023-04-17 11:04 Sachin Monga
2023-04-19 18:42 Sachin Monga
2023-05-02 13:18 ` Rajalakshmi Srinivasaraghavan
2023-05-09 5:01 Sachin Monga
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fe39e07c-bf67-ac28-cca9-47125717ced6@linux.ibm.com \
--to=murphyp@linux.ibm.com \
--cc=libc-alpha@sourceware.org \
--cc=smonga@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).