This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Obsolete matherr, _LIB_VERSION, libieee.a
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org
- Date: Mon, 21 Aug 2017 17:15:55 -0300
- Subject: Re: Obsolete matherr, _LIB_VERSION, libieee.a
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.2.20.1708172128090.26254@digraph.polyomino.org.uk>
On 17/08/2017 18:29, Joseph Myers wrote:
> This patch obsoletes support for SVID libm error handling (the system
> where a user-defined function matherr is called on a libm function
> error; only enabled if you also set _LIB_VERSION = _SVID_ or
> _LIB_VERSION = _XOPEN_) and the use of the _LIB_VERSION global
> variable to control libm error handling. matherr and _LIB_VERSION are
> made into compat symbols, not supported for new ports or for static
> linking. The libieee.a object file (which sets _LIB_VERSION = _IEEE_,
> so disabling errno setting for some functions) is also removed, and
> all the related definitions are removed from math.h.
>
> The manual already recommends against using matherr, and it's already
> not supported for _Float128 functions (those use new wrappers that
> don't support matherr, only errno) - this patch means that it becomes
> possible to e.g. add sinf32 as an alias to sinf without that resulting
> in undesired matherr support in sinf32 for existing glibc ports.
> matherr support is not part of any standard supported by glibc (it was
> removed in XPG4).
>
> Because matherr is a function to be defined by the user, of course
> user programs defining such a function will still continue to link; it
> just quietly won't be used. If they try to write to the library's
> copy of _LIB_VERSION to enable SVID error handling, however, they will
> get a link error (but if they define their own _LIB_VERSION variable,
> they won't).
>
> I expect the most likely case of build failures from this patch to be
> programs with unconditional cargo-culted uses of -lieee (based on a
> notion of "I want IEEE floating point", not any actual requirement for
> that library).
>
> Ideally, the new-port-or-static-linking case would use the new
> wrappers used for _Float128. This is not implemented in this patch,
> because of the complication of architecture-specific (powerpc32 and
> sparc) sqrt wrappers that use _LIB_VERSION and __kernel_standard
> directly. Thus, the old wrappers and __kernel_standard are still
> built unconditionally, and _LIB_VERSION still exists in static libm.
> But when the old wrappers and __kernel_standard are built in the
> non-compat case, _LIB_VERSION and matherr are defined as macros so
> code to support those features isn't actually built into static libm
> or new ports' shared libm after this patch.
>
> I intend to move to the new wrappers for static libm and new ports in
> followup patches. I believe the sqrt wrappers for powerpc32 and sparc
> can reasonably be removed. GCC already optimizes the normal case of
> sqrt by generating code that uses a hardware instruction and only
> calls the sqrt function if the argument was negative (if
> -fno-math-errno, of course, it just uses the hardware instruction
> without any check for negative argument being needed). Thus those
> wrappers will only actually get called in the case of negative
> arguments, which is not a case it makes sense to optimize for. But
> even without removing the powerpc32 and sparc wrappers it should still
> be possible to move to the new wrappers for static libm and new ports,
> just without having those dubious architecture-specific optimizations
> in static libm.
>
> Everything said about matherr equally applies to matherrf and matherrl
> (IA64-specific, undocumented), except that the structure of IA64 libm
> means it won't be converted to using the new wrappers (it doesn't use
> the old ones either, but its own error-handling code instead).
>
> As with other tests of compat symbols, I expect test-matherr and
> test-matherr-2 to need to become appropriately conditional once we
> have a system for disabling such tests for ports too new to have the
> relevant symbols.
>
> Tested for x86_64 and x86, and with build-many-glibcs.py. Any
> comments before I commit this and move on to the followup patches?
Joseph I am seeing the failure:
../sysdeps/ieee754/k_standard.c: In function ‘__kernel_standard’:
../sysdeps/ieee754/k_standard.c:943:12: error: ‘exc.retval’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
return exc.retval;
~~~^~~~~~~
When building 'math/k_standard.o' with GCC 7.1.1 and 8.0.0 (built
with build-many-glibcs.py). with patch on master. GCC 5.4/6.2.1 does
not show this issue.
I would say this is due the a missing default for the switch case,
but I can't tell exactly why GCC does not emit this same issue with
_LIBC_VERSION being an external variable instead of a define (maybe
a compiler bug?).