Re: [RFC PATCH 0/5] *printf/*scanf functions for the long double migration on powerpc64le

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 28 May 2018, Gabriel F. T. Gomes wrote:

> You presumed correctly, indeed.  I think that Zack's proposal is the right
> thing to have in the end.  However, I also expected that rebuilding these
> files with -mabi=ieeelongdouble had the advantage of being potentially
> easier to get right, because I wouldn't need to touch anything from the
> current implementation.  Besides that, I also expect that it will be
> faster to get done, because it only adds files to the build, and since this
> is useful for POWER9 users, getting it done sooner than later is something
> that we need.
> 
> Taking this "timing" perspective into account and also that there seems to
> be other problems that would need fixing before Zack's proposal can be
> fully complete [1], would it be OK to have these functions added as new
> implementations in a first step?  Afterwards, with "timing" concerns out
> of the way, we could work together (if Zack is OK with that) on the
> cleanup (for nldbl and ieee128-on-powerpc).
> 
> [1] https://sourceware.org/ml/libc-alpha/2018-03/msg00554.html

I don't think tests for hidden annotation issues (or fixes for existing 
such issues) are needed in order to make the move to explicit flags here; 
the patches just need reviewing / updating to follow the rules described 
at <https://sourceware.org/ml/libc-alpha/2018-03/msg00552.html> for any 
new internal functions they add.  I'm also not convinced that building 
files twice, and making sure that all calls within those files end up 
pointed to the new ieee128 internal functions when needed, is any easier 
to get right than passing explicit flags, and making sure that calls 
within those files call appropriate other internal functions that take 
those flags - especially given that Zack's patches already do most of 
what's required regarding passing those flags around (new work for argp.h 
/ err.h / error.h printf-like functions being needed in any case).

So rather than going down the dead-end route of building the files twice 
and so complicating the subsequent cleanup to use explicit flags, I think 
the support for explicit flags (along the lines of Zack's patches) should 
be added first.  That is, first in the commit sequence on master.  You 
could of course maintain multiple public branches, one with the latest 
version of Zack's patches and one with ieee128 patches built on top of 
that, working on them in parallel and posting for review patches from each 
branch as and when they are ready, with patches from the ieee128 branch 
not actually being able to go on master until all the changes they depend 
on are also in master.

Some changes could be independent of both of the above to some extent - 
for example, the argp.h / err.h / error.h ldbl-opt support, or the header 
changes to support calling appropriate ieee128 functions on the basis that 
the actual changes defining new macros to activate the new header code for 
powerpc64le would go in last of all along with the actual addition of all 
the new functions to the ABI.  So there could be rather more than two 
branches involved while development is active, all being developed and 
having patches posted, reviewed and revised in parallel.

-- 
Joseph S. Myers
joseph@codesourcery.com