[Bug target/113570] New: RISC-V: SPEC2017 549 fotonik3d miscompilation in autovec VLS 256 build

[Bug target/113570] New: RISC-V: SPEC2017 549 fotonik3d miscompilation in autovec VLS 256 build

[vineetg at gcc dot gnu.org]

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

            Bug ID: 113570
           Summary: RISC-V: SPEC2017 549 fotonik3d miscompilation in
                    autovec VLS 256 build
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vineetg at gcc dot gnu.org
                CC: juzhe.zhong at rivai dot ai, kito.cheng at gmail dot com,
                    law at gcc dot gnu.org, palmer at dabbelt dot com,
                    patrick at rivosinc dot com, rdapp at gcc dot gnu.org
  Target Milestone: ---

fotonik3d runs to completion BUT output results fail vs. reference output.

specperl specdiff  -m -l 10 --abstol 1e-27 --reltol 1e-10 --obiwan
--floatcompare  benchspec/CPU/549.fotonik3d_r/data/refrate/output/pscyee.out
pscyee.out

0646:   -1.91273086037953E-17, -1.46491401919706E-15,
        -1.91273086057460E-17, -1.46491401919687E-15,
                            ^
0668:   -1.91251317582607E-17, -1.42348205527085E-15,
        -1.91251317602571E-17, -1.42348205527068E-15,
                            ^
0690:   -1.91228927083786E-17, -1.38431570180230E-15,
        -1.91228927104223E-17, -1.38431570180212E-15,
                            ^
0712:   -1.91205914533895E-17, -1.34723370999236E-15,
        -1.91205914554988E-17, -1.34723370999214E-15,
                            ^
0734:   -1.91182279925531E-17, -1.31207366208699E-15,
        -1.91182279947287E-17, -1.31207366208678E-15,
                            ^
0756:   -1.91158023250692E-17, -1.27868958770083E-15,
        -1.91158023272966E-17, -1.27868958770060E-15,
                            ^
0778:   -1.91133144501623E-17, -1.24694993327743E-15,
        -1.91133144524329E-17, -1.24694993327713E-15,
                            ^
0800:   -1.91107643669701E-17, -1.21673582512221E-15,
        -1.91107643693121E-17, -1.21673582512195E-15,
                            ^
0822:   -1.91081520746626E-17, -1.18793957765398E-15,
        -1.91081520769832E-17, -1.18793957765367E-15,
                            ^
0844:   -1.91054775723835E-17, -1.16046340741478E-15,
        -1.91054775748087E-17, -1.16046340741452E-15,
                            ^

Build flags: -Ofast -fno-lto -static -march=rv64gcv_zvl256b_zba_zbb_zbs_zicond
-ftree-vectorize --param=riscv-autovec-preference=scalable
-fallow-argument-mismatch -fmax-stack-var-size=65536

QEMU_CPU=rv64,v=true,vlen=256,vext_spec=v1.0,Zve32f=true,Zve64f=true,zba=true,zbb=true,zbs=true,zicond=true

[Bug target/113570] RISC-V: SPEC2017 549 fotonik3d miscompilation in autovec VLS 256 build

[vineetg at gcc dot gnu.org]

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

--- Comment #1 from Vineet Gupta <vineetg at gcc dot gnu.org> ---
This one is a headache as we don't know where the problem is. And that it takes
~7hr for a QEMU run to finish.

Good this is there is a comparison point as VLA build works fine.

(1). bloat-o-meter (from Linux kernel) to diff the VLS (nok) and VLA (ok)
builds.

  Function                                     old     new   delta
  init_                                       6722    6752     +30
  __huygens_mod_MOD_huygense                 17078   17990    +912
  __huygens_mod_MOD_huygensh                 14412   15614   +1202
  __huygens_mod_MOD_uin.isra                  2922    2944     +22
  __material_mod_MOD_mat_updatee              4228    4272     +44

  __mur_mod_MOD_mur_init                      9054    9162    +108
  __mur_mod_MOD_mur_storee                    2546    2446    -100
  __mur_mod_MOD_mur_updatee                  10124   10354    +230

  __pec_mod_MOD_pec_init                      8522    8046    -476

  __plane_source_mod_MOD_plane_source_init    6942    7072    +130

  __power_mod_MOD___copy_power_mod_Powertyp      14      26     +12
  __power_mod_MOD_power_dft                   1280    1156    -124
  __power_mod_MOD_power_init                  9830    9994    +164
  __power_mod_MOD_power_print                 2304    1556    -748

  __upml_mod_MOD_upml_allocate.isra          19384   19614    +230
  __upml_mod_MOD_upml_init                   25564   26178    +614
  __upml_mod_MOD_upml_set_eps_arrays.isra     5406    6356    +950
  __upml_mod_MOD_upml_updatee                32516   27130   -5386
  __upml_mod_MOD_upml_updatee_simple         36112   29612   -6500
  __upml_mod_MOD_upml_updateh                15962   15992     +30

  writeout_                                  10856   11002    +146

(2). Assuming the issue is one of those above (which may not be the true),
manually  rebuild, changing build flags to VLA, one module at a time, relink,
rerun qemu and compare output.

   - This resulted in power.fppized.f90 as the culprit

(3) Manually split up the power module into multiple files - one function at a
time and do the same exercise to identify the function.

[Bug target/113570] RISC-V: SPEC2017 549 fotonik3d miscompilation in autovec VLS 256 build

[rdapp at gcc dot gnu.org]

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

--- Comment #2 from Robin Dapp <rdapp at gcc dot gnu.org> ---
I'm pretty certain this is "works as intended" and -Ofast causes the precision
to be different than with -O3 (and dependant on the target).  See also:


It has been reported that with gfortran -Ofast -march=native verification
errors may be seen, for example:

****************************************
*** Miscompare of pscyee.out; for details see
   
/data2/johnh/out.v1.1.5/benchspec/CPU/549.fotonik3d_r/run/run_base_refrate_Ofastnative.0000/pscyee.out.mis
0646:   -1.91273086037953E-17, -1.46491401919706E-15,
        -1.91273086057460E-17, -1.46491401919687E-15,
                            ^
0668:   -1.91251317582607E-17, -1.42348205527085E-15,
        -1.91251317602571E-17, -1.42348205527068E-15,
                            ^

The errors may occur with other compilers as well, depending on your particular
compiler version, hardware platform, and optimization options.

The problem arises when a compiler chooses to vectorize a particular loop from
power.F90 line number 369

369   do ifreq = 1, tmppower%nofreq
370     frequency(ifreq,ipower) = freq
371     freq = freq + freqstep
372   end do



from https://www.spec.org/cpu2017/Docs/benchmarks/549.fotonik3d_r.html
which further states:


Workaround: You will need to specify optimization options that do not cause
this loop to be vectorized. For example, on a particular platform studied in
mid-2020 using GCC 10.2, these results were seen:

OK     -Ofast -march=native -fno-unsafe-math-optimization 

If you apply one of the above workarounds in base, be sure to obey the
same-for-all rule which requires that all benchmarks in a suite of a given
language must use the same flags. For example, the sections below turn off
unsafe math optimizations for all Fortran modules in the floating point rate
and floating point speed benchmark suites:

default=base:     
      OPTIMIZE       = -Ofast -flto -march=native 
fprate,fpspeed=base:
      FOPTIMIZE      = -fno-unsafe-math-optimizations

[Bug target/113570] RISC-V: SPEC2017 549 fotonik3d miscompilation in autovec VLS 256 build

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law <law at gcc dot gnu.org> ---
See pr84201 for more details as well as
https://www.spec.org/cpu2017/Docs/benchmarks/549.fotonik3d_r.html

[Bug target/113570] RISC-V: SPEC2017 549 fotonik3d miscompilation in autovec VLS 256 build

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #4 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Just looked a little closer.  Looks like the same signature.  Essentially you
can't use -Ofast (or fast-math in general) with this benchmark, especially with
vectorization.

*** This bug has been marked as a duplicate of bug 84201 ***

[Bug target/113570] RISC-V: SPEC2017 549 fotonik3d miscompilation in autovec VLS 256 build

[juzhe.zhong at rivai dot ai]

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

--- Comment #5 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
It seems that we don't have any bugs in current SPEC 2017 testing.

So I strongly suggest "full coverage" testing on SPEC 2017 which I mentioned
in PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087

-march=rv64gcv --param=riscv-autovec-lmul=m2
-march=rv64gcv --param=riscv-autovec-lmul=m4
-march=rv64gcv --param=riscv-autovec-lmul=m8
-march=rv64gcv --param=riscv-autovec-lmul=dynamic

-march=rv64gcv_zvl256b --param=riscv-autovec-lmul=m2
-march=rv64gcv_zvl256b --param=riscv-autovec-lmul=m4
-march=rv64gcv_zvl256b --param=riscv-autovec-lmul=m8
-march=rv64gcv_zvl256b --param=riscv-autovec-lmul=dynamic

-march=rv64gcv_zvl512b --param=riscv-autovec-lmul=m2
-march=rv64gcv_zvl512b --param=riscv-autovec-lmul=m4
-march=rv64gcv_zvl512b --param=riscv-autovec-lmul=m8
-march=rv64gcv_zvl512b --param=riscv-autovec-lmul=dynamic

-march=rv64gcv --param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv --param=riscv-autovec-lmul=m2
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv --param=riscv-autovec-lmul=m4
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv --param=riscv-autovec-lmul=m8
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv --param=riscv-autovec-lmul=dynamic
--param=riscv-autovec-preference=fixed-vlmax

-march=rv64gcv_zvl256b --param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv_zvl256b --param=riscv-autovec-lmul=m2
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv_zvl256b --param=riscv-autovec-lmul=m4
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv_zvl256b --param=riscv-autovec-lmul=m8
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv_zvl256b --param=riscv-autovec-lmul=dynamic
--param=riscv-autovec-preference=fixed-vlmax

-march=rv64gcv_zvl512b --param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv_zvl512b --param=riscv-autovec-lmul=m2
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv_zvl512b --param=riscv-autovec-lmul=m4
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv_zvl512b --param=riscv-autovec-lmul=m8
--param=riscv-autovec-preference=fixed-vlmax
-march=rv64gcv_zvl512b --param=riscv-autovec-lmul=dynamic
--param=riscv-autovec-preference=fixed-vlmax

Could you trigger these testing ?