Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc
Hi Jakub, > This doesn't seem to handle the powerpc* IBM double double long double. Do we support the IEEE Fortran modules on this target, despite having a non-IEEE long double? I remember we talked about it when I first implemented it, but can’t remember what choice we ended up making. > __LDBL_IS_IEC_60559__ isn't defined for this type, because it is far from > an IEEE754 type, but it has signaling NaNs - as can be seen in glibc > libc/sysdeps/ieee754/ldbl-128ibm/s_issignalingl.c > the type is a pair of doubles and whether it is a sNaN or qNaN is determined > by whether the first double is a sNaN or qNaN. > > Ok for trunk? It doesn’t hurt to provide an implementation, in any case. OK to push, and thanks for the patch. FX
Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc
On Mon, Jan 17, 2022 at 12:11:59AM +0100, FX via Gcc-patches wrote:
> This patch is the third in my “signaling NaN” series. For targets with IEEE
> support but without the issignaling macro in libc (i.e., everywhere except
> glibc), this allows us to provide a fallback implementation. In order to keep
> the code in ieee_helper.c relatively readable, I’ve put that new
> implementation in a separate file, issignaling_fallback.h.
>
> The logic is borrowed from different routines in glibc, but gathered into a
> single file and much simpler than the glibc implementation, because we do not
> need to cover all the cases they have (comments with details are available in
> issignaling_fallback.h).
>
> I can’t test this on all the targets I’d like to, obviously. But it was
> tested on x86_64-pc-linux-gnu (where it doesn’t do anything), on
> x86_64-pc-linux-gnu by mimicking the lack of a issignaling macro, and on
> x86_64-apple-darwin (which does not have issignaling).
This doesn't seem to handle the powerpc* IBM double double long double.
__LDBL_IS_IEC_60559__ isn't defined for this type, because it is far from
an IEEE754 type, but it has signaling NaNs - as can be seen in glibc
libc/sysdeps/ieee754/ldbl-128ibm/s_issignalingl.c
the type is a pair of doubles and whether it is a sNaN or qNaN is determined
by whether the first double is a sNaN or qNaN.
Ok for trunk?
2022-01-25 Jakub Jelinek
* ieee/issignaling_fallback.h (__issignalingl): Define for
IBM extended long double are returning __issignaling on the
first double.
--- libgfortran/ieee/issignaling_fallback.h.jj 2022-01-25 12:14:45.404232320
+0100
+++ libgfortran/ieee/issignaling_fallback.h 2022-01-25 12:14:52.504131720
+0100
@@ -137,6 +137,19 @@ __issignalingl (long double x)
return ret || (((exi & 0x7fff) == 0x7fff) && (hxi > 0xc000));
}
+#elif (__LDBL_DIG__ == 31)
+
+/* Long double is 128-bit IBM extended type. */
+
+static inline int
+__issignalingl (long double x)
+{
+ union { long double value; double parts[2]; } u;
+
+ u.value = x;
+ return __issignaling (u.parts[0]);
+}
+
#elif (__LDBL_DIG__ == 33) && __LDBL_IS_IEC_60559__
/* Long double is 128-bit type. */
Jakub
Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc
> Yes, it does. > > (There is also some leeway granted to non-release-critical languages > like Fortran. RM approval is only needed once a branch has been > frozen). Thanks Thomas. Pushed: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e89d0befe3ec3238fca6de2cb078eb403b8c7e99 I’m hoping my use of macros is enough to make it build on all target, and I’ll follow the gcc-testresults and other lists to see if there is any trouble. If you see something (or something is reported), feel free to CC me on it… FX
Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc
On 24.01.22 15:23, FX via Fortran wrote: Then it’s OK to commit for me, but you will need approval from release managers at this stage. Hum… I submitted it before stage 4 started, does that count? Yes, it does. (There is also some leeway granted to non-release-critical languages like Fortran. RM approval is only needed once a branch has been frozen). Best regards Thomas
Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc
> Then it’s OK to commit for me, but you will need approval from release > managers at this stage. Hum… I submitted it before stage 4 started, does that count? FX
Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc
Le 23/01/2022 à 11:05, FX a écrit : Hi Mikael, I spotted two unexpected things (to me at least) related to x86 extended type: - You check for endianness, so the format is not x86-specific? - Is it expected that the padding bits are in the middle of the data in the big-endian case? IEEE specifies that extended precision types can be present, possibly with any endianness, at least in theory. There are other CPUs with extended precision types than Intel, although we probably don’t support them currently in gfortran: Motorola 68881 has a IEEE-compatible 80-bit format and is big endian. I kept the code generic, but if you think it’s a problem I can remove that part and make it error out. No, it’s not a problem, I just was surprised to see endianness checks as I thought it was x86-only. I followed the logic used in glibc to deal with bit layout and endianness, so it should be safe as currently proposed. Then it’s OK to commit for me, but you will need approval from release managers at this stage. Thanks.
Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc
Hi Mikael, > I spotted two unexpected things (to me at least) related to x86 extended type: > - You check for endianness, so the format is not x86-specific? > - Is it expected that the padding bits are in the middle of the data in the > big-endian case? IEEE specifies that extended precision types can be present, possibly with any endianness, at least in theory. There are other CPUs with extended precision types than Intel, although we probably don’t support them currently in gfortran: Motorola 68881 has a IEEE-compatible 80-bit format and is big endian. I kept the code generic, but if you think it’s a problem I can remove that part and make it error out. I followed the logic used in glibc to deal with bit layout and endianness, so it should be safe as currently proposed. FX
Re: [PATCH] Fortran: detect signaling NaNs on targets without issignaling macro in libc
Hello,
Le 17/01/2022 à 00:11, FX via Fortran a écrit :
This patch is the third in my “signaling NaN” series. For targets with IEEE
support but without the issignaling macro in libc (i.e., everywhere except
glibc), this allows us to provide a fallback implementation. In order to keep
the code in ieee_helper.c relatively readable, I’ve put that new implementation
in a separate file, issignaling_fallback.h.
The logic is borrowed from different routines in glibc, but gathered into a
single file and much simpler than the glibc implementation, because we do not
need to cover all the cases they have (comments with details are available in
issignaling_fallback.h).
I can’t test this on all the targets I’d like to, obviously. But it was tested
on x86_64-pc-linux-gnu (where it doesn’t do anything), on x86_64-pc-linux-gnu
by mimicking the lack of a issignaling macro, and on x86_64-apple-darwin (which
does not have issignaling).
OK to push?
again, I feel underqualified to review this.
I spotted two unexpected things (to me at least) related to x86 extended
type:
diff --git a/libgfortran/ieee/issignaling_fallback.h
b/libgfortran/ieee/issignaling_fallback.h
new file mode 100644
index 000..e824cf8c59b
--- /dev/null
+++ b/libgfortran/ieee/issignaling_fallback.h
...
+
+#elif (__LDBL_DIG__ == 18) && __LDBL_IS_IEC_60559__
+
+/* Long double is x86 extended type. */
+
+typedef union
+{
+ long double value;
+ struct
+ {
+#if __FLOAT_WORD_ORDER == __BIG_ENDIAN
+int sign_exponent:16;
+unsigned int empty:16;
+uint32_t msw;
+uint32_t lsw;
+#elif __FLOAT_WORD_ORDER == __LITTLE_ENDIAN
+uint32_t lsw;
+uint32_t msw;
+int sign_exponent:16;
+unsigned int empty:16;
+#endif
+ } parts;
+} ieee_long_double_shape_type;
+
- You check for endianness, so the format is not x86-specific?
- Is it expected that the padding bits are in the middle of the data in
the big-endian case?
