This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]