Store float for pow result test

Alexandre Oliva oliva@adacore.com
Tue Oct 1 08:56:00 GMT 2019


Optimizing gcc.dg/torture/pr41094.c, the compiler computes the
constant value and short-circuits the whole thing.  At -O0, however,
on 32-bit x86, the call to pow() remains, and the program compares the
returned value in a stack register, with excess precision, with the
exact return value expected from pow().  If libm's pow() returns a
slightly off result, the compare fails.  If the value in the register
is stored in a separate variable, so it gets rounded to double
precision, and then compared, the compare passes.

It's not clear that the test was meant to detect libm's reliance on
rounding off the excess precision, but I guess it wasn't, so I propose
this slight change that enables it to pass regardless of the slight
inaccuracy of the C library in use.

Regstrapped on x86_64-linux-gnu, and tested on the affected target.
Ok to install?


for  gcc/testsuite/ChangeLog

	* gcc.dg/torture/pr41094.c: Introduce intermediate variable.
---
 gcc/testsuite/gcc.dg/torture/pr41094.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/torture/pr41094.c b/gcc/testsuite/gcc.dg/torture/pr41094.c
index 2a4e9616cbfad..9219a1741a37f 100644
--- a/gcc/testsuite/gcc.dg/torture/pr41094.c
+++ b/gcc/testsuite/gcc.dg/torture/pr41094.c
@@ -13,7 +13,8 @@ double foo(void)
 
 int main()
 {
-  if (foo() != 2.0)
+  double r = foo ();
+  if (r != 2.0)
     abort ();
   return 0;
 }

-- 
Alexandre Oliva, freedom fighter  he/him   https://FSFLA.org/blogs/lxo
Be the change, be Free!        FSF VP & FSF Latin America board member
GNU Toolchain Engineer                        Free Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara



More information about the Gcc-patches mailing list