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:
>
>> > 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).
We're adding the new file on top of Implies:
ieee754/ldbl-128ibm-compat
ieee754/ldbl-128ibm
ieee754/ldbl-opt
ieee754/dbl-64
ieee754/flt-32
ieee754/float128
>> 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).
Agreed.
The question is: assuming you concluded you need new *ibm128 symbols,
should the changes affect everyone using ldbl-128ibm or just those using
ieee754/ldbl-128ibm-compat?
That's why we're using them.
>> 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).
I was misunderstanding you.
Agreed.
> 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.
OK. That will have to wait a little more.
> 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).
OK.
I have to think more about this and go back to my notes.
Thanks!
--
Tulio Magno