This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Remove non-add-on Banner files
Joseph Myers <joseph@codesourcery.com> writes:
> On Wed, 27 Sep 2017, Tulio Magno Quites Machado Filho wrote:
>
>> > I don't see libdfp as being of any relevance to the possible removal of
>> > the add-ons mechanism. It used to be a glibc add-on, but that was
>> > replaced by a standalone build system many years ago. We have various
>> > optional libraries in glibc such as libnsl and libmvec, controlled by
>> > ordinary --enable options.
>> >
>> > Any libdfp integration in glibc would I expect also look very different,
>> > as regards build system and general integration, from either the present
>> > build system or the old add-on version. For example, functions would be
>> > declared directly in the relevant headers under appropriate __GLIBC_USE
>> > conditionals (in bits/mathcalls.h in many cases - most functions should be
>> > present for both binary and decimal types). Tests would use the libm-test
>> > / auto-libm-test machinery, adapted as necessary to support DFP; the vast
>> > bulk of test inputs to most functions should be applicable to both binary
>> > and decimal floating point. (The actual function implementations would I
>> > expect not need changing much for glibc.)
>>
>> I created an issue in the libdfp project [1] to track these changes.
>>
>> [1] https://github.com/libdfp/libdfp/issues/63
>
> It's not clear to me that what I wrote in that paragraph has much
> relevance to the existing standalone libdfp; it was entirely about what
> would be appropriate for a hypothetical integration in glibc, were there
> interest in or consensus for such an integration in the first place.
If we never reach consensus, I'm going to close it. But I think it's important
to leave traces of this discussion in the libdfp project too.
> Declaring using bits/mathcalls.h only makes sense when the functions are
> part of glibc. (Though it carries implications for projects that do make
> sense for standalone libdfp: where an existing glibc libm function is
> appropriate for DFP types but missing for them in libdfp, as is the case
> for various TS 18661-1 functions in glibc that also exist for DFP in TS
> 18661-2, adding the DFP versions to libdfp is appropriate.)
>
> The libm-test machinery is also not particularly designed to be separated
> from the glibc build system; you'd need lots of local changes to use it in
> libdfp (and lots of local changes to make it work with DFP types anyway -
> including an MPFR equivalent for DFP in gen-auto-libm-tests, possibly
> wrapping round GMP and MPFR and using interval arithmetic to get correctly
> rounded DFP results). Though if you did get it working with libdfp, I
> expect you'd find lots of libdfp bugs that need fixing, e.g. the libdfp
> lgamma / tgamma implementations have issues I fixed in glibc some time
> ago, so making those tests work with libdfp could lead to significant
> improvements in libdfp code quality.
Ack.
--
Tulio Magno