g:cf20d00ca1ae5a0da9b329896d7b51e55381bdd7, r10-4160 fortran.dg/maxlocval_4.f90 also fails. This only happens on power 9. Executing on host: /home3/seurer/gcc/git/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran -B/home3/seurer/gcc/git/build/gcc-test2/gcc/testsuite/gfortran/../../ -B/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/minlocval_4.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O2 -pedantic-errors -B/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libatomic/.libs -B/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs -L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs -L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs -lm -o ./minlocval_4.exe (timeout = 300) spawn -ignore SIGHUP /home3/seurer/gcc/git/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran -B/home3/seurer/gcc/git/build/gcc-test2/gcc/testsuite/gfortran/../../ -B/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/minlocval_4.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O2 -pedantic-errors -B/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs -L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libatomic/.libs -B/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs -L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs -L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs -lm -o ./minlocval_4.exe PASS: gfortran.dg/minlocval_4.f90 -O2 (test for excess errors) Setting LD_LIBRARY_PATH to .:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libatomic/.libs:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test2/gcc:.:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libatomic/.libs:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test2/gcc:/home/seurer/gcc/git/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test2/./isl/.libs:/home/seurer/gcc/git/build/gcc-test2/./prev-isl/.libs Execution timeout is: 300 spawn [open ...] Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG IEEE_DIVIDE_BY_ZERO STOP 70 FAIL: gfortran.dg/minlocval_4.f90 -O2 execution test
r10-4160 is the "daily bump" commit. How confident are you in your bisection? :-)
You are right, it was git g:6d099a76a0f6a040a3e678f2bce7fc69cc3257d8, r10-4161
This issue may relates to cunroll and cunrollli; after cunroll, for power9 some special instructions were selected. In RTL, for power9, 'smax' is generated at ce1 pass; While for power8, 'smax' is not used.
This issue can be reproduced with GCC9 "-O2 -funroll-loops -mcpu=power9" or "-O3 -mcpu=power9".
There are below difference between data/instructions for P8 and P9: (maxlocval_4.f90) f29=-inf f30=-inf f31=nan P9: xsmaxcdp vs31,vs29,vs31 ==> vs31/f31:nan (smax(-inf, nan)-->nan) b 0x10004b60 <MAIN__+15760> P8: fcmpu cr0,f29,f31 blt 0x10004c20 <MAIN__+15952> (not jump, -inf < nan --> false" fmr f31,f29 ==>f31:-inf b 0x10004c20 <MAIN__+15952> On P9, 'f31' becomes ‘nan’ by instruction "xsmaxcdp". While on P8, 'f31' becomes '-inf' through "fcmpu and blt".
commit r10-7114-g37e0df8a9be5a8232f4ccb73cdadb02121ba523f Author: Jiufu Guo <guojiufu@linux.ibm.com> Date: Tue Mar 10 13:51:57 2020 +0800 rs6000: Check -+0 and NaN for smax/smin generation PR93709 mentioned regressions on maxlocval_4.f90 and minlocval_f.f90 which relates to max of '-inf' and 'nan'. This regression occur on P9 because P9 new instruction 'xsmaxcdp' is generated. And for C code `a < b ? b : a` is also generated as `xsmaxcdp` under -O2 for P9. While this instruction behavior more like C/C++ semantic (a>b?a:b). This generates prevents 'xsmaxcdp' to be generated for those cases. 'xsmincdp' also is handled in patch. gcc/ 2020-03-10 Jiufu Guo <guojiufu@linux.ibm.com> PR target/93709 * gcc/config/rs6000/rs6000.c (rs6000_emit_p9_fp_minmax): Check NAN and SIGNED_ZEROR for smax/smin. gcc/testsuite 2020-03-10 Jiufu Guo <guojiufu@linux.ibm.com> PR target/93709 * gcc.target/powerpc/p9-minmax-3.c: New test.
Confirmed, since fixed on trunk. Do we want any backports?
The releases/gcc-9 branch has been updated by Jiu Fu Guo <guojiufu@gcc.gnu.org>: https://gcc.gnu.org/g:d01cb80e0fbe23510a861faab9909b76837faf98 commit r9-8401-gd01cb80e0fbe23510a861faab9909b76837faf98 Author: Jiufu Guo <guojiufu@linux.ibm.com> Date: Tue Mar 10 13:51:57 2020 +0800 rs6000: Check -+0 and NaN for smax/smin generation PR93709 mentioned regressions on maxlocval_4.f90 and minlocval_f.f90 which relates to max of '-inf' and 'nan'. This regression occur on P9 because P9 new instruction 'xsmaxcdp' is generated. And for C code `a < b ? b : a` is also generated as `xsmaxcdp` under -O2 for P9. While this instruction behavior more like C/C++ semantic (a>b?a:b). In GCC9, the issue also occur as the new test case shows. This generates prevents 'xsmaxcdp' to be generated for those cases. 'xsmincdp' also is handled in patch. gcc/ 2020-03-19 Jiufu Guo <guojiufu@linux.ibm.com> PR target/93709 * gcc/config/rs6000/rs6000.c (rs6000_emit_p9_fp_minmax): Check NAN and SIGNED_ZEROR for smax/smin. gcc/testsuite 2020-03-19 Jiufu Guo <guojiufu@linux.ibm.com> PR target/93709 * gcc.target/powerpc/p9-minmax-3.c: New test.
submit to trunk and GCC9.