This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] Support for type-generic libm function implementations libm
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Tue, 14 Jun 2016 21:20:21 +0000
- Subject: Re: [RFC] Support for type-generic libm function implementations libm
- Authentication-results: sourceware.org; auth=none
- References: <55807bea-73b6-2b68-df1d-bf94b841be49 at linux dot vnet dot ibm dot com>
On Tue, 14 Jun 2016, Paul E. Murphy wrote:
> This builds from https://sourceware.org/ml/libc-alpha/2016-06/msg00550.html
> to further tweak the math Makefile.
> As it stands, there is much duplication when building
> wrappers for IEEE functions and complex functions.
> With a little creativity, this can reduce much
> redundant source, and simplify supporting new types.
> Only two platforms (alpha and m68k) override complex
> functions. Both should work with the approach.
What about the ldbl-opt code that wraps complex functions? Does that need
> This defines two new classes of libm objects. g for
> generated objects, and t for templates to generate
> those objects.
Note that right now t_* is used in libm for generated tables....
> Note, I have not tested this on alpha. If anyone can
> assist me in testing (or just point out a reasonable
> mechanism to do it myself) it would be much
> appreciated. Likewise for m68k.
I don't really like how platforms needing to override a file have to
override the template file with something containing conditionals on the
type. Is it hard to arrange things so that: if an appropriately named
file with a name depending on the type is present in sysdeps, that file is
used instead of the template (so compiling from a per-type file in sysdeps
takes precedence over compiling from the template)?
On whatever platforms you have tested, did you make sure the installed
stripped shared libraries were unchanged (or at least that the relevant
objects were after stripping debug info, if the changes have the effect of
changing the order in which objects are linked into libm.so)?
> +#if M_TYPE == M_FLOAT
> +# define M_PFX FLT
> +# define M_LIT f
> +# define M_SUF(c) c ## f
> +# define FLOAT float
> +#elif M_TYPE == M_DOUBLE
> +# define M_PFX DBL
> +# define M_LIT
> +# define M_SUF(c) c
> +# define FLOAT double
> +#elif M_TYPE == M_LDOUBLE
> +# define M_PFX LDBL
> +# define M_LIT L
> +# define M_SUF(c) c ## l
> +# define FLOAT long double
> +# error Error: M_TYPE must be defined before including
I'd expect more macros making use of M_PFX, M_LIT - are those intended to
be added as needed? I'd also expect macros relating to use of M_*
constants from <math.h>. Probably the undefine / redefine of LDBL_EPSILON
for IBM long double also belongs in this header.
> +M_SUF (__carg) (__complex__ FLOAT x)
You can't use __complex__ FLOAT because that won't work with __float128
(as it's a built-in typedef not a keyword; GCC bug 32187). Instead, you
need another macro for the complex type.
Joseph S. Myers