Re: [PATCH] Move declare_mgen_finite_alias definition

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 11 May 2018, Tulio Magno Quites Machado Filho wrote:

> > Something else?  What other (existing) sysdeps directories for 
> > floating-point types would you propose to use in the sysdeps directory 
> > ordering?
> 
> I didn't understand your questions.
> ldbl-128ibm-compat is the only sysdeps directory I'm proposing.

My question was about which *existing* sysdeps directories are there (from 
the set {ldbl-128, ldbl-128ibm, float128}, in particular) (and what the 
order of all these directories is).

> If I'm understanding correctly, this would require #ifdef's in every file.
> libm_alias_* are encapsulating this for you.  You can provide a single
> implementation per directory (or many if you prefer #ifdef's in the header).

libm_alias_* are indeed intended to encapsulate #ifdefs so they aren't 
needed in every file, only in certain headers.  (Cf. how they've already 
replaced lots of #if conditionals on NO_LONG_DOUBLE and on whether to 
provide compat symbols, and so eliminated various files from ldbl-opt.)

> In your proposal, do you also think ldbl-128ibm functions should be renamed
> to *ibm128?

I don't see any *need* for such renaming (either adding extra exported 
function names for them, or renaming the source files).  If extra exported 
function names *are* added for them, I don't think that significantly 
affects my point that the type-generic template machinery shouldn't be 
used for such type-specific functions (because you can arrange for 
libm_alias_ldouble to add those aliases when those files are built with 
-mabi=ibmlongdouble and arrange for it to be used in ldbl-128ibm).

> I'm not against your suggestion, but I'm afraid it would require a lot more
> code.  Does that make sense?

I don't think it should require significantly more code to use 
libm_alias_* macros in place of type-generic ones (the type-generic ones 
largely wrap the libm_alias_* ones as far as possible anyway).

If you think things can't work without the type-generic machinery being 
used for this, I think you need to make the subsequent patches available 
somewhere and explain in more detail what the obstacles would be to making 
libm_alias_* work for them.

> > The obvious starting point for binary128 long double support on 
> > powerpc64le would seem to me to be just to get the installed headers to 
> > arrange for calls to *l to be asm-redirected to call *f128.  That doesn't 
> > quite work because
> 
> Exactly.  We tried that way.
> 
> > (a) it's not namespace-clean and (b) there are a few 
> > obsolescent functions with no public *f128 names which shouldn't get such 
> > names, but are part of the *l API so need to be available for long double 
> > in the -mabi=ieeelongdouble case, so you may actually want to call new 
> > __*f128 names instead (so get libm_alias_float128* to define those, maybe 
> > with new macro variants as needed, and watching out for cases where 
> > __*f128 already exists but isn't what *f128 is aliased to).
> 
> Indeed. That's one of the reasons we created the new directory.

I suspect my suggestion of using __*ieee128 or similar for the exported 
names should avoid all the complications around __*f128 already existing.  
A new directory *is*, I expect, still needed for the few cases of 
functions in the long double API but not the _Float128 API (including e.g. 
new variants of nexttowardf and nexttoward that are needed for the new 
long double format).

-- 
Joseph S. Myers
joseph@codesourcery.com