https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124042
Bug ID: 124042
Summary: Miscompare of 482.sphinx3 on aarch64 since
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: needs-bisection
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pheeck at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
Host: aarch64-gnu-linux
Target: aarch64-gnu-linux
When you run the SPEC CPU 2006 benchmark 482.sphinx3 compiled with -Ofast
-march=native and PGO (-fprofile-use) on a Neoverse V2 (Nvidia Grace) machine
you get a miscompare:
*** Miscompare of an4.log; for details see
/home/fkastl/gcc/benchmarks/cpu2006/benchspec/CPU2006/482.sphinx3/build/build_peak_amd64-m64-mine.0000/an4.log.mis
Error (VE) with training run!
*** Error building 482.sphinx3
In an4.log.mis, you find:
0081: 758 126 162 -536738 -148846 0 T
748 126 162 -536738 -148846 0 T
^
0082: 959 163 185 -543175 -74100 -1 <sil>
949 163 185 -543175 -74100 -1 <sil>
^
0083: 1311 186 200 -229603 -148846 0 N
1301 186 200 -229603 -148846 0 N
^
0084: 1978 201 284 -1557179 -74100 -1 <sil>
1968 201 284 -1557179 -74100 -1 <sil>
^
0085: 2387 285 341 -1032179 -74100 -1 <sil>
2377 285 341 -1032179 -74100 -1 <sil>
^
0086: 2784 342 365 -307526 -148846 0 U
2774 342 365 -307526 -148846 0 U
^
0087: 3153 366 397 -459018 -74100 -1 <sil>
3120 366 397 -459018 -74100 -1 <sil>
^
0088: 3155 398 398 0 -148846 0 </s>
3122 398 398 0 -148846 0 </s>
^
0095: INFO: utt.c(337): 398 frm; 1719 sen, 11839 gau/fr, Sen 0.00 CPU 0.00
Clk [Ovrhd 0.00 CPU 0.00 Clk]; 857 hmm, 8 wd/fr, 0.00 CPU 0.00 Clk
(an406-fcaw-b)
INFO: utt.c(337): 398 frm; 1717 sen, 11827 gau/fr, Sen 0.00 CPU 0.00
Clk [Ovrhd 0.00 CPU 0.00 Clk]; 854 hmm, 8 wd/fr, 0.00 CPU 0.00 Clk
(an406-fcaw-b)
^
0098: INFO: lm.c(826): 31358 bg(), 31346 bo; 1 fills, 1 in
mem (50.0%)
INFO: lm.c(826): 30478 bg(), 30466 bo; 1 fills, 1 in
mem (50.0%)
^
You don't have to do a "size ref" run, "size test" suffices. The miscompare is
detected on the output of the training run. Which is strange since I couldn't
reproduce the bug without using PGO. I guess that adding instrumentation
somehow influences some optimizations and they're more aggressive?
Not sure when this started happening. It was sooner than December 2025.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
