[4/9] ldbl-128ibm-compat: Add a generic significand() implementation
Commit Message
Create a template for significand and reuse it in the ldbl-128ibm-compat directory.
2018-06-06 Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
* math/s_significand_template.c: New file.
* sysdeps/ieee754/ldbl-128ibm-compat/Versions: Add
__significandieee128.
* sysdeps/ieee754/ldbl-128ibm-compat/s_significandf128.c: New file.
* sysdeps/ieee754/ldbl-128ibm-compat/s_significandl.c: New file.
Signed-off-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
---
math/s_significand_template.c | 33 ++++++++++++++++++++++
sysdeps/ieee754/ldbl-128ibm-compat/Versions | 1 +
.../ieee754/ldbl-128ibm-compat/s_significandf128.c | 25 ++++++++++++++++
3 files changed, 59 insertions(+)
create mode 100644 math/s_significand_template.c
create mode 100644 sysdeps/ieee754/ldbl-128ibm-compat/s_significandf128.c
Comments
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 Myers <joseph@codesourcery.com> writes:
> 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.
Ack.
> Much the same would apply to e_scalb templates.
Ack.
> For w_scalb you'd need to
> treat the existing w_scalb*_compat templates like the other compat ones -
I didn't follow completely your proposal here.
Are you saying that ldbl-128ibm-compat also needs a w_scalbf128_compat?
> 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.
Ack.
> 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.
Indeed.
> 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.
OK. I'm going to split both.
Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com> writes:
> Joseph Myers <joseph@codesourcery.com> writes:
>
>> On Wed, 6 Jun 2018, Tulio Magno Quites Machado Filho wrote:
>>
>> For w_scalb you'd need to
>> treat the existing w_scalb*_compat templates like the other compat ones -
>
> I didn't follow completely your proposal here.
> Are you saying that ldbl-128ibm-compat also needs a w_scalbf128_compat?
Sorry. I hit send too soon.
Please ignore this question. :-D
new file mode 100644
@@ -0,0 +1,33 @@
+/* Return the mantissa of a floating-point number.
+ Copyright (C) 2018 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, see
+ <http://www.gnu.org/licenses/>. */
+
+/*
+ * significand(x) computes just
+ * scalb(x, (long double) - ilogb(x)),
+ * for exercising the fraction-part(F) IEEE 754-1985 test vector.
+ */
+
+#include <math.h>
+#include <math_private.h>
+
+FLOAT
+M_DECL_FUNC (__significand) (FLOAT x)
+{
+ return M_SUF (__ieee754_scalb) (x,(FLOAT) - M_SUF (__ilogb) (x));
+}
+declare_mgen_alias (__significand, significand)
@@ -110,6 +110,7 @@ libm {
__scalbnieee128;
__setpayloadieee128;
__setpayloadsigieee128;
+ __significandieee128;
__sincosieee128;
__sinhieee128;
__sinieee128;
new file mode 100644
@@ -0,0 +1,25 @@
+/* Get mantissa of long double.
+ Copyright (C) 2018 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, see
+ <http://www.gnu.org/licenses/>. */
+
+#include <float128_private.h>
+#include <math-type-macros-float128.h>
+
+#define __significandf128 __significandieee128
+#undef declare_mgen_alias
+#define declare_mgen_alias(...)
+#include <math/s_significand_template.c>