Re: [PATCH] Move declare_mgen_finite_alias definition

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 15 May 2018, Tulio Magno Quites Machado Filho wrote:

> >> > (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).
> 
> When you say that a namespace is clean, are you saying that new symbols should
> only be created as required?  e.g.  __cosieee128 should not exist because there
> is already __cosf128.

No, I'm not saying this.

1. The namespace issue is that C11 doesn't reserve the name cosf128, so 
just redirecting cosl to cosf128 wouldn't be namespace-clean for that 
reason.

2. __cosf128 and __cosieee128 are both reserved.  Now, we don't generally 
want multiple reserved-namespace names *pointing to the same function* 
exported from glibc - that makes the dynamic symbol table in the installed 
shared libraries larger than necessary.  So we don't want any new 
__issignalingieee128, for example, because __issignalingf128 is fully 
sufficient whether the type is called _Float128 or long double.  But 
__cosf128 is a purely internal symbol.  So exporting __cosieee128 would 
not mean redundant reserved-namespace exports - and would avoid 
complications around some functions already having an internal __*f128 
name, some not having it, and some such internal names, where they exist, 
having the *f128 alias point to them, while others have the *f128 alias 
point to a wrapper.  It would also, I expect, avoid the need to have new 
*l versions for the binary128 functions, and thus to have new __*ibm128 
exports, so reducing the total number of exports needed.

(If you wanted to support users declaring *l functions directly without 
including <math.h> - which of course doesn't work at present with 
-mlong-double-64 - you'd need some other mechanism for achieving the 
redirections, as a plain *l call with no redirection will end up at the 
default symbol version for that function.)

-- 
Joseph S. Myers
joseph@codesourcery.com