[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #44 from JuzheZhong --- (In reply to Patrick O'Neill from comment #43) > (In reply to Patrick O'Neill from comment #42) > > I kicked off a run roughly 10 hours ago with your memory-hog fix patch > > applied to a1b2953924c451ce90a3fdce6841b63bf05f335f. I'll post the results > > here when the runs complete. Thanks! > > No new failures! > > zvl128b: > no fails! > > zvl256b: > 549.fotonik3d (runtime) - pr113570 (looks like this fail is since I used > -Ofast) Thanks. Could you trigger full coverage testing of SPEC with these following combination compile option: -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 I believe they can be separate tasks assigned muitl-cores or muti-thread run simultaneously.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #43 from Patrick O'Neill --- (In reply to Patrick O'Neill from comment #42) > I kicked off a run roughly 10 hours ago with your memory-hog fix patch > applied to a1b2953924c451ce90a3fdce6841b63bf05f335f. I'll post the results > here when the runs complete. Thanks! No new failures! zvl128b: no fails! zvl256b: 549.fotonik3d (runtime) - pr113570 (looks like this fail is since I used -Ofast)
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #42 from Patrick O'Neill --- (In reply to JuzheZhong from comment #41) > Hi, Patrick. > > Could you trigger test again base on latest trunk GCC? > > We have recent memory-hog fix patch: > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=3132d2d36b4705bb762e61b1c8ca4da7c78a8321 > > I want to make sure it doesn't cause a regression on SPEC. > > I have tested it with full coverage GCC testsuite, no regression. > > But I want to know about SPEC 2017 I kicked off a run roughly 10 hours ago with your memory-hog fix patch applied to a1b2953924c451ce90a3fdce6841b63bf05f335f. I'll post the results here when the runs complete. Thanks!
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #41 from JuzheZhong --- Hi, Patrick. Could you trigger test again base on latest trunk GCC? We have recent memory-hog fix patch: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3132d2d36b4705bb762e61b1c8ca4da7c78a8321 I want to make sure it doesn't cause a regression on SPEC. I have tested it with full coverage GCC testsuite, no regression. But I want to know about SPEC 2017
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #40 from Patrick O'Neill --- (In reply to Patrick O'Neill from comment #39) > FYI I ran spec2017 last night and got: > > zvl128b: > no fails! > > zvl256b: > 549.fotonik3d (runtime) - pr113570 GCC hash: a1b2953924c451ce90a3fdce6841b63bf05f335f
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #39 from Patrick O'Neill --- FYI I ran spec2017 last night and got: zvl128b: no fails! zvl256b: 549.fotonik3d (runtime) - pr113570
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #38 from Robin Dapp --- deepsjeng also looks ok here.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #37 from Robin Dapp --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206#c9 > Using 4a0a8dc1b88408222b88e10278017189f6144602, the spec run failed on: > zvl128b (All runtime fails): > 527.cam4 (Runtime) > 531.deepsjeng (Runtime) > 521.wrf (Runtime) > 523.xalancbmk (Runtime) I tried reproducing the xalanc fail first but with the current trunk I don't see a runtime fail. Going to try deepsjeng next.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #36 from JuzheZhong --- Hi, Patrick. I just fixed a bug that will cause VSETVL PASS and AVL prop PASS bug. Could you trigger a full run of SPEC with -O3 -ftrapping-math again ? Thanks.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #35 from JuzheZhong --- (In reply to Vineet Gupta from comment #33) > cam4 failure is a bug in vsetvl pass which I'm debugging atm. > An erroneous vsetvl insn is getting generated, clobbering a live register > used subsequently in a V insn. Could you give me the peephole of assembler sequence ? Maybe I can try to reproduce it with RVV intrinsics then I can fix it. I think I can fix it quickly if it is vsetvl bugs.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #34 from JuzheZhong --- (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.00 > > Ofast result: 50005000.00 > > > > 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.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 Vineet Gupta changed: What|Removed |Added CC||vineetg at gcc dot gnu.org --- Comment #33 from Vineet Gupta --- cam4 failure is a bug in vsetvl pass which I'm debugging atm. An erroneous vsetvl insn is getting generated, clobbering a live register used subsequently in a V insn.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #32 from Patrick O'Neill --- (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.00 > Ofast result: 50005000.00 > > 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.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #31 from JuzheZhong --- (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.00 Ofast result: 50005000.00 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.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #30 from Patrick O'Neill --- (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
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #29 from Li Pan --- (In reply to Patrick O'Neill from comment #27) > Linking the discussion/plan here since more interested people are CCd here. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206#c9 > Using 4a0a8dc1b88408222b88e10278017189f6144602, the spec run failed on: > zvl128b (All runtime fails): > 527.cam4 (Runtime) > 531.deepsjeng (Runtime) > 521.wrf (Runtime) > 523.xalancbmk (Runtime) > > zvl256b: > 507.cactuBSSN (Runtime) > 521.wrf (Build) > 527.cam4 (Runtime) > 531.deepsjeng (Runtime) > 549.fotonik3d (Runtime) > > With that info I think the next steps are: > 1. Triage the zvl256b 521.wrf build failure > 2. Bisect the newly-failing testcases > 3. Finish triaging the remaining testcases the fuzzer found > 4. Attempt to manually reduce cam4 for zvl128b (since it seems to have the > fastest build+runtime) > 5. Attempt to manually reduce other fails. Hi Patrick, 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. Thanks again. Pan
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #28 from JuzheZhong --- (In reply to Patrick O'Neill from comment #27) > Linking the discussion/plan here since more interested people are CCd here. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206#c9 > Using 4a0a8dc1b88408222b88e10278017189f6144602, the spec run failed on: > zvl128b (All runtime fails): > 527.cam4 (Runtime) > 531.deepsjeng (Runtime) > 521.wrf (Runtime) > 523.xalancbmk (Runtime) > > zvl256b: > 507.cactuBSSN (Runtime) > 521.wrf (Build) > 527.cam4 (Runtime) > 531.deepsjeng (Runtime) > 549.fotonik3d (Runtime) > > With that info I think the next steps are: > 1. Triage the zvl256b 521.wrf build failure > 2. Bisect the newly-failing testcases > 3. Finish triaging the remaining testcases the fuzzer found > 4. Attempt to manually reduce cam4 for zvl128b (since it seems to have the > fastest build+runtime) > 5. Attempt to manually reduce other fails. Plz reduce cam4 for zvl128b first. No need to care about build fail of wrf. We already know the reason, it's middle-end issue which takes some time.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #27 from Patrick O'Neill --- Linking the discussion/plan here since more interested people are CCd here. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206#c9 Using 4a0a8dc1b88408222b88e10278017189f6144602, the spec run failed on: zvl128b (All runtime fails): 527.cam4 (Runtime) 531.deepsjeng (Runtime) 521.wrf (Runtime) 523.xalancbmk (Runtime) zvl256b: 507.cactuBSSN (Runtime) 521.wrf (Build) 527.cam4 (Runtime) 531.deepsjeng (Runtime) 549.fotonik3d (Runtime) With that info I think the next steps are: 1. Triage the zvl256b 521.wrf build failure 2. Bisect the newly-failing testcases 3. Finish triaging the remaining testcases the fuzzer found 4. Attempt to manually reduce cam4 for zvl128b (since it seems to have the fastest build+runtime) 5. Attempt to manually reduce other fails.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #26 from JuzheZhong --- CC Li Pan who may also reproduce the bugs for me. Plz give us more details how to reproduce the bugs since we don't see any bugs when build and run SPEC.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #25 from jiawei --- I had run SPEC2017-v1.1.9 with rv64gcv_zvl256b, it passed the compile and run on base and validate cases, used qemu 8.1.0.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #24 from JuzheZhong --- CC jiawei who run SPEC for me. Maybe you can help him to reproduce such issue then I can debug it from his feedback.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #23 from JuzheZhong --- (In reply to palmer from comment #22) > (In reply to JuzheZhong from comment #19) > > (In reply to Vineet Gupta from comment #18) > > > (In reply to JuzheZhong from comment #17) > > > > PLCT told me they passed with zvl256b. > > > > > > > > I always run SPEC with FIXED-VLMAX since we always care about peak > > > > performance > > > > on our board. > > > > > > Sure we all have our preferred peak performance configs. But the compiler > > > needs to work for all vendors' configs. So as a test, can you try a > > > scalable > > > build run at your end to at least see if you can see those issues ? > > > > I am not able to build and test SPEC since I don't have QEMU and SPEC > > environment. > > Sorry, I'm kind of confused here: you're saying you can't build/test SPEC, > but then above saying you run SPEC. > > > I should ask my colleague to do that but they are quite busy with company's > > things and frankly I can't pull more resource on open source work from my > > company. I am sorry that my typo make you confused. I must say "we" instead of "I" :). "We" is PLCT lab, my colleague, and Li Pan. I just notice my careless writing, sometimes say "I", sometimes say "we". Since I always ask some body do things I want to do.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 palmer at gcc dot gnu.org changed: What|Removed |Added CC||palmer at gcc dot gnu.org --- Comment #22 from palmer at gcc dot gnu.org --- (In reply to JuzheZhong from comment #19) > (In reply to Vineet Gupta from comment #18) > > (In reply to JuzheZhong from comment #17) > > > PLCT told me they passed with zvl256b. > > > > > > I always run SPEC with FIXED-VLMAX since we always care about peak > > > performance > > > on our board. > > > > Sure we all have our preferred peak performance configs. But the compiler > > needs to work for all vendors' configs. So as a test, can you try a scalable > > build run at your end to at least see if you can see those issues ? > > I am not able to build and test SPEC since I don't have QEMU and SPEC > environment. Sorry, I'm kind of confused here: you're saying you can't build/test SPEC, but then above saying you run SPEC. > I should ask my colleague to do that but they are quite busy with company's > things and frankly I can't pull more resource on open source work from my > company.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #21 from JuzheZhong --- Btw, I saw there are 2 more FAILs: FAIL: gcc.dg/vect/tsvc/vect-tsvc-s1115.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/tsvc/vect-tsvc-s1115.c execution test FAIL: gcc.dg/vect/tsvc/vect-tsvc-s114.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/tsvc/vect-tsvc-s114.c execution test on -march=rv64gcv_zvl1024b --param=riscv-autovec-lmul=dynamic. I am not sure whether they are same issue as SPEC issue on your side. I am going to fix them to see whether we are "lucky".
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #20 from JuzheZhong --- I am not able to build and test SPEC since I don't have QEMU and SPEC environment. I should ask my colleague to do that but they are quite busy with company's things and frankly I can't pull more resource on open source work from my company.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #19 from JuzheZhong --- (In reply to Vineet Gupta from comment #18) > (In reply to JuzheZhong from comment #17) > > PLCT told me they passed with zvl256b. > > > > I always run SPEC with FIXED-VLMAX since we always care about peak > > performance > > on our board. > > Sure we all have our preferred peak performance configs. But the compiler > needs to work for all vendors' configs. So as a test, can you try a scalable > build run at your end to at least see if you can see those issues ? I am not able to build and test SPEC since I don't have QEMU and SPEC environment. I should ask my colleague to do that but they are quite busy with company's things and frankly I can't pull more resource on open source work from my company.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #18 from Vineet Gupta --- (In reply to JuzheZhong from comment #17) > PLCT told me they passed with zvl256b. > > I always run SPEC with FIXED-VLMAX since we always care about peak > performance > on our board. Sure we all have our preferred peak performance configs. But the compiler needs to work for all vendors' configs. So as a test, can you try a scalable build run at your end to at least see if you can see those issues ?
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #17 from JuzheZhong --- PLCT told me they passed with zvl256b. I always run SPEC with FIXED-VLMAX since we always care about peak performance on our board.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #16 from Vineet Gupta --- (In reply to JuzheZhong from comment #15) > Currently, we don't have much run FAIL and ICE left in full coverage testing. > > I suspect it is very corner case in SPEC. > > You don't have to debug it. Just need to give me a preprocessed source file. > > Like this: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110560 > > You can see google highway folks attachment is very big but I still can fix > the issue as long as you can give me some sources that I can reproduce the > issues. As I mentioned already these are runtime failure mismatches, so we don't know where the issue is and thus no reduced test case. FWIW I could/would have debugged gcc code it if I had a reduced test. So we need to dig down into guts of the benchmark and see where the output is generated, checkpoint and so on so forth etc. The other approach is to try "defeature" autovec and see if can point to broad areas (in backend/middle-end) where the issue could be. e.g. - simple vs. lazy vsetvl - disabling reductions etc. BTW I'm surprised you are not seeing these as there is nothing rivos specific here. Are you running the full SPEC suite, including Fortran / Float workloads.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #15 from JuzheZhong --- Currently, we don't have much run FAIL and ICE left in full coverage testing. I suspect it is very corner case in SPEC. You don't have to debug it. Just need to give me a preprocessed source file. Like this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110560 You can see google highway folks attachment is very big but I still can fix the issue as long as you can give me some sources that I can reproduce the issues.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #14 from Vineet Gupta --- (In reply to Vineet Gupta from comment #13) > (In reply to JuzheZhong from comment #12) > > (In reply to Patrick O'Neill from comment #11) > > > (In reply to Patrick O'Neill from comment #10) > > > > I've kicked off 2 spec runs (zvl 128 and 256) using > > > > r14-6765-g4d9e0f3f211. > > > > I'll let you know the results when they finish. > > > > > > My terminal crashed - so these are partial results: > > > zvl256: 3 runtime failures > > > 531.deepsjeng > > > ??? > > > ??? At least 549.fotonik3d runtime failure with vl256 remains even with simple_vsetvl.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 Vineet Gupta changed: What|Removed |Added CC||vineetg at gcc dot gnu.org --- Comment #13 from Vineet Gupta --- (In reply to JuzheZhong from comment #12) > (In reply to Patrick O'Neill from comment #11) > > (In reply to Patrick O'Neill from comment #10) > > > I've kicked off 2 spec runs (zvl 128 and 256) using r14-6765-g4d9e0f3f211. > > > I'll let you know the results when they finish. > > > > My terminal crashed - so these are partial results: > > zvl256: 3 runtime failures > > 531.deepsjeng > > ??? > > ??? > > > > zvl128: 1 runtime failure > > 527.cam4_r > > > > If I had to guess I would say the 2 ??? fails are the existing 521/549. > > You mean those 2 cases are still failing? > Do you have any ideas to locate those FAIL and extract them as a simple case? > zvl128 / no vl: 1 runtime failure > 527.cam4_r Yes this still remains. It is hard to debug (for me at least) as this is fortran. However this goes away if simple_vsetvl is used (with -Ofast for rest of buiild) - using [1] [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641342.html
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #12 from JuzheZhong --- (In reply to Patrick O'Neill from comment #11) > (In reply to Patrick O'Neill from comment #10) > > I've kicked off 2 spec runs (zvl 128 and 256) using r14-6765-g4d9e0f3f211. > > I'll let you know the results when they finish. > > My terminal crashed - so these are partial results: > zvl256: 3 runtime failures > 531.deepsjeng > ??? > ??? > > zvl128: 1 runtime failure > 527.cam4_r > > If I had to guess I would say the 2 ??? fails are the existing 521/549. You mean those 2 cases are still failing? Do you have any ideas to locate those FAIL and extract them as a simple case?
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #11 from Patrick O'Neill --- (In reply to Patrick O'Neill from comment #10) > I've kicked off 2 spec runs (zvl 128 and 256) using r14-6765-g4d9e0f3f211. > I'll let you know the results when they finish. My terminal crashed - so these are partial results: zvl256: 3 runtime failures 531.deepsjeng ??? ??? zvl128: 1 runtime failure 527.cam4_r If I had to guess I would say the 2 ??? fails are the existing 521/549.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 Patrick O'Neill changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #10 from Patrick O'Neill --- I've kicked off 2 spec runs (zvl 128 and 256) using r14-6765-g4d9e0f3f211. I'll let you know the results when they finish. Thanks for the quick fix on this bug!
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #9 from JuzheZhong --- It's fixed on the trunk. I wonder whether it can fix the issues that you (RIVOS) fail to run SPEC 527 and. 549 We have fixed several issues recently, could you use the latest trunk GCC to run SPEC today ?
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #8 from GCC Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:008b80e42eb7cb55c6a2ef55728241b8733dfd17 commit r14-6761-g008b80e42eb7cb55c6a2ef55728241b8733dfd17 Author: Juzhe-Zhong Date: Wed Dec 20 14:55:26 2023 +0800 RISC-V: Optimize SELECT_VL codegen when length is known as smaller than VF While trying to fix bugs of PR113097, notice this following situation we generate redundant vsetvli _255 = SELECT_VL (3, POLY_INT_CST [4, 4]); COND_LEN (..., _255) Before this patch: vsetivli a5, 3... ... vadd.vv (use a5) After this patch: ... vadd.vv (use AVL = 3) The reason we can do this is because known_ge (3, [4,4]) is true. It's safe to apply such optimization Tested on both RV32 and RV64 full coverage testing, no regression. PR target/113087 gcc/ChangeLog: * config/riscv/riscv-v.cc (expand_select_vl): Optimize SELECT_VL. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/pr113087-2.c: New test.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #7 from GCC Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:d82bb518fa372cc30cc3352e0a124d0bd6deb36f commit r14-6760-gd82bb518fa372cc30cc3352e0a124d0bd6deb36f Author: Juzhe-Zhong Date: Wed Dec 20 14:50:11 2023 +0800 RISC-V: Fix bug of VSETVL fusion This patch fixes bugs in the fusion of this following case: li a5,-1 vmv.s.x v0,a5 -> demand any non-zero AVL vsetvli a5, ... Incorrect fusion after VSETVL PASS: li a5,-1 vsetvli a5... vmv.s.x v0, a5 --> a5 is modified as incorrect value. We disallow this incorrect fusion above. Full coverage testing of RV64 and RV32 no regression. PR target/113087 gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc: Disallow fusion when VL modification pollutes non AVL use. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/pr113087-1.c: New test.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #6 from Patrick O'Neill --- (In reply to JuzheZhong from comment #5) > ... > I confirmed it is vsetvl bugs. But I wonder whether you have open source the > random generator ? > > If yes, may be we can dedicate some resources to run random tests too. I use csmith as the random generator and try to fuzz targets that don't have any execution fails/ICEs (currently just rv64gcv/rv64gcv_zvl256b). https://github.com/csmith-project/csmith I was planning on getting the fuzzer and a random config builder running on spare precommit compute but haven't set it up yet. I'll clean up/put the shell scripts I use for csmith here tomorrow: https://github.com/patrick-rivos/gcc-fuzz-ci
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #5 from JuzheZhong --- (In reply to Patrick O'Neill from comment #4) > I can attempt to reduce them however running an iteration of 549 takes > multiple hours so it might be challenging using my current setup (creduce). > Hopefully the random generator stumbles across the same issue and it can get > fixed that way since it's worked for other spec fails previously. I confirmed it is vsetvl bugs. But I wonder whether you have open source the random generator ? If yes, may be we can dedicate some resources to run random tests too.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #4 from Patrick O'Neill --- I can attempt to reduce them however running an iteration of 549 takes multiple hours so it might be challenging using my current setup (creduce). Hopefully the random generator stumbles across the same issue and it can get fixed that way since it's worked for other spec fails previously.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #3 from JuzheZhong --- (In reply to Patrick O'Neill from comment #2) > No, this is from a random generator but the 527/549 issues could be related? > I haven't reduced spec fails. I can't reproduce spec fails. We have tested it on both QEMU and K230 with -march=rv64gcv_zvl256b, all passed. Could you reduce spec fails ?
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #2 from Patrick O'Neill --- No, this is from a random generator but the 527/549 issues could be related? I haven't reduced spec fails.
[Bug target/113087] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087 --- Comment #1 from JuzheZhong --- Is this coming from SPEC 527 or 549 ?
