* PowerPC: Map q built-ins to *l instead of *f128 if IEEE 128-bit long double.
@ 2020-10-22 22:08 Michael Meissner
2020-10-27 15:08 ` will schmidt
2020-11-03 0:26 ` Segher Boessenkool
0 siblings, 2 replies; 3+ messages in thread
From: Michael Meissner @ 2020-10-22 22:08 UTC (permalink / raw)
To: gcc-patches, Michael Meissner, Segher Boessenkool,
David Edelsohn, Bill Schmidt, Peter Bergner, Jeff Law,
Jonathan Wakely
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 <meissner@linux.ibm.com>
* 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: meissner@linux.ibm.com, phone: +1 (978) 899-4797
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: PowerPC: Map q built-ins to *l instead of *f128 if IEEE 128-bit long double.
2020-10-22 22:08 PowerPC: Map q built-ins to *l instead of *f128 if IEEE 128-bit long double Michael Meissner
@ 2020-10-27 15:08 ` will schmidt
2020-11-03 0:26 ` Segher Boessenkool
1 sibling, 0 replies; 3+ messages in thread
From: will schmidt @ 2020-10-27 15:08 UTC (permalink / raw)
To: Michael Meissner, gcc-patches, Segher Boessenkool,
David Edelsohn, Bill Schmidt, Peter Bergner, Jeff Law,
Jonathan Wakely
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 <meissner@linux.ibm.com>
>
> * 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
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: PowerPC: Map q built-ins to *l instead of *f128 if IEEE 128-bit long double.
2020-10-22 22:08 PowerPC: Map q built-ins to *l instead of *f128 if IEEE 128-bit long double Michael Meissner
2020-10-27 15:08 ` will schmidt
@ 2020-11-03 0:26 ` Segher Boessenkool
1 sibling, 0 replies; 3+ messages in thread
From: Segher Boessenkool @ 2020-11-03 0:26 UTC (permalink / raw)
To: Michael Meissner, gcc-patches, David Edelsohn, Bill Schmidt,
Peter Bergner, Jeff Law, Jonathan Wakely
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-11-03 0:27 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-22 22:08 PowerPC: Map q built-ins to *l instead of *f128 if IEEE 128-bit long double Michael Meissner
2020-10-27 15:08 ` will schmidt
2020-11-03 0:26 ` Segher Boessenkool
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).