https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121623

            Bug ID: 121623
           Summary: [ia64] bootstrap comparison failure (differently
                    ordered st8s in MMI for gcc/trans-mem.o), stage 2 -> 3
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: frank.scheiner at web dot de
  Target Milestone: ---
              Host: ia64-t2-linux-gnu
            Target: ia64-t2-linux-gnu
             Build: ia64-t2-linux-gnu

Created attachment 62166
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62166&action=edit
Patch to ignore bogus error during comparison

I pushed two bootstraps and testsuite runs for c and c++ through on my rx2800
i2 recently:

* GCC 15.1.0:
https://gcc.gnu.org/pipermail/gcc-testresults/2025-August/855566.html
* GCC 15.2.0
https://gcc.gnu.org/pipermail/gcc-testresults/2025-August/855308.html

For comparison (but for c, c++, fortran and objc):

* gcc-15-20240528 w/LRA enabled:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817268.html

For the bootstrap to succeed a patch is needed to overrule the following
comparison failure between stage 2 and stage 3 compile results for
`gcc/trans-mem.o` (patch's attached):

```
bash-5.2# date; time make -j9 bootstrap 2>&1 | tee
/srv/ssd/logs/15.1.0-RC-20250418/make.log; echo $?; date
[...]
make[2]: Entering directory '/dev/shm/gcc-15.1.0-RC-20250418/gcc.build.lnx'
make[3]: Entering directory '/dev/shm/gcc-15.1.0-RC-20250418/gcc.build.lnx'
rm -f stage_current
make[3]: Leaving directory '/dev/shm/gcc-15.1.0-RC-20250418/gcc.build.lnx'
Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/trans-mem.o differs
make[2]: *** [Makefile:23407: compare] Error 1
make[2]: Leaving directory '/dev/shm/gcc-15.1.0-RC-20250418/gcc.build.lnx'
make[1]: *** [Makefile:23387: stage3-bubble] Error 2
make[1]: Leaving directory '/dev/shm/gcc-15.1.0-RC-20250418/gcc.build.lnx'
make: *** [Makefile:23450: bootstrap] Error 2

real    331m2.512s
user    2360m28.519s
sys     27m9.219s
0
Sun Apr 20 17:28:52 UTC 2025
bash-5.2#x
```

It took some time to determine the actual reason for this miscompare - which
also played into not having testsuite results for the GCC 15 RCs - but the
actual difference is the order of two stores:

```
root@darkstar:/srv/ssd/gcc-15.1.0-RC-20250423/gcc.build.lnx# objdump -l -d
stage2-gcc/trans-mem.o.stripped > stage2-gcc/trans-mem.o.stripped.s  
root@darkstar:/srv/ssd/gcc-15.1.0-RC-20250423/gcc.build.lnx# objdump -l -d
stage3-gcc/trans-mem.o.stripped > stage3-gcc/trans-mem.o.stripped.s

root@darkstar:/srv/ssd/gcc-15.1.0-RC-20250423/gcc.build.lnx# diff -Nur
stage2-gcc/trans-mem.o.stripped.s stage3-gcc/trans-mem.o.stripped.s
--- stage2-gcc/trans-mem.o.stripped.s    2025-04-25 17:42:30.312500000 +0000
+++ stage3-gcc/trans-mem.o.stripped.s    2025-04-25 17:43:11.687500000 +0000
@@ -1,5 +1,5 @@

-stage2-gcc/trans-mem.o.stripped:     file format elf64-ia64-little
+stage3-gcc/trans-mem.o.stripped:     file format elf64-ia64-little


 Disassembly of section .text:
@@ -581,8 +581,8 @@
      bf0:    09 18 21 49 00 21     [MMI]       adds r35=72,r36
      bf6:    10 83 30 00 42 00                 adds r49=16,r12
      bfc:    06 00 00 84                       mov r48=r0;;
-     c00:    08 00 00 1e 98 11     [MMI]       st8 [r15]=r0
-     c06:    80 00 38 30 2b 00                 st8 [r14]=r0,8
+     c00:    08 40 00 1c 98 15     [MMI]       st8 [r14]=r0,8
+     c06:    00 00 3c 30 23 00                 st8 [r15]=r0
      c0c:    00 00 04 00                       nop.i 0x0
      c10:    09 78 80 42 00 21     [MMI]       adds r15=32,r33
      c16:    f0 02 bc 30 20 c0                 ld8 r47=[r47]
```
...as found out with Ski performing the above commands.

These stores look independent, so the order inside a bundle should be
negligible, also considering that instructions in a bundle are executed in
parallel. Hence I figured both compile results are actually valid. This is also
the only file and place where it happens. Why it happens is yet unclear.

This wasn't present in gcc-15-20240528 yet AFAIR, but GCC 15.1.0 RC1
(15.1.0-RC-20250418) had it already and it's there ever since (also observed
for GCC 15.1.0 and 15.2.0).

Unfortunately I have no idea where to actually start looking in the compiler
code to figure that one out.

Reply via email to