On Linux/ia32, revision 151575 gave: Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/gcov.o differs gcc/gcov-dump.o differs gcc/coverage.o differs make[5]: *** [compare] Error 1 make[5]: Leaving directory `/export/gnu/import/svn/gcc-test/bld' make[4]: *** [stage3-bubble] Error 2 make[4]: Leaving directory `/export/gnu/import/svn/gcc-test/bld' make[3]: *** [bootstrap] Error 2
*** Bug 41326 has been marked as a duplicate of this bug. ***
Problem is also seen of i386-*-freebsd
It was introduced between revision 151561 and revision 151575.
I can reproduce this, and it appears the differences are between stage1 and stage2 compiled objects, not -g vs. -g -gtoggle. Will try now a bootstrap without -gtoggle in STAGE2_CFLAGS.
Even without -gtoggle it fails the same way. For gcov.c (haven't looked at the other ones) the differences start between stage1 and stage2 cc1 in the bswap pass, in stage2 dump there is nothing (just ; Function lines), in stage1 dump there are some functions and several replacements made. Looking into it.
I bet the bug is in r151573, tree-ssa-math-opts.s difference between stage1 compiled tree-ssa-math-opts.c done using a day old stage1 cc1 and current stage1 cc1 is: @@ -1050,7 +1050,7 @@ find_bswap_1: addl $-1, 64(%esp) movl %edx, 68(%esp) movl 64(%esp), %edx - adcl $-1, 68(%esp) + adcl $0, 68(%esp) movl 68(%esp), %ecx andl %edx, (%edi) andl %ecx, 4(%edi) @@ -1368,7 +1368,7 @@ find_bswap_1: addl $-1, 80(%esp) movl %edx, 84(%esp) movl 80(%esp), %edx - adcl $-1, 84(%esp) + adcl $0, 84(%esp) movl 84(%esp), %ecx andl (%edi), %edx andl 4(%edi), %ecx @@ -1738,7 +1738,7 @@ execute_optimize_bswap: movl 40(%esp), %eax movl %edx, 44(%esp) movl 40(%esp), %edx - adcl $-1, 44(%esp) + adcl $0, 44(%esp) movl 44(%esp), %ecx andl $67305985, %eax movl %eax, 56(%esp) which strongly suggests the shifting got broken.
Seems it is convert_modes (DImode, DImode, (const_int -1), 1) call. It used to correctly return (const_int -1), now it returns (const_double -1 [0xffffffff] 0 [0x0] 0 [0x0] 0 [0x0] 0 [0x0] 0 [0x0]).
Created attachment 18562 [details] gcc45-pr41324.patch Patch I'm going to bootstrap/regtest.
Revision 151573 is the cause.
(In reply to comment #8) > Created an attachment (id=18562) [edit] > gcc45-pr41324.patch > > Patch I'm going to bootstrap/regtest. So we now go through half of convert_modes to return the identity? Very nice...
If you want to revert the original convert_modes patch, sure, that's an option as well. This patch fixed the bootstrap without the reversion though...
> If you want to revert the original convert_modes patch, sure, that's an option > as well. This patch fixed the bootstrap without the reversion though... Right, but reverting an incorrect patch should be a pleasure. :-)
I'll leave that decision to you RTL maintainers ;) Anyway, without my patch I think even convert_modes (DImode, TImode, (const_int -1), 1) will return (const_double 0xffffffff) on 32-bit HWI hosts, which is definitely wrong. I doubt anyone calls that routine with such arguments, but anyway.
I think we should revert revision 151573 and find a better fix for PR 39779.
Aforementioned patch has been reverted.