aboutsummaryrefslogtreecommitdiff
path: root/gcc/tree-ssa-alias.c
diff options
context:
space:
mode:
authorAlexandre Oliva <oliva@adacore.com>2019-10-01 11:36:47 +0000
committerAlexandre Oliva <aoliva@gcc.gnu.org>2019-10-01 11:36:47 +0000
commit676e38c2a93311bc847c1034637efc935e527f8f (patch)
treeb71bee62329d42492f63b9ebfceb726d68dff4dc /gcc/tree-ssa-alias.c
parent31632e2c4327146ea8d21cff33adaa505b17d2bd (diff)
downloadgcc-676e38c2a93311bc847c1034637efc935e527f8f.zip
gcc-676e38c2a93311bc847c1034637efc935e527f8f.tar.gz
gcc-676e38c2a93311bc847c1034637efc935e527f8f.tar.bz2
Store float for pow result test
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
Diffstat (limited to 'gcc/tree-ssa-alias.c')
0 files changed, 0 insertions, 0 deletions