public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
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) \

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