On Fri, Oct 20, 2017 at 12:40 PM, Thomas Schwinge <tho...@codesourcery.com> wrote: > Hi! > > In <https://gcc.gnu.org/PR77620>, we got a user wonder about released vs. > trunk GCC execution times, not knowing that the latter has more run-time > checking enabled. Once that got clarified, the discussion proceeded: > > (In reply to petschy from comment #6) >> Would it be sensible to put an extra line to the output of 'gcc/g++ -v' if >> the slow checks are enabled, which just states this fact / warns about >> (possibly mentioning the use of --enable-checking=release at configure)? >> Future tickets like this might be avoided this way. > > (In reply to Andrew Pinski from comment #7) >> We already output one if you use -ftime-report. > > (In reply to Jonathan Wakely from comment #8) >> We get reports like this every few months, and nobody ever uses >> -ftime-report before filing a bug. I think something in the -v output would >> be useful. > > We kind-of already report that by means of "--enable-checking=[...]" as > part of the "Configured with:" line: > > $ gcc-6 -v 2>&1 | sed -n '/^Configured with: /s%.*--enable-checking=\([^ > ]*\).*%\1%p' > release > > $ build-gcc/gcc/xgcc -v 2>&1 | sed -n '/^Configured with: > /s%.*--enable-checking=\([^ ]*\).*%\1%p' > yes,df,fold,extra,rtl > > Though, that only gets displayed if "--enable-checking=[...]" has been > specified explicitly, I think? > > > Is that is generally considered useful, should I look into adding a > separate "Run-time checking: [...]" line? Should that just print the > configured checks, or also some "slow!" notice, as suggested? The latter > only for the really slow checks? Are we able to identify these > generally?
All checking slows down the compiler. I guess adding stuff to -v output might break scripts out in the wild... but yes, we could output the same boiler-plate as with -ftime-report. > > Also, from reading the documentation, I can't tell if (it's the idea > that) running checking-enabled GCC with "-fno-checking" would indeed get > rid of *all* the checking's run-time overhead? (Basically, if all > "ENABLE_*_CHECKING" usage is guarded by "flag_checking", too? Not yet > verified.) No, for example all the tree and rtl macro checking isn't guarded by flag_checking nor are gcc_checking_assert()s, etc. The flag wasn't intended to be used in the negative form but to allow better debugging of problems in a release checking compiler so when you get a random ICE you can run with -fchecking and immediately pinpoint a more useful place where things go wrong (you mostly get IL checking that way). Richard. > > Grüße > Thomas
