This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Prefer new libm function wrappers for !LIBM_SVID_COMPAT [committed]
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Cc: nd at arm dot com
- Date: Fri, 29 Sep 2017 18:44:56 +0100
- Subject: Re: Prefer new libm function wrappers for !LIBM_SVID_COMPAT [committed]
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <alpine.DEB.2.20.1709052336210.6352@digraph.polyomino.org.uk>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 06/09/17 00:36, Joseph Myers wrote:
> The initial obsoletion of SVID libm error handling left the old
> wrappers and __kernel_standard still being used for new ports and
> static linking, just with macro definitions of _LIB_VERSION and
> matherr that meant symbols with those names were never actually used
> and the code for different error handling variants could be optimized
> out.
>
> This patch cleans things up further by eliminating the
> __kernel_standard use for new ports and static linking. Now, the old
> wrappers no longer generate any code in the !LIBM_SVID_COMPAT case,
> while the new errno-only wrappers that were added for float128 support
> are now also used for float, double and long double in that case.
>
> The changes are generally straightforward. The w_scalb*_compat
> wrappers continue to be used (scalb is obsolescent in the sense of not
> being supported for float128, but is present in supported standards -
> the 2001 edition of POSIX and earlier XSI versions - so remains
> supported for static linking and new ports, as do the float and long
> double variants that are existing GNU extensions). Those wrappers
> would only call __kernel_standard in the _LIB_VERSION == _SVID_ case.
> Since we would like to be able to compile most of glibc without
> optimization, relying on a static function whose only use is under an
> if (0) condition being optimized away to avoid an undefined
> __kernel_standard reference may not be a good idea. Thus, the
> relevant code in the scalb wrappers has LIBM_SVID_COMPAT conditionals
> added to guarantee it's not built at all in the case where
> __kernel_standard does not exist.
>
> Just as i386 has its own w_sqrt_compat.c, so w_sqrt.c is also added.
> ia64 gets dummy w_*.c to prevent those files being built where they
> would conflict with the ia64 libm, as with its existing w_*_compat.c.
>
> Conditions disabling code for !LIBM_SVID_COMPAT are needed in both the
> math/ wrappers and in the long double wrappers in ldbl-opt (to avoid
> them setting up aliases and symbol versions for undefined symbols). I
> hope that future cleanups to how libm function aliases and symbol
> versioning are done will eliminate the need for most of the ldbl-opt
> wrappers.
>
> Tested for x86_64 and x86, and with build-many-glibcs.py. Committed.
>
> 2017-09-05 Joseph Myers <joseph@codesourcery.com>
>
> * sysdeps/generic/math-type-macros-double.h: Include
> <math-svid-compat.h>.
> (__USE_WRAPPER_TEMPLATE): Define to !LIBM_SVID_COMPAT.
> * sysdeps/generic/math-type-macros-float.h: Include
> <math-svid-compat.h>.
> (__USE_WRAPPER_TEMPLATE): Define to !LIBM_SVID_COMPAT.
> * sysdeps/generic/math-type-macros-ldouble.h: Include
> <math-svid-compat.h>.
> (__USE_WRAPPER_TEMPLATE): Define to !LIBM_SVID_COMPAT.
> * math/lgamma-compat.h (BUILD_LGAMMA): Include LIBM_SVID_COMPAT
> condition.
i think this change made the gammaf, gamma, gammal
weak aliases disappear on new targets.
(at least i don't have those symbols after i rebase
the arm/ilp32 patches now, they used to come from
math/w_lgamma*_compat2.os)
i don't think it's safe to remove them for new targets
since they are still in the public math.h