gcc 16.1.0 bootstrapping problem on NetBSD: stage2 and stage3 differ

Thomas Klausner via Gcc-help <[email protected]>
Newsgroups gmane.comp.gcc.help
Message-ID <[email protected]>
Hi!

I'm trying to package gcc 16.1.0 for pkgsrc. I'm running NetBSD
11.99.7/x86_64 with the built-in "gcc (nb3 20260428) 14.3.0" and "GNU
ld (NetBSD Binutils nb1) 2.46.0.20260210".

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)

Is this a known problem?

Is there a patch, or workaround except --disable-bootstrap?

For comparison, the working gcc15 package:
https://github.com/NetBSD/pkgsrc/tree/trunk/lang/gcc15

The gcc16 work-in-progress package:
https://github.com/NetBSD/pkgsrc-wip/tree/master/gcc16

Thanks,
 Thomas
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.