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.


for  gcc/testsuite/ChangeLog

	* gcc.dg/torture/pr41094.c: Introduce intermediate variable.

From-SVN: r276404