Re: Defining macros for function symbol versions

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 7 Dec 2016, Steven Munroe wrote:

> This all seems to be very disruptive change, this late in the 2.25
> cycle.

I disagree.  Thinking several steps ahead about what will be needed for 
future changes, and trying to build consensus among people expert in the 
relevant technical details, doesn't disrupt anything.  Creating such a 
header doesn't disrupt anything.  Using it in 
sysdeps/ieee754/ldbl-opt/math-type-macros-double.h doesn't disrupt 
anything either.  Even refactoring how aliases are defined for double 
functions doesn't disrupt anything and likely wouldn't happen in this 
release cycle.  It's only changing how aliases are defined for ldbl-128 
that could be disruptive (and I'm operating on the expectation that by 
then there will be a float128 implementation in the tree, which I'll then 
end up reworking on the basis of functions always defining *f128 names and 
sometimes defining *l as aliases to those).

> Given that TS 18661 is an emerging stand that very few applications need
> or intend to use. It seems prudent to defer further TS 18661 work until
> 2.26 and allow our float128 (which you specificity asked for) to proceed
> and deliver key components before 2.25 closes.

There's a false distinction here.  float128 support is largely part of TS 
18661-3 support.  Supporting it as a distinct format is somewhat separate 
from the aliases being discussed here, but they fit together in the same 
TS 18661 theme.

The consensus-setting for TS 18661-1 functions 
<https://sourceware.org/ml/libc-alpha/2016-06/msg00421.html> (which you'll 
note was thinking ahead, two months before I started adding such 
functions) included "If float128 support had gone in first, 
implementations would be expected to include the *f128 API; if it had not, 
the float128 work would be expected to add the *f128 versions of relevant 
new functions that had been added to glibc[*].", which is essentially just 
repeating standard glibc practice: anyone contributing patches needs to 
produce patches that are appropriate in the context of master as it is at 
the time of contribution.

There have also been plenty of gaps between additions of 18661-1 functions 
in which there was time for submitting float128 patches.

I really don't see sNaN fixes for fmax/fmin and adding 
FE_SNANS_ALWAYS_SIGNAL, fmaxmag*, fminmag*, roundeven and *fromfp* (a 
rough list of the next 18661-1 pieces I plan, which may or may not get in 
for 2.25) as being plausibly disruptive to float128 work (fmaxmag* and 
fminmag* will use type-generic templates anyway).  (It's less likely I'll 
get to the functions that round result to narrower type for 2.25, given 
the infrastructure preparations they require, but I don't see those 
preparations as disruptive to float128 either, and as stated in the 
aforementioned consensus-setting, float128 work would *not* be expected to 
include float128 versions of these functions, since the _FloatN / _FloatNx 
versions of those functions are associated with *pairs* of types and so 
don't become relevant to glibc until more than one such type is supported 
in glibc.)

-- 
Joseph S. Myers
joseph@codesourcery.com