This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Move declare_mgen_finite_alias definition
Joseph Myers <joseph@codesourcery.com> writes:
> On Fri, 11 May 2018, Tulio Magno Quites Machado Filho wrote:
>> > 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).
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.
--
Tulio Magno