Re: [PATCH] powerpc64*: diverge sysdeps directories

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 6 Dec 2017, Gabriel F. T. Gomes wrote:

> An overview would be that I was planning to build upon the aliasing
> mechanism that you wrote for mips, s390x, etc.  This means that I was
> planning for powerpc64le to imply ldbl-128, rather than ldbl-128ibm.  This

That could probably work, but it seems likely to be more complicated than 
keeping building with -mabi=ibmlongdouble (so keeping the same sysdeps 
implications, but with additional aliases for float128 functions to be 
namespace-clean, and appropriate header magic - header magic being needed 
in any case).

(Cf. how it would be nice for ldbl-128 functions to build with the *f128 
names unconditionally and *l aliases conditionally, with most of the 
macros from float128_private.h then being eliminated.  But right now we 
have float128_private.h, which works and was certainly a much simpler 
point to get to.  Or cf. how a patch proposed a while back to make 
_FILE_OFFSET_BITS=64 the default still kept glibc itself building with 
_FILE_OFFSET_BITS=32 to avoid many problems arising.)

> >(a) it might be undesirable to have any new APIs that are explicitly for 
> >use of IBM long double in a context where long double is binary128;
> 
> My intention with the approach I described above was that the old
> implementations would be accessible through external symbol versioning
> (for instance, acosl@GLIBC_2.17) to new symbols (for instance,
> __ibm128_ieee754_acosl).  I was assuming, perhaps incorrectly, that adding
> such new symbols would be OK.

(i) New internal, non-exported symbols should certainly be OK.

(ii) It's new APIs - allowing the user to call acosibm128, for example, 
with declarations of such names in the public headers - that I think 
should be avoided.  Rather, people wishing to use IBM long double 
functions after a change of default should compile their programs with 
-mabi=ibmlongdouble.

(iii) Regarding new internal-namespace ABIs, some may be needed (or else a 
compiler extension to allow the headers to specify a symbol version to use 
with a function, but new internal-namespace ABIs would be less 
disruptive).  Adding a single set of new ABIs to be used when float128 
functions are called as long double (e.g. __acosf128, symbol version 
GLIBC_2.28) is a smaller addition than adding a new set of ABIs for 
float128 functions called as long double (e.g. acosl, symbol version 
GLIBC_2.28) *and* a new set of ABIs for ibm128 functions so they can still 
be accessed with -mabi=ibmlongdouble (e.g. __ibm128_acosl, version 
GLIBC_2.28).  Though the latter is effectively the approach followed with 
__nldbl_*.

The precise set of ABIs should more or less just be a matter of how you 
set up the libm_alias_* macros and associated Versions entries and header 
magic.  Note that I didn't convert any IBM long double files (whether in 
ldbl-128ibm or in powerpc sysdeps directories) to using 
libm_alias_ldouble, simply because it wasn't relevant for my _Float* work.

Whatever you do, being able to have test coverage for both long double 
modes would be a very good idea.  Right now, there is *no* test coverage 
for -mlong-double-64 at all, on any platform that supports it.

(iv) For functions already exported under internal-namespace ABIs, there 
should be no need to add any more such ABIs.  __isinfl and __isinff128 
fully suffice to provide isinf functionality for both types, all that's 
needed is to ensure they are declared with appropriate types in the case 
where long double is binary128 (so __isinfl would have __ibm128 argument 
then) and that the type-generic macros result in that case in *f128 being 
used for long double and *l being used for __ibm128.  Likewise for the 
__*_finite ABIs.

(You could argue there's no need for the type-generic macros to support 
__ibm128 when long double is binary128.  In that case, you just need to 
make sure __isinff128 not __isinfl gets called for long double arguments.)

> >(b) strict namespace conformance would mean mapping *l calls (when long 
> >double is binary128) to new __*f128 exports but without strict conformance 
> >they could map to *f128;
> 
> I thought of it the other way around, i.e. new __ibm128_*l symbols.

Well, if you provide new symbol versions of acosl and all the other such 
functions then it can be done that way.

> >(d) the approach used in the present ldbl-opt support for different long 
> >double formats in printf-like functions - setting a TLS variable to 
> >indicate the long double format in a compat wrapper before calling the 
> >main function - would be questionable for any new uses because of 
> >AS-safety considerations and a desire for dprintf at least to be AS-safe 
> >in some cases;
> 
> I wasn't aware of that being questionable.  I'll need more time to
> understand how to avoid this.

Arguably, internal functions taking an explicit parameter for the kind of 
long double in use (though preferably you want to arrange things so the 
parameter doesn't exist for configurations that don't need it).

(The present code doesn't even save and restore the TLS variable, just 
sets it to 1 then to 0, so would also run into problems if a function 
compiled with one long double choice were called from within a printf-like 
function compiled with a different long double choice, e.g. through the 
use of printf hooks.)

> >(e) the set of printf-like functions with ldbl-opt compatibility is 
> >incomplete (missing at least argp.h, err.h, error.h functions) and such 
> >incompleteness should not be replicated when adding a third choice of long 
> >double.
> 
> OK.  This is something else I need more time to think of.

It's probably one of the more straightforward pieces.  Review the 
installed headers to find all printf/scanf/strfmon-like functions and get 
a complete list of those without long double compatibility, and add 
compatibility for those that lack it.  Then, __LDBL_REDIR_DECL etc. macros 
can be used for all functions with such compatibility (and whatever 
approach you use for a third long double choice, those macros will need a 
powerpc version that handles having the three variants).

You can't solve the ambiguity for pre-2.4 symbol versions of such 
functions lacking compatibility, which might have been called by pre-2.4 
problems expecting long double = double or by post-2.4 programs expecting 
long double = IBM long double.  But you can add __nldbl_* variants so 
future programs built with -mlong-double=64 work correctly with these 
functions, and by adding the __LDBL_REDIR_DECL etc. calls you put the 
machinery in place for these functions to work properly when there is a 
third long double variant as well.

> >But not I think any detailed design discussions or branches to flesh out 
> >the design.
> 
> I did not understand this sentence.

It's following on from the previous sentence that started before (a) - 
"There have been a few previous discussions touching on this question ....  
But not I think any detailed design discussions ....".

> Thanks for pointing that out.  I also bumped into these files while
> working on the subdirectory renaming, but I wasn't aware that the
> mechanism of having *-le.abilist was there only because of powerpc64le.  I

It was because initially powerpc64le had different symbol versions but not 
any other need for different sysdeps directories.

-- 
Joseph S. Myers
joseph@codesourcery.com