From: Joseph Myers <joseph@codesourcery.com>
To: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Cc: <libc-alpha@sourceware.org>, <gabriel@inconstante.eti.br>,
<raji@linux.ibm.com>
Subject: Re: [PATCH 4/9] ldbl-128ibm-compat: Add a generic significand() implementation
Date: Thu, 07 Jun 2018 13:38:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.20.1806071325120.27583@digraph.polyomino.org.uk> (raw)
In-Reply-To: <20180606223909.16675-5-tuliom@linux.ibm.com>
On Wed, 6 Jun 2018, Tulio Magno Quites Machado Filho wrote:
> Create a template for significand and reuse it in the ldbl-128ibm-compat
> directory.
The following applies to both this patch and the scalb one: I don't think
it makes sense to have a template that is, in fact, only used for one
format.
If using a template for significand, I'd expect it to be used for all
floating-point types / formats (removing the existing s_significand*.c
etc. from math/ and sysdeps/ieee754/ldbl-opt/, listing it in
gen-libm-calls instead of libm-calls). The empty version in
sysdeps/ieee754/float128 would still ensure nothing gets built for
significand for float128 and you'd still have the s_significandf128.c you
add in this patch (the ChangeLog entry seems wrong to mention
s_significandl.c). Using templates like that would mean the object files
define excess aliases such as significandf32, but those aliases aren't in
Versions files so they are harmless, not exported from libm.
Much the same would apply to e_scalb templates. For w_scalb you'd need to
treat the existing w_scalb*_compat templates like the other compat ones -
that is, make their entire contents conditional on LIBM_SVID_COMPAT (so
they don't get built for new targets or static linking at all), while the
new w_scalb template would be listed in gen-libm-calls and not have any
LIBM_SVID_COMPAT conditionals in it, and a new dummy
sysdeps/ieee754/float128/w_scalbf128.c would ensure no code actually gets
built from that template in the normal float128 case. Given the general
handling of finite aliases I'd expect a new __scalbf128_finite function
export to be added to the Versions file for ldbl-128ibm-compat as well.
I would suggest that patches adding such templates and using them for
existing formats without changing the ABI anywhere (a cleanup /
refactoring of existing code) be separated from patches that actually add
new ldbl-128ibm-compat symbols.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2018-06-07 13:38 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-06 22:41 [PATCH 0/9] Introduce ieee128 symbols and redirections Tulio Magno Quites Machado Filho
2018-06-06 22:41 ` [PATCH 3/9] ldbl-128ibm-compat: Provide a generic scalb implementation Tulio Magno Quites Machado Filho
2018-06-06 22:41 ` [PATCH 2/9] Move declare_mgen_finite_alias definition Tulio Magno Quites Machado Filho
2018-06-07 13:25 ` Joseph Myers
2018-06-06 22:41 ` [PATCH 1/9] ldbl-128ibm-compat: Create libm-alias-float128.h Tulio Magno Quites Machado Filho
2018-06-06 23:05 ` Joseph Myers
2018-06-13 20:16 ` Tulio Magno Quites Machado Filho
2018-06-06 22:41 ` [PATCH 4/9] ldbl-128ibm-compat: Add a generic significand() implementation Tulio Magno Quites Machado Filho
2018-06-07 13:38 ` Joseph Myers [this message]
2018-06-15 20:16 ` Tulio Magno Quites Machado Filho
2018-06-15 20:20 ` Tulio Magno Quites Machado Filho
2018-06-06 22:42 ` [PATCH 5/9] ldbl-128ibm-compat: Provide ISO C functions not provided by the _Float128 API Tulio Magno Quites Machado Filho
2018-06-07 14:51 ` Joseph Myers
2018-06-13 21:41 ` Tulio Magno Quites Machado Filho
2018-06-06 22:42 ` [PATCH 8/9] ldbl-128ibm-compat: Redirect long double functions to f128/ieee128 functions Tulio Magno Quites Machado Filho
2018-06-06 22:42 ` [PATCH 6/9] ldbl-128ibm-compat: Provide nexttoward functions Tulio Magno Quites Machado Filho
2018-06-06 22:42 ` [PATCH 7/9] Refactor math-finite.h and introduce mathcalls-redir.h Tulio Magno Quites Machado Filho
2018-06-06 23:23 ` Joseph Myers
2018-06-13 21:36 ` Tulio Magno Quites Machado Filho
2018-06-13 22:58 ` Joseph Myers
2018-06-14 18:07 ` Tulio Magno Quites Machado Filho
2018-06-06 22:43 ` [PATCH 9/9] ldbl-128ibm-compat: Redirect complex math functions Tulio Magno Quites Machado Filho
2018-06-06 23:11 ` [PATCH 0/9] Introduce ieee128 symbols and redirections Joseph Myers
2018-06-13 20:25 ` Tulio Magno Quites Machado Filho
2018-06-13 20:28 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1806071325120.27583@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=gabriel@inconstante.eti.br \
--cc=libc-alpha@sourceware.org \
--cc=raji@linux.ibm.com \
--cc=tuliom@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).