https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #3 from Mikael Pettersson <mikpelinux at gmail dot com> --- Created attachment 45384 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45384&action=edit pre-processed source for libiberty/sort.c One of the smallest .o files that differ is from libiberty's sort.c (pre-processed source attached as sort.i; sorry haven't had time to minimize it). stage1 and stage2 generate different code for this file: > stage1-gcc/xgcc -Bstage1-gcc -O2 -S -o sort.s-stage1 sort.i > stage2-gcc/xgcc -Bstage2-gcc -O2 -S -o sort.s-stage2 sort.i > diff -u sort.s-stage[12] | wc 109 460 2005 > diff -u sort.s-stage[12] | head --- sort.s-stage1 2019-01-08 22:10:50.288929388 +0100 +++ sort.s-stage2 2019-01-08 22:10:59.148975673 +0100 @@ -21,21 +21,23 @@ sort_pointers: @ args = 0, pretend = 0, frame = 1024 @ frame_needed = 0, uses_anonymous_args = 0 - push {r4, r5, r6, r7, r8, lr} - lsl r7, r0, #2 + push {r4, r5, r6, r7, r8, r9, lr} + lsl r8, r0, #2 I wasn't able to trigger anything with -fcompare-debug, using either of the stage1 or stage2 compilers. Looking though the build log, I noticed that stage1 compiles stage2 with -fno-checking, while stage2 compiles stage3 with -fchecking=1. (This is deliberate according to the top-level Makefile.tpl.) Stage1 generates the same code for sort.i with -fno-checking or -fchecking=1, and stage2 does the same. Finally I checked the stage3 compiler and it generates the exact same code as the stage1 does. To me it looks like -fno-checking (possibly in combination with --enable-checking=release) causes some breakage somewhere.
