mirror of
https://sourceware.org/git/glibc.git
synced 2024-11-26 23:10:06 +00:00
4b7d1efb51
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. |
||
|---|---|---|
| .. | ||
| aarch64 | ||
| alpha | ||
| arm | ||
| generic | ||
| gnu | ||
| hppa | ||
| i386 | ||
| ia64 | ||
| ieee754 | ||
| init_array | ||
| m68k | ||
| mach | ||
| microblaze | ||
| mips | ||
| nios2 | ||
| nptl | ||
| posix | ||
| powerpc | ||
| pthread | ||
| s390 | ||
| sh | ||
| sparc | ||
| tile | ||
| unix | ||
| wordsize-32 | ||
| wordsize-64 | ||
| x86 | ||
| x86_64 | ||