Re: PowerPC: Map q built-ins to *l instead of *f128 if IEEE 128-bit long double.
Hi! On Thu, Oct 22, 2020 at 06:08:32PM -0400, Michael Meissner wrote: > If we map nanq to nanf128 when long double is IEEE, it seems to lose the > special signaling vs. non-signaling NAN support. Well, that is very confidence-inspiring. Please figure out what is actually going on? Why do the f128 functions work in the other cases? *Do* they? Segher
Re: PowerPC: Map q built-ins to *l instead of *f128 if IEEE 128-bit long double.
On Thu, 2020-10-22 at 18:08 -0400, Michael Meissner via Gcc-patches wrote:
> PowerPC: Map q built-ins to *l instead of *f128 if IEEE 128-bit long double.
>
> I have split all of these patches into separate patches to hopefully get them
> into the tree.
>
> If we map nanq to nanf128 when long double is IEEE, it seems to lose the
> special signaling vs. non-signaling NAN support. This patch maps the
> functions
> to the long double version if long double is IEEE 128-bit. If this patch
> is not applied, a few tests in the testsuite will start failing.
>
> I have tested this patch with bootstrap builds on a little endian power9
> system
> running Linux. With the other patches, I have built two full bootstrap builds
> using this patch and the patches after this patch. One build used the current
> default for long double (IBM extended double) and the other build switched the
> default to IEEE 128-bit. I used the Advance Toolchain AT 14.0 compiler as the
> library used by this compiler. There are no regressions between the tests.
> There are 3 fortran benchmarks (ieee/large_2.f90, default_format_2.f90, and
> default_format_denormal_2.f90) that now pass.
>
> Can I install this into the trunk?
>
> We have gotten some requests to back port these changes to GCC 10.x. At the
> moment, I am not planning to do the back port, but I may need to in the
> future.
>
> gcc/
> 2020-10-22 Michael Meissner
>
> * config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): If long
> double is IEEE-128 map the nanq built-in functions to the long
> double function, not the f128 function.
A bit long, but I think its OK.
> ---
> gcc/config/rs6000/rs6000-c.c | 31 ---
> 1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
> index cc1e997524e..bee78fcbac4 100644
> --- a/gcc/config/rs6000/rs6000-c.c
> +++ b/gcc/config/rs6000/rs6000-c.c
> @@ -684,15 +684,32 @@ rs6000_cpu_cpp_builtins (cpp_reader *pfile)
>builtin_define ("__builtin_vsx_xvnmsubmsp=__builtin_vsx_xvnmsubsp");
> }
>
> - /* Map the old _Float128 'q' builtins into the new 'f128' builtins. */
> + /* Map the old _Float128 'q' builtins into the new 'f128' builtins if long
> + double is IBM or 64-bit.
> +
> + However, if long double is IEEE 128-bit, map both sets of built-in
> + functions to the normal long double version. This shows up in nansf128
> + vs. nanf128. */
>if (TARGET_FLOAT128_TYPE)
> {
> - builtin_define ("__builtin_fabsq=__builtin_fabsf128");
> - builtin_define ("__builtin_copysignq=__builtin_copysignf128");
> - builtin_define ("__builtin_nanq=__builtin_nanf128");
> - builtin_define ("__builtin_nansq=__builtin_nansf128");
> - builtin_define ("__builtin_infq=__builtin_inff128");
> - builtin_define ("__builtin_huge_valq=__builtin_huge_valf128");
> + if (FLOAT128_IEEE_P (TFmode))
> + {
> + builtin_define ("__builtin_fabsq=__builtin_fabsl");
> + builtin_define ("__builtin_copysignq=__builtin_copysignl");
> + builtin_define ("__builtin_nanq=__builtin_nanl");
> + builtin_define ("__builtin_nansq=__builtin_nansl");
> + builtin_define ("__builtin_infq=__builtin_infl");
> + builtin_define ("__builtin_huge_valq=__builtin_huge_vall");
> + }
> + else
> + {
> + builtin_define ("__builtin_fabsq=__builtin_fabsf128");
> + builtin_define ("__builtin_copysignq=__builtin_copysignf128");
> + builtin_define ("__builtin_nanq=__builtin_nanf128");
> + builtin_define ("__builtin_nansq=__builtin_nansf128");
> + builtin_define ("__builtin_infq=__builtin_inff128");
> + builtin_define ("__builtin_huge_valq=__builtin_huge_valf128");
> + }
> }
ok
lgtm,
thanks
-Will
>
>/* Tell users they can use __builtin_bswap{16,64}. */
> --
> 2.22.0
>
>
PowerPC: Map q built-ins to *l instead of *f128 if IEEE 128-bit long double.
PowerPC: Map q built-ins to *l instead of *f128 if IEEE 128-bit long double.
I have split all of these patches into separate patches to hopefully get them
into the tree.
If we map nanq to nanf128 when long double is IEEE, it seems to lose the
special signaling vs. non-signaling NAN support. This patch maps the functions
to the long double version if long double is IEEE 128-bit. If this patch
is not applied, a few tests in the testsuite will start failing.
I have tested this patch with bootstrap builds on a little endian power9 system
running Linux. With the other patches, I have built two full bootstrap builds
using this patch and the patches after this patch. One build used the current
default for long double (IBM extended double) and the other build switched the
default to IEEE 128-bit. I used the Advance Toolchain AT 14.0 compiler as the
library used by this compiler. There are no regressions between the tests.
There are 3 fortran benchmarks (ieee/large_2.f90, default_format_2.f90, and
default_format_denormal_2.f90) that now pass.
Can I install this into the trunk?
We have gotten some requests to back port these changes to GCC 10.x. At the
moment, I am not planning to do the back port, but I may need to in the future.
gcc/
2020-10-22 Michael Meissner
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): If long
double is IEEE-128 map the nanq built-in functions to the long
double function, not the f128 function.
---
gcc/config/rs6000/rs6000-c.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
index cc1e997524e..bee78fcbac4 100644
--- a/gcc/config/rs6000/rs6000-c.c
+++ b/gcc/config/rs6000/rs6000-c.c
@@ -684,15 +684,32 @@ rs6000_cpu_cpp_builtins (cpp_reader *pfile)
builtin_define ("__builtin_vsx_xvnmsubmsp=__builtin_vsx_xvnmsubsp");
}
- /* Map the old _Float128 'q' builtins into the new 'f128' builtins. */
+ /* Map the old _Float128 'q' builtins into the new 'f128' builtins if long
+ double is IBM or 64-bit.
+
+ However, if long double is IEEE 128-bit, map both sets of built-in
+ functions to the normal long double version. This shows up in nansf128
+ vs. nanf128. */
if (TARGET_FLOAT128_TYPE)
{
- builtin_define ("__builtin_fabsq=__builtin_fabsf128");
- builtin_define ("__builtin_copysignq=__builtin_copysignf128");
- builtin_define ("__builtin_nanq=__builtin_nanf128");
- builtin_define ("__builtin_nansq=__builtin_nansf128");
- builtin_define ("__builtin_infq=__builtin_inff128");
- builtin_define ("__builtin_huge_valq=__builtin_huge_valf128");
+ if (FLOAT128_IEEE_P (TFmode))
+ {
+ builtin_define ("__builtin_fabsq=__builtin_fabsl");
+ builtin_define ("__builtin_copysignq=__builtin_copysignl");
+ builtin_define ("__builtin_nanq=__builtin_nanl");
+ builtin_define ("__builtin_nansq=__builtin_nansl");
+ builtin_define ("__builtin_infq=__builtin_infl");
+ builtin_define ("__builtin_huge_valq=__builtin_huge_vall");
+ }
+ else
+ {
+ builtin_define ("__builtin_fabsq=__builtin_fabsf128");
+ builtin_define ("__builtin_copysignq=__builtin_copysignf128");
+ builtin_define ("__builtin_nanq=__builtin_nanf128");
+ builtin_define ("__builtin_nansq=__builtin_nansf128");
+ builtin_define ("__builtin_infq=__builtin_inff128");
+ builtin_define ("__builtin_huge_valq=__builtin_huge_valf128");
+ }
}
/* Tell users they can use __builtin_bswap{16,64}. */
--
2.22.0
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
