https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #31 from JuzheZhong <juzhe.zhong at rivai dot ai> --- (In reply to Patrick O'Neill from comment #30) > (In reply to Li Pan from comment #29) > > Thanks a lot for the summary. Could you please help to share some more > > information about the spec2017 for above data? Like data set (test, train, > > or ref), the enviornment (qemu, spike, or hardware) as well as the spec > > config file. Just would like to make sure we are on the same page for the > > failures and reproducible from others. > > Hi Pan, > > We use nix to build/run spec so it's a bit opaque to me but I've extracted > out: > ref data set > qemu > flags: > "-Ofast" > "-mtune=generic-ooo" > "-march=rv64imafdcv_zba_zbb_zbs_zicond_zfa" > "-fno-lto" > "-ftree-vectorize" > "--param=riscv-autovec-preference=scalable" > > There are other flags that are are injected by the nix harness and I'm in > the process of pulling them out. With these flags you should at least see > the cam4 failure. Vineet is looking at the cam4 failure and is planning to > open a bugzilla with details. > > Thanks, > Patrick 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.
