https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119977
--- Comment #18 from Sam James <sjames at gcc dot gnu.org> --- Made a little bit of progress. I have it semi-standalone but it needs headers from the same directory. * Script to reproduce the comparison failure on trunk: https://gcc.gnu.org/bugzilla/attachment.cgi?id=61229 * Script I've been reducing & bisected the difference with: https://gcc.gnu.org/bugzilla/attachment.cgi?id=61314 * It is GC-related. Setting different `--param ggc-min-expand= --param=ggc-min-heapsize=` makes it work. * Reduction is therefore very painful and slow. * Bisection was done with a hacked up `contrib/compare-lto` to always fail so that the stage2-*, stage3-* layout was retained (happens when a failure happens, couldn't easily replicate that otherwise) then using the gccs from stage2+stage3. * Bisecting between basepoints/gcc-15 and trunk for a difference in a constant source file (reduced gimple-match-6.cc from r16-152-g4f7b3c24112016) yields r15-7652-ga2755339c6c983. i.e. From r15-7652-ga2755339c6c983, stage2 gcc with `-march=znver4 -O2 -ggdb3 -fno-checking` produces different results from stage3 gcc w/ `-march=znver4 -O2 -ggdb3 -fchecking=1` with `.gnu.lto_.decls.1` changing size. If it is that commit, that would mean it's the same as our downstream reported issue in i386.o (which I haven't yet reproduced w/ vanilla sources with no default changes etc). (Previously, `.gnu.lto_.jmpfuncs.1` was changing, but I couldn't reproduce that with a certain reduction, so changed it to make progress rather than restarting.) I'll try reproduce / confirm the bisect result next and get a tarball to share.
