This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Defining macros for function symbol versions
On Wed, 2016-12-07 at 22:19 +0000, Joseph Myers wrote:
> 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).
>
That is not what I am hearing from the team. What I hear is the constant
disruption and re-porting.
I am asking for a little breathing room here. It seems like small thing
the ask.
> > 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.
>
In your mind only. We never agreed to make TS 18661 a priority over
__float128. For us TS 18661 was always a secondary and later goal.
For power __float128 is an important part of enabling the POWER platform
for the next processor. With hard deadlines.
Again you specifically asked for __float128 support in POWER.
> 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.
>
Again this is not what the team experienced.
Since you seemed to be unaware, I thought I should bring this to your
attention.
> 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.)
>
This is just the latest example.