https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #34 from JuzheZhong <juzhe.zhong at rivai dot ai> --- (In reply to Patrick O'Neill from comment #32) > (In reply to JuzheZhong from comment #31) > > You are using -Ofast which will have precision issue on floating-point. > > > > You can reference it: > > > > https://godbolt.org/z/zzG8xbx95 > > > > O3 result: 50002896.000000 > > Ofast result: 50005000.000000 > > > > They are different and not correctness issue. > > > > GCC is same behavior as LLVM. > > > > More details: > > https://github.com/llvm/llvm-project/issues/77044 > > > > So, to elide the potential floating-point precision confusion, > > I suggest you first use -O3 -ftrapping-math to test SPEC. > > > > Otherwise, it's really hard to locate the real issue. > > The cam4 failure still appears with: > "-O3" > "-ftrapping-math" > "-mtune=generic-ooo" > "-march=rv64imafdcv_zba_zbb_zbs_zicond_zfa" > "-fno-lto" > "-ftree-vectorize" > "--param=riscv-autovec-preference=scalable" > > I'll keep digging through the harness and finding the remaining flags. CAM4 is likely VSETVLI bug that Robin told me. I mean the other failures. Could you trigger a full run of SPEC with -O3 -ftrapping-math ? To see how many bugs in SPEC actually. I think we don't need to care about the failures which caused by floating-point precision.
