tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

gcc 16 bootstrap, stage 2 and 3 differ



Hi!

I've tried asking upstream, but I only heard crickets.
https://gcc.gnu.org/pipermail/gcc-help/2026-August/145120.html

I have a problem when packaging gcc 16.1.0 for pkgsrc.  Using the same
flags and patches that work for gcc 15.3.0, I see a problem late in
the build when the stage2 and stage3 files are compared:

Comparing stages 2 and 3
warning: gcc/cobol/parse.o differs
Bootstrap comparison failure!
gcc/build/genoutput.o differs
gcc/build/gensupport.o differs
gcc/build/genrecog.o differs
gcc/build/genmatch.o differs
... and many more ...

Looking at one of them in detail with objdump, I see that that the
generated code is the same:

$ objdump -d /tmp/wip/gcc16/work/build/stage2-gcc/c/c-decl.o > /tmp/stage2
$ objdump -d /tmp/wip/gcc16/work/build/stage3-gcc/c/c-decl.o > /tmp/stage3
$ diff /tmp/stage?
2c2
< /tmp/wip/gcc16/work/build/stage2-gcc/c/c-decl.o:     file format elf64-x86-64
---
> /tmp/wip/gcc16/work/build/stage3-gcc/c/c-decl.o:     file format elf64-x86-64

but there are differences in the debug sections:

$ objdump --dwarf=loc /tmp/wip/gcc16/work/build/stage2-gcc/c/c-decl.o > /tmp/stage2.dwarfloc
$ objdump --dwarf=loc /tmp/wip/gcc16/work/build/stage3-gcc/c/c-decl.o > /tmp/stage3.dwarfloc
$ diff -u /tmp/stage?.dwarfloc |less
--- /tmp/stage2.dwarfloc        2026-08-10 17:47:38.617582857 +0000
+++ /tmp/stage3.dwarfloc        2026-08-10 17:47:43.673454224 +0000
@@ -1,10 +1,10 @@

-/tmp/wip/gcc16/work/build/stage2-gcc/c/c-decl.o:     file format elf64-x86-64
+/tmp/wip/gcc16/work/build/stage3-gcc/c/c-decl.o:     file format elf64-x86-64

 Contents of the .debug_loclists section:

 Table at Offset 0
-  Length:          0x2665e
+  Length:          0x2667b
   DWARF version:   5
   Address size:    8
   Segment size:    0
@@ -4086,8229 +4086,8225 @@
     000030ae v000000000000000 v000000000000000 location view pair
     000030b0 v000000000000000 v000000000000000 location view pair
     000030b2 v000000000000000 v000000000000000 location view pair
+    000030b4 v000000000000000 v000000000000000 location view pair

-    000030b4 0000000000000047 (base address)
-    000030bd v000000000000000 v000000000000000 views at 000030aa for:
+    000030b6 0000000000000047 (base address)
+    000030bf v000000000000000 v000000000000000 views at 000030aa for:
              0000000000000047 00000000000000d7 (DW_OP_reg4 (rsi))
-    000030c3 v000000000000000 v000000000000000 views at 000030ac for:
-             00000000000000d7 0000000000000156 (DW_OP_reg11 (r11))
-    000030ca v000000000000000 v000000000000000 views at 000030ae for:
+    000030c5 v000000000000000 v000000000000000 views at 000030ac for:
+             00000000000000d7 00000000000000e8 (DW_OP_breg0 (rax): -1; DW_OP_stack_value)
+    000030ce v000000000000000 v000000000000000 views at 000030ae for:
+             00000000000000e8 0000000000000156 (DW_OP_reg11 (r11))
+    000030d5 v000000000000000 v000000000000000 views at 000030b0 for:
              00000000000002b9 00000000000002c7 (DW_OP_reg11 (r11))
-    000030d1 v000000000000000 v000000000000000 views at 000030b0 for:
+    000030dc v000000000000000 v000000000000000 views at 000030b2 for:
              00000000000002e7 00000000000002fe (DW_OP_reg4 (rsi))
-    000030d8 v000000000000000 v000000000000000 views at 000030b2 for:
+    000030e3 v000000000000000 v000000000000000 views at 000030b4 for:
              0000000000000442 000000000000044d (DW_OP_reg4 (rsi))
-    000030df <End of list>
+    000030ea <End of list>

(over 70000 more lines follow)

Does anyone have an idea where this difference might come from?

For now, the package (lang/gcc16) is using the --disable-bootstrap
workaround.

Thanks,
 Thomas


Home | Main Index | Thread Index | Old Index