[Bug tree-optimization/97744] New: [11 regression] floating point result errors after r11-4637

[Bug tree-optimization/97744] New: [11 regression] floating point result errors after r11-4637

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97744

            Bug ID: 97744
           Summary: [11 regression] floating point result errors after
                    r11-4637
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:f5e18dd9c7dacc9671044fc669bd5c1b26b6bdba, r11-4637 

This revision causes errors in the 32 bit run of the 172.mgrid test case, part
of spec 2000.

Running Benchmarks
  Running 172.mgrid ref base wds_test_32 default
*** Miscompare of mgrid.out, see
cpu2000/benchspec/CFP2000/172.mgrid/run/00000011/mgrid.out.mis
  Running 172.mgrid ref base wds_test_32 default
*** Miscompare of mgrid.out, see
cpu2000/benchspec/CFP2000/172.mgrid/run/00000011/mgrid.out.mis
  Running 172.mgrid ref base wds_test_32 default
*** Miscompare of mgrid.out, see
cpu2000/benchspec/CFP2000/172.mgrid/run/00000011/mgrid.out.mis
Error: 3x172.mgrid

cat cpu2000/benchspec/CFP2000/172.mgrid/run/00000011/mgrid.out.mis
12732:      0.620103E-12
          -0.425977E-12
                      ^
12733:      0.620103E-12
          -0.425977E-12
                      ^
12734:      0.627531E-12
          -0.431079E-12
                      ^
12735:      0.627531E-12
          -0.431079E-12
                      ^
12736:      0.629423E-12
          -0.432379E-12
                      ^
12737:      0.629423E-12
          -0.432379E-12
                      ^
12738:      0.629932E-12
          -0.432729E-12
                      ^

[Bug tree-optimization/97744] [11 regression] 32 bit floating point result errors after r11-4637

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97744

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0
           Keywords|                            |wrong-code

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Needs some investigation.

[Bug tree-optimization/97744] [11 regression] 32 bit floating point result errors after r11-4637

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97744

--- Comment #2 from seurer at gcc dot gnu.org ---
This particular test has been problematic before.  For example, see pr83497. 
Previously the change in output was from some floating point operations being
reordered causing a minute rounding change but it was actually OK.

By adding -fno-associative-math or removing -ffast-math it will work.  We are
probably just going to go with that.

[Bug tree-optimization/97744] [11 regression] 32 bit floating point result errors after r11-4637

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97744

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |linkw at gcc dot gnu.org
   Last reconfirmed|                            |2020-11-07
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to seurer from comment #2)
> This particular test has been problematic before.  For example, see pr83497.
> Previously the change in output was from some floating point operations
> being reordered causing a minute rounding change but it was actually OK.
> 
> By adding -fno-associative-math or removing -ffast-math it will work.  We
> are probably just going to go with that.

Thanks for the information! I'll have a look at it.

[Bug tree-optimization/97744] [11 regression] 32 bit floating point result errors after r11-4637

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97744

--- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
The additional pass fre4 run triggers this, to disable fre4 can make it pass
(but to disable dse3 can't separately, so it's unrelated), further narrowing
down shows fre4 on the function MG3XDEMO is responsible. By checking the
differences in the optimized files, some FMA computation order differences
attracted me. eg:

original:
  <bb 33> [local count: 4095816269717]:
  # D__I_lsm0.2159_1324 = PHI <_269(33), _1322(32)>
  # D_lsm0.2160_1321 = PHI <_382(33), _1313(32)>
  # D_lsm0.2162_1312 = PHI <_418(33), _1304(32)>
  # doloop.2199_1211 = PHI <doloop.2199_1210(33), doloop.2199_1209(32)>
  # ivtmp.2221_1207 = PHI <ivtmp.2221_1206(33), ivtmp.2263_1126(32)>
  # ivtmp.2232_1201 = PHI <ivtmp.2232_1200(33), 0(32)>
  _827 = ivtmp.2266_1109 + 24;
  _826 = (real(kind=8) *) _827;

  ...
  _293 = MEM <real(kind=8)> [(real(kind=8)[0:D.3022] *)_816 + ivtmp.2232_1201 *
1];
  _294 = _288 + _293;
  _295 = ((_294));
  _296 = _295 * 2.5e-1;
  _15 = .FMA (_263, 5.0e-1, _296);
  _815 = ivtmp.2270_1092 + 32;
  _814 = (real(kind=8) *) _815;
  ...
  _362 = _418 + D_lsm0.2162_1312;
  _363 = ((_362));
  _12 = .FMA (_363, 6.25e-2, _15);
  _370 = .FMA (_337, 1.25e-1, _12);
  _1163 = (void *) ivtmp.2221_1207;
  MEM <real(kind=8)> [(real(kind=8)[0:D.3025] *)_1163 + 16B] = _370;

vs. with culprit commit:

  <bb 33> [local count: 4095816269717]:
  # D__I_lsm0.2159_1324 = PHI <_269(33), _1322(32)>
  # D_lsm0.2160_1321 = PHI <_382(33), _1313(32)>
  # D_lsm0.2162_1312 = PHI <_418(33), _1304(32)>
  # doloop.2200_11 = PHI <doloop.2200_1333(33), doloop.2200_1329(32)>
  # ivtmp.2222_213 = PHI <ivtmp.2222_426(33), ivtmp.2264_1206(32)>
  # ivtmp.2233_1325 = PHI <ivtmp.2233_1413(33), 0(32)>
  _952 = ivtmp.2267_1189 + 24;
  _951 = (real(kind=8) *) _952;
  ...
  _293 = MEM <real(kind=8)> [(real(kind=8)[0:D.3022] *)_941 + ivtmp.2233_1325 *
1];
  _365 = _290 + _293;
  _294 = _365 + D__I_lsm0.2159_1324;
  _295 = ((_294));
...
  _362 = _418 + D_lsm0.2162_1312;
  _363 = ((_362));
  _364 = _363 * 6.25e-2;
  _558 = .FMA (_263, 5.0e-1, _364);
  _12 = .FMA (_295, 2.5e-1, _558);
  _370 = .FMA (_337, 1.25e-1, _12);
  _1265 = (void *) ivtmp.2222_213;
  MEM <real(kind=8)> [(real(kind=8)[0:D.3025] *)_1265 + 16B] = _370;

So I tried to disable pass widening_mul, it can pass and then I further
narrowed down to convert_mult_to_fma.

So the commit causes FMA computation order changes and triggered the final
comparison failure.  By bisecting on one particular FMA transform, it comes to
the one in PSINV which is called by MG3XDEMO for several times.

  _896 = _8 * _902;
  _240 = _637 + _896;

vs.

  _240 = .FMA (_8,_902, _637);

Excepting for Seurer mentioned options which make it pass, as
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html, the option
-ffp-contract=off which is able to disable FMA optimization can also make this
pass.

Besides, searching bugs shows this mgrid is well known to be with too small
absolute tolerance such as PR35418.

[Bug tree-optimization/97744] [11 regression] 32 bit floating point result errors after r11-4637

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97744

--- Comment #5 from Kewen Lin <linkw at gcc dot gnu.org> ---
btw, this is power7 specific, I found it can pass with -mcpu=power8.

[Bug tree-optimization/97744] [11 regression] 32 bit floating point result errors after r11-4637

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97744

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |INVALID

--- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> ---
With the above findings, I think the culprit commit just gets the fragile
tolerance issue exposed again, closed as invalid.