Re: Obsolete matherr, _LIB_VERSION, libieee.a

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

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?).