Define and use a libm_alias_float macro.
Fully supporting TS 18661-3 _FloatN / _FloatNx types in the cases
where they have the same format as other supported types (in line with
the principles described at
<https://sourceware.org/ml/libc-alpha/2017-01/msg00333.html>) means
adding a lot of function aliases to libm (and a few to libc). float
functions will have *f32 aliases, double functions will have *f32x and
*f64 aliases, long double functions may have *f64x, *f128 or both
aliases depending on the configuration, float128 functions have have
*f64x aliases depending on the configuration.
At present, most individual libm functions have their own weak_alias
calls to define the public names for those functions. For TS 18661-3
support, it is desirable that functions not all need to duplicate the
logic for which alias names to define.
Thus, common macros for defining the public aliases to a libm function
make sense. In the double and long double cases, such macros will
also help simplify existing code (with LONG_DOUBLE_COMPAT
etc. conditionals), by eliminating existing conditionals and ldbl-opt
/ ldbl-64-128 wrappers (using the generated ldbl-compat-choose.h to
allow a single macro definition to expand appropriately for each
symbol depending on LONG_DOUBLE_COMPAT for that symbol).
This patch starts the process of adding such macros with a
straightforward case: a libm_alias_float macro, initially only used in
the case of type-generic templates, to define aliases for float
functions (currently just the *f public names, in future also *f32).
Future patches are intended to add such macros for other types and to
extend the cases in which they are used, with a view to as many places
as possible using them before support for _FloatN / _FloatNx aliases
is enabled. (I think it's inevitable that some places doing
architecture-specific things with aliases and symbol versioning may
end up needing to replicate logic for the new aliases, but hopefully
the number of such places can be kept to a minimum.)
The libm_alias_float macro takes unsuffixed names for both the
internal and public function names. The need for unsuffixed public
names is obvious, since such macros will end up defining multiple
public names with different suffixes. Unsuffixed internal names are
because I expect the ldbl-128 functions to end up in a form that
always defines *f128 names and sometimes also defines *l names - with
the main internal names being e.g. __ieee754_<func>f128 (so many
macros in float128_private.h can go away). But __ieee754_<func>l
aliases will still be needed for e.g. use from math/ complex
functions, meaning the alias macro needs to see just __ieee754_<func>
as internal name so it can create an alias based on that name. Since
libm_alias_float128 will thus need the unsuffixed internal name, it
seems to make sense for all such macros to receive the unsuffixed
name.
Tested for x86_64. Also tested with build-many-glibcs.py that
installed stripped shared libraries are unchanged by the patch.
* sysdeps/generic/libm-alias-float.h: New file.
* sysdeps/generic/math-type-macros-float.h: Include
<libm-alias-float.h>.
[!declare_mgen_alias] (declare_mgen_alias): Define macro.
2017-09-11 23:21:25 +00:00
|
|
|
/* Define aliases for libm float functions.
|
2018-01-01 00:32:25 +00:00
|
|
|
Copyright (C) 2017-2018 Free Software Foundation, Inc.
|
Define and use a libm_alias_float macro.
Fully supporting TS 18661-3 _FloatN / _FloatNx types in the cases
where they have the same format as other supported types (in line with
the principles described at
<https://sourceware.org/ml/libc-alpha/2017-01/msg00333.html>) means
adding a lot of function aliases to libm (and a few to libc). float
functions will have *f32 aliases, double functions will have *f32x and
*f64 aliases, long double functions may have *f64x, *f128 or both
aliases depending on the configuration, float128 functions have have
*f64x aliases depending on the configuration.
At present, most individual libm functions have their own weak_alias
calls to define the public names for those functions. For TS 18661-3
support, it is desirable that functions not all need to duplicate the
logic for which alias names to define.
Thus, common macros for defining the public aliases to a libm function
make sense. In the double and long double cases, such macros will
also help simplify existing code (with LONG_DOUBLE_COMPAT
etc. conditionals), by eliminating existing conditionals and ldbl-opt
/ ldbl-64-128 wrappers (using the generated ldbl-compat-choose.h to
allow a single macro definition to expand appropriately for each
symbol depending on LONG_DOUBLE_COMPAT for that symbol).
This patch starts the process of adding such macros with a
straightforward case: a libm_alias_float macro, initially only used in
the case of type-generic templates, to define aliases for float
functions (currently just the *f public names, in future also *f32).
Future patches are intended to add such macros for other types and to
extend the cases in which they are used, with a view to as many places
as possible using them before support for _FloatN / _FloatNx aliases
is enabled. (I think it's inevitable that some places doing
architecture-specific things with aliases and symbol versioning may
end up needing to replicate logic for the new aliases, but hopefully
the number of such places can be kept to a minimum.)
The libm_alias_float macro takes unsuffixed names for both the
internal and public function names. The need for unsuffixed public
names is obvious, since such macros will end up defining multiple
public names with different suffixes. Unsuffixed internal names are
because I expect the ldbl-128 functions to end up in a form that
always defines *f128 names and sometimes also defines *l names - with
the main internal names being e.g. __ieee754_<func>f128 (so many
macros in float128_private.h can go away). But __ieee754_<func>l
aliases will still be needed for e.g. use from math/ complex
functions, meaning the alias macro needs to see just __ieee754_<func>
as internal name so it can create an alias based on that name. Since
libm_alias_float128 will thus need the unsuffixed internal name, it
seems to make sense for all such macros to receive the unsuffixed
name.
Tested for x86_64. Also tested with build-many-glibcs.py that
installed stripped shared libraries are unchanged by the patch.
* sysdeps/generic/libm-alias-float.h: New file.
* sysdeps/generic/math-type-macros-float.h: Include
<libm-alias-float.h>.
[!declare_mgen_alias] (declare_mgen_alias): Define macro.
2017-09-11 23:21:25 +00:00
|
|
|
This file is part of the GNU C Library.
|
|
|
|
|
|
|
|
|
|
The GNU C Library is free software; you can redistribute it and/or
|
|
|
|
|
modify it under the terms of the GNU Lesser General Public
|
|
|
|
|
License as published by the Free Software Foundation; either
|
|
|
|
|
version 2.1 of the License, or (at your option) any later version.
|
|
|
|
|
|
|
|
|
|
The GNU C Library is distributed in the hope that it will be useful,
|
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
|
Lesser General Public License for more details.
|
|
|
|
|
|
|
|
|
|
You should have received a copy of the GNU Lesser General Public
|
|
|
|
|
License along with the GNU C Library; if not, see
|
|
|
|
|
<http://www.gnu.org/licenses/>. */
|
|
|
|
|
|
|
|
|
|
#ifndef _LIBM_ALIAS_FLOAT_H
|
|
|
|
|
#define _LIBM_ALIAS_FLOAT_H
|
|
|
|
|
|
2017-12-06 22:14:09 +00:00
|
|
|
#include <bits/floatn.h>
|
|
|
|
|
|
2017-10-10 21:29:11 +00:00
|
|
|
/* Define _FloatN / _FloatNx aliases for a float libm function that
|
|
|
|
|
has internal name FROM ## f ## R and public names TO ## suffix ## R
|
|
|
|
|
for each suffix of a supported _FloatN / _FloatNx floating-point
|
|
|
|
|
type with the same format as float. */
|
2017-12-06 22:14:09 +00:00
|
|
|
#if __HAVE_FLOAT32 && !__HAVE_DISTINCT_FLOAT32
|
|
|
|
|
# define libm_alias_float_other_r(from, to, r) \
|
|
|
|
|
weak_alias (from ## f ## r, to ## f32 ## r)
|
|
|
|
|
#else
|
|
|
|
|
# define libm_alias_float_other_r(from, to, r)
|
|
|
|
|
#endif
|
2017-10-10 21:29:11 +00:00
|
|
|
|
|
|
|
|
/* Likewise, but without the R suffix. */
|
|
|
|
|
#define libm_alias_float_other(from, to) \
|
|
|
|
|
libm_alias_float_other_r (from, to, )
|
|
|
|
|
|
Define and use a libm_alias_float macro.
Fully supporting TS 18661-3 _FloatN / _FloatNx types in the cases
where they have the same format as other supported types (in line with
the principles described at
<https://sourceware.org/ml/libc-alpha/2017-01/msg00333.html>) means
adding a lot of function aliases to libm (and a few to libc). float
functions will have *f32 aliases, double functions will have *f32x and
*f64 aliases, long double functions may have *f64x, *f128 or both
aliases depending on the configuration, float128 functions have have
*f64x aliases depending on the configuration.
At present, most individual libm functions have their own weak_alias
calls to define the public names for those functions. For TS 18661-3
support, it is desirable that functions not all need to duplicate the
logic for which alias names to define.
Thus, common macros for defining the public aliases to a libm function
make sense. In the double and long double cases, such macros will
also help simplify existing code (with LONG_DOUBLE_COMPAT
etc. conditionals), by eliminating existing conditionals and ldbl-opt
/ ldbl-64-128 wrappers (using the generated ldbl-compat-choose.h to
allow a single macro definition to expand appropriately for each
symbol depending on LONG_DOUBLE_COMPAT for that symbol).
This patch starts the process of adding such macros with a
straightforward case: a libm_alias_float macro, initially only used in
the case of type-generic templates, to define aliases for float
functions (currently just the *f public names, in future also *f32).
Future patches are intended to add such macros for other types and to
extend the cases in which they are used, with a view to as many places
as possible using them before support for _FloatN / _FloatNx aliases
is enabled. (I think it's inevitable that some places doing
architecture-specific things with aliases and symbol versioning may
end up needing to replicate logic for the new aliases, but hopefully
the number of such places can be kept to a minimum.)
The libm_alias_float macro takes unsuffixed names for both the
internal and public function names. The need for unsuffixed public
names is obvious, since such macros will end up defining multiple
public names with different suffixes. Unsuffixed internal names are
because I expect the ldbl-128 functions to end up in a form that
always defines *f128 names and sometimes also defines *l names - with
the main internal names being e.g. __ieee754_<func>f128 (so many
macros in float128_private.h can go away). But __ieee754_<func>l
aliases will still be needed for e.g. use from math/ complex
functions, meaning the alias macro needs to see just __ieee754_<func>
as internal name so it can create an alias based on that name. Since
libm_alias_float128 will thus need the unsuffixed internal name, it
seems to make sense for all such macros to receive the unsuffixed
name.
Tested for x86_64. Also tested with build-many-glibcs.py that
installed stripped shared libraries are unchanged by the patch.
* sysdeps/generic/libm-alias-float.h: New file.
* sysdeps/generic/math-type-macros-float.h: Include
<libm-alias-float.h>.
[!declare_mgen_alias] (declare_mgen_alias): Define macro.
2017-09-11 23:21:25 +00:00
|
|
|
/* Define aliases for a float libm function that has internal name
|
|
|
|
|
FROM ## f ## R and public names TO ## suffix ## R for each suffix
|
|
|
|
|
of a supported floating-point type with the same format as float.
|
|
|
|
|
This should only be used for functions where such public names
|
|
|
|
|
exist for _FloatN types, not for implementation-namespace exported
|
|
|
|
|
names (where there is one name per format, not per type) or for
|
|
|
|
|
obsolescent functions not provided for _FloatN types. */
|
|
|
|
|
#define libm_alias_float_r(from, to, r) \
|
2017-12-06 22:14:09 +00:00
|
|
|
weak_alias (from ## f ## r, to ## f ## r); \
|
2017-10-10 21:29:11 +00:00
|
|
|
libm_alias_float_other_r (from, to, r)
|
Define and use a libm_alias_float macro.
Fully supporting TS 18661-3 _FloatN / _FloatNx types in the cases
where they have the same format as other supported types (in line with
the principles described at
<https://sourceware.org/ml/libc-alpha/2017-01/msg00333.html>) means
adding a lot of function aliases to libm (and a few to libc). float
functions will have *f32 aliases, double functions will have *f32x and
*f64 aliases, long double functions may have *f64x, *f128 or both
aliases depending on the configuration, float128 functions have have
*f64x aliases depending on the configuration.
At present, most individual libm functions have their own weak_alias
calls to define the public names for those functions. For TS 18661-3
support, it is desirable that functions not all need to duplicate the
logic for which alias names to define.
Thus, common macros for defining the public aliases to a libm function
make sense. In the double and long double cases, such macros will
also help simplify existing code (with LONG_DOUBLE_COMPAT
etc. conditionals), by eliminating existing conditionals and ldbl-opt
/ ldbl-64-128 wrappers (using the generated ldbl-compat-choose.h to
allow a single macro definition to expand appropriately for each
symbol depending on LONG_DOUBLE_COMPAT for that symbol).
This patch starts the process of adding such macros with a
straightforward case: a libm_alias_float macro, initially only used in
the case of type-generic templates, to define aliases for float
functions (currently just the *f public names, in future also *f32).
Future patches are intended to add such macros for other types and to
extend the cases in which they are used, with a view to as many places
as possible using them before support for _FloatN / _FloatNx aliases
is enabled. (I think it's inevitable that some places doing
architecture-specific things with aliases and symbol versioning may
end up needing to replicate logic for the new aliases, but hopefully
the number of such places can be kept to a minimum.)
The libm_alias_float macro takes unsuffixed names for both the
internal and public function names. The need for unsuffixed public
names is obvious, since such macros will end up defining multiple
public names with different suffixes. Unsuffixed internal names are
because I expect the ldbl-128 functions to end up in a form that
always defines *f128 names and sometimes also defines *l names - with
the main internal names being e.g. __ieee754_<func>f128 (so many
macros in float128_private.h can go away). But __ieee754_<func>l
aliases will still be needed for e.g. use from math/ complex
functions, meaning the alias macro needs to see just __ieee754_<func>
as internal name so it can create an alias based on that name. Since
libm_alias_float128 will thus need the unsuffixed internal name, it
seems to make sense for all such macros to receive the unsuffixed
name.
Tested for x86_64. Also tested with build-many-glibcs.py that
installed stripped shared libraries are unchanged by the patch.
* sysdeps/generic/libm-alias-float.h: New file.
* sysdeps/generic/math-type-macros-float.h: Include
<libm-alias-float.h>.
[!declare_mgen_alias] (declare_mgen_alias): Define macro.
2017-09-11 23:21:25 +00:00
|
|
|
|
|
|
|
|
/* Likewise, but without the R suffix. */
|
|
|
|
|
#define libm_alias_float(from, to) libm_alias_float_r (from, to, )
|
|
|
|
|
|
|
|
|
|
#endif
|