I noticed that compiling my C++ project with 7.0 at -O3 took twice as much time as before with earlier major versions. First I thought that it might be that 7.0 used more optimizations, but a significant time difference remained even with -O0: 5.4.1 6.2.1 7.0.0 -O0 2m10 2m18 3m43 -O1 2m45 2m51 5m38 -O2 3m24 3m26 6m46 -O3 3m25 3m34 7m05 Also did measurements with the gcc source, compiling the master branch (b55f1f4) with for o in 0 1 2 3; do for v in 4.9.2 5.4.1 6.2.1 7.0.0; do rm -Rf *; ../configure CC=gcc-$v CXX=g++-$v --enable-languages=c,c++ --disable-multilib --program-suffix=-`cat ../gcc/BASE-VER` --disable-bootstrap CFLAGS="-O$o -march=native" CXXFLAGS="-O$o -march=native"; time make -j8; echo "-O$o $v"; echo hit enter to continue; read x; done; done 4.9.2 5.4.1 6.2.1 7.0.0 -O0 7m15 7m12 7m28 8m18 -O1 7m11 7m13 7m02 9m11 -O2 8m19 8m17 8m24 10m57 -O3 8m53 8m57 9m05 12m03 The tests were done on a PC with Debian Jessie 64bit, AMD FX-8150 @ 4GHz, 16GB RAM, XFS on SSD. $ gcc-4.9.2 -v Using built-in specs. COLLECT_GCC=gcc-4.9.2 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-languages=c,c++ --disable-multilib --program-suffix=-4.9.2 Thread model: posix gcc version 4.9.2 20140808 (prerelease) (GCC) $ gcc-5.4.1 -v Using built-in specs. COLLECT_GCC=gcc-5.4.1 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.4.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --enable-languages=c,c++ --disable-multilib --program-suffix=-5.4.1 --disable-bootstrap CFLAGS='-O2 -march=native' CXXFLAGS='-O2 -march=native' Thread model: posix gcc version 5.4.1 20160829 (GCC) $ gcc-6.2.1 -v Using built-in specs. COLLECT_GCC=gcc-6.2.1 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../configure --enable-languages=c,c++ --disable-multilib --program-suffix=-6.2.1 --disable-bootstrap CFLAGS='-O2 -march=native' CXXFLAGS='-O2 -march=native' Thread model: posix gcc version 6.2.1 20160831 (GCC) $ gcc-7.0.0 -v Using built-in specs. COLLECT_GCC=gcc-7.0.0 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../configure --enable-languages=c,c++ --disable-multilib --program-suffix=-7.0.0 --disable-bootstrap CFLAGS='-O2 -march=native' CXXFLAGS='-O2 -march=native' Thread model: posix gcc version 7.0.0 20160831 (experimental) (GCC)
What happens if you configure gcc trunk with --enable-checking=release ? The released versions default to that already and when GCC 7 is released, it will also be that default too.
Thanks, --enable-checking=release did the trick. Those unreleased checks definitely have some runtime cost :) My project was built in 3m35 with -O3, and the gcc master branch: 7.0.0 -O0 7m30 -O1 7m00 -O2 8m23 -O3 9m02 These are effectively the same as with 6.2.1. Sorry for the noise.
Closing as invalid then. That is --enable-checking=release gets us to where 6.2.1 was.
.
(In reply to petschy from comment #2) > Thanks, --enable-checking=release did the trick. Those unreleased checks > definitely have some runtime cost :) Yes in some cases there are O(n^2) checking functions which hurt compile time. Plus running more and more checking hurts cache locality too.
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.
We already output one if you use -ftime-report.
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.