Re: Defining macros for function symbol versions

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 8 Dec 2016, Steven Munroe wrote:

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

If some individual actually working on float128 changes, and familiar with 
the technical details of relevant areas of glibc, wishes to raise specific 
concerns, they are free to do so.  That means concerns of the form "I'm 
planning global changes of this form to these 100 places in glibc and 
those might conflict with global changes of this other form to those 
places implied by your proposal.".  Or if there is an issue with the 
design of a particular patch contradicting directions planned for 
float128, the relevant person should respond to that particular patch 
posting in a timely manner.

Things work much better when the people working on patches, the people 
posting those patches, the people engaging with other relevant community 
development discussions and the people familiar with the relevant 
technical details in glibc are all the same.

I'd give much higher weight to detailed technical concerns expressed by 
Paul Murphy - who has shown excellent technical understanding of the 
relevant areas of glibc, and excellent engagement with the community in 
the course of float128 infrastructure work (including at least once 
rewriting a patch after I'd already approved it, because he'd found a 
better way of achieving the desired result).  Whereas I consider indirect 
reports lacking in technical detail essentially unactionable.

While there is no requirement for development to take place on public 
branches, if the float128 patches had been developed on such branches then 
any rebasings would have been more visible and it would have been much 
clearer what sorts of changes actually affect the same areas.

(To be clear, the response to a substantive technical concern about 
clashing global changes might well be to try to work out a way in which 
e.g. the global changes from one patch series can be macroized in a way 
that works for the other series as well, and go in early.  Or to conclude 
that at least one set of global changes is objectively inappropriate, 
independent of the other.)

> Again you specifically asked for __float128 support in POWER.

What specific mailing list message are you reading that way?  I suspect it 
is being read out of context or with insufficient attention to the full 
details of what I wrote.  I did not *ask* for the support.  Given the 
stated desire to provide libm-like functionality for this type (other than 
through a whole new incompatible libc/libm ABI), I *advised* on 
appropriate directions for supporting it in the GNU system (both in API 
and implementation terms), consistent with emerging standards but 
including things that seem useful outside those standards (e.g. supporting 
the functions with the __float128 type name for compilers not supporting 
_Float128).

I'd like to see support for these interfaces in glibc on relevant 
architectures.  I'm not particularly concerned about when it gets in or 
who does it (but if it's implemented in the first instance for POWER, I'd 
likely follow up by adding the support on x86_64 and x86 myself).  We do 
time-based releases in glibc, so whether something is in 2.25 depends on 
whether it was ready and achieved consensus and got committed before the 
end of December.  (Exactly the same applies to my TS 18661-1 work - I'm 
not particularly concerned with which release has a given function, as 
long as the API set in a release is vaguely coherent, e.g. not having a 
function only for some types but not others.)

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

Well, you can see from git logs of math/Versions that I added no 18661-1 
functions between canonicalize on 26 Oct and setpayload on 19 Nov, for 
example, which would have been time for several iterations of float128 
patch series with no rebasing for any of my 18661-1 patches (if you want, 
you can count the interval as starting on 28 Oct when I added SNAN macros, 
since those would imply a corresponding SNANF128 addition).  And there 
have been plenty of gaps of a week or so.

Rebasing for routine things such as changes to lists of functions or tests 
in Makefiles is expected for anyone with out-of-tree patches.  It 
shouldn't take more than a few minutes each time to update float128 
patches for my changes.

I also see a gap between the last float128 patch series posted on 9 Nov, 
which I responded to within a few hours, and the first response to any of 
my comments, on 5 Dec.  That gap is half of the total time that was 
available as of 9 Nov for getting new features in 2.25 (effectively it's 
rather more than half).  Naturally such delays in responding to patch 
reviews do not look like showing much concern for getting features in a 
particular release.

> Since you seemed to be unaware, I thought I should bring this to your
> attention.

I'm aware of what takes place on the mailing list and in the repository.

-- 
Joseph S. Myers
joseph@codesourcery.com