Re: [PATCH] Patch 2 of 2 for ILP32 aarch64

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 12 Jun 2017, Zack Weinberg wrote:

> > That would mean building from a checkout requires a range of tools, in
> > precise versions, that are not currently required.
> 
> I tend to think that == dependencies on tools should automatically be
> considered bugs.  >= dependencies are OK, and I am actually fine with
> requiring bleeding-edge tools for working with a git checkout (as
> opposed to building a release).  I don't see a lot of value in
> facilitating _development_ in old LTS-type environments.

There's a difference between old LTS, and the current LTS release of a 
distribution (which might still be a couple of years old).  And some 
dependencies may be on things not in any release at all.

> > That would make libm testing from a checkout very slow
> > (auto-libm-test-out-cacos and auto-libm-test-out-cacosh take about 80
> > minutes each to generate on my system; at present, you only care about
> > that if you're changing tests for those functions), as well as requiring
> > development headers and libraries for an unreleased version of MPC (for an
> > mpc_atan bug fix affecting glibc tests).
> 
> These are expectations for the math functions, computed with an
> independent, extra-high-precision implementation, right?
> 
> It might make sense to maintain these separately from the glibc
> repository.  You could test _any_ math library with them, after all?

In theory.  gen-auto-libm-tests is closely tied to glibc's particular 
choices regarding e.g. when underflow exceptions should be allowed or 
permitted very close to the underflow threshold, and various changes would 
be needed to defer such choices to a later stage than when the 
expectations are generated.  It's also closely tied to the 
libm-test-driver and gen-libm-test.pl; I don't expect any of that to work 
as-is with another libm implementation.

> I'd still structure that repo with no generated files checked in on
> master, but have an alternative trunk that _just_ contained the
> generated expectations, with parallel tags.  Then glibc could pull
> that in as a submodule as appropriate.  (Or something like that.  Just
> thinking out loud here.)

I think things such as submodules are best avoided for glibc (as 
complicating tagging, branching, atomic committing etc. across the whole 
tree).

-- 
Joseph S. Myers
joseph@codesourcery.com