Summary: | [10 regression] fortran.dg/minlocval_4.f90 fails on power 9 after r10-4161 | ||
---|---|---|---|
Product: | gcc | Reporter: | seurer |
Component: | target | Assignee: | Jiu Fu Guo <guojiufu> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bill.schmidt, marxin, tkoenig |
Priority: | P3 | Keywords: | wrong-code |
Version: | 10.0 | ||
Target Milestone: | 10.0 | ||
See Also: | https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98140 | ||
Host: | powerpc64le-linux-gnu | Target: | powerpc64le-linux-gnu |
Build: | powerpc64le-linux-gnu | Known to work: | |
Known to fail: | Last reconfirmed: | 2020-03-11 00:00:00 |
Description
seurer
2020-02-12 16:56:28 UTC
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. |