https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #29 from Li Pan <pan2.li at intel dot com> --- (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
