Currently stage2 and 3 use the same warning options, but that is redundant: if any warnings are generated, they will be present at stage2 (and stop bootstrap). By not enabling any warnings for stage3, we would get checking that warnings do not affect code generation. Note that simply adding -w at stage3 doesn't work, as it simply suppresses the warning at print time. I tried leaving only -Wno-narrowing in warning flags and got many comparison failures: Comparing stages 2 and 3 warning: gcc/cc1obj-checksum.o differs Bootstrap comparison failure! gcc/calls.o differs gcc/dwarf2out.o differs gcc/loop-iv.o differs gcc/generic-match.o differs gcc/ipa-inline.o differs gcc/builtins.o differs gcc/optabs.o differs gcc/tree-vrp.o differs gcc/profile.o differs gcc/i386.o differs gcc/cfgexpand.o differs gcc/simplify-rtx.o differs gcc/gimple-ssa-sprintf.o differs gcc/expr.o differs gcc/print-tree.o differs gcc/gimple-match.o differs gcc/godump.o differs gcc/gimple-ssa-nonnull-compare.o differs gcc/targhooks.o differs gcc/tree-ssa-live.o differs gcc/gimple-ssa-warn-restrict.o differs gcc/tree-ssa-ccp.o differs gcc/gimplify.o differs gcc/tree-cfg.o differs gcc/tree-pretty-print.o differs make: *** [compare] Error 1
That's bad. I guess the range-warnings are guilty here. It would be interesting to check whether it works OK with GCC 7 (or GCC 6). But confirmed, this would be a good idea! Martin should have an idea what warning flags control the range-setting so we can see if we can survive with explicitely adding those.
(In reply to Alexander Monakov from comment #0) > I tried leaving only -Wno-narrowing in warning flags and got many comparison > failures For maximum differences, we should switch to -Wnarrowing in the previous stage so that there's a point in explicitly disabling it in the next one.
I wouldn't be surprised if the build fails with -Wnarrowing (but maybe that should be fixed anyway, so we can build with non-GNU compilers that default to C++11 or later).
Yep, that's correct: -Wno-narrowing is necessary for build to succeed at all.
(In reply to Jonathan Wakely from comment #3) > I wouldn't be surprised if the build fails with -Wnarrowing (but maybe that > should be fixed anyway, so we can build with non-GNU compilers that default > to C++11 or later). Well yes, that was my ulterior motive for suggesting it... ;-)
GCC 7 sadly has a similar list of miscomparing files. Did not check GCC 6 yet. So far I managed to catch one set of misbehaving warnings by checking testsuite fallout with -fcompare-debug=-Wall, but unfortunately fixing those would not reduce the number of bootstrap miscompares: PR 86567.
cp/mangle.o miscompares due to -Wsign-compare, possibly due to caching in maybe_constant_value as in the above PR.
Other files seem to miscompare due to -Wnonnull-compare: PR 86569.
One more: -Wimplicit-fallthrough issue uncovered by the testsuite: PR 86575. So far all issues appeared in gcc-6 or more recent.
If this is becoming the meta-bug for all warnings that affect codegen, then I'd like to add bug 61579 (-Wwrite-strings) as at least semi-related... (not sure if toggling it causes miscompares though)
(In reply to Eric Gallager from comment #10) > If this is becoming the meta-bug for all warnings that affect codegen, then > I'd like to add bug 61579 (-Wwrite-strings) as at least semi-related... (not > sure if toggling it causes miscompares though) That one is *supposed* to affect codegen (so maybe it should be a -f option instead).
(In reply to Jonathan Wakely from comment #11) > (In reply to Eric Gallager from comment #10) > > If this is becoming the meta-bug for all warnings that affect codegen, then > > I'd like to add bug 61579 (-Wwrite-strings) as at least semi-related... (not > > sure if toggling it causes miscompares though) > > That one is *supposed* to affect codegen (so maybe it should be a -f option > instead). hm, I could've sworn there was already an -f option with a similar name, but after checking the manual I can't seem to find it after all, so... I guess making it an -f option could work.