[PATCH] Include math.h in nextafter-2.c test.
Wed Nov 18 05:33:23 GMT 2020
On Sun, 2020-11-15 at 12:12 -0500, Michael Meissner via Gcc-patches wrote:
> Include math.h in nextafter-2.c test.
> I previously posted this with two other patches. I've separated this into its
> own patch. What happens is because the nextafter-2.c test uses -fno-builtin,
> and it does not include math.h, the wrong nextafterl and nextforwardl gets
> called when long double is not IBM 128-bit (i.e. either 64-bit, or IEEE
Thats a sandbox issue, or something upstream ?
> Rather than add the include only for the PowerPC, I thought it was better to
> always include it. There might be some port in the future that has the same
> issue with multiple long double types without using multilibs.
> Can I check this into the master branch.
> 2020-11-15 Michael Meissner <firstname.lastname@example.org>
> * gcc.dg/nextafter-2.c: Include math.h.
> gcc/testsuite/gcc.dg/nextafter-2.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
> diff --git a/gcc/testsuite/gcc.dg/nextafter-2.c b/gcc/testsuite/gcc.dg/nextafter-2.c
> index e51ae94be0c..8149a709fa5 100644
> --- a/gcc/testsuite/gcc.dg/nextafter-2.c
> +++ b/gcc/testsuite/gcc.dg/nextafter-2.c
> @@ -6,6 +6,18 @@
> #include <stdlib.h>
> +/* In order to run on systems like the PowerPC that have 3 different long
> + double types, include math.h so it can choose what is the appropriate
> + nextafterl function to use.
> + If we didn't use -fno-builtin for this test, the PowerPC compiler would have
> + changed the names of the built-in functions that use long double. The
> + nextafter-1.c function runs with this mapping.
> + Since this test uses -fno-builtin, include math.h, so that math.h can make
> + the appropriate choice to use. */
Can this be simplified to stl
/* Include math.h so that systems like PowerPC that have different long
double types can choose the appropriate nextafterl function to use. */
> +#include <math.h>
> #if defined(__GLIBC__) && defined(__GLIBC_PREREQ)
> # if !__GLIBC_PREREQ (2, 24)
> /* Workaround buggy nextafterl in glibc 2.23 and earlier,
More information about the Gcc-patches