GCC g++ version 8 very slow to compile

I have just tried 8-2019-q3-update. Its compile time performance is the same as 8-2018-q4, ie 3x slower than the older 7-2017-q4.

The simple test I uploaded was compiled without any significant compiler flags: "arm-none-eabi-g++ -c -o main.o main.cpp". As stated I think compiling any C++ code appears to take 3x longer on these more recent releases.

I haven't checked actual CPU usage (I would probably have to create a huge C++ code file to really test this). Any other tests I could do at this stage, I assume the speed difference comes from the 7 to 8 update, perhaps by some new optimisation stages  ?

I have just tried 8-2019-q3-update. Its compile time performance is the same as 8-2018-q4, ie 3x slower than the older 7-2017-q4.

The simple test I uploaded was compiled without any significant compiler flags: "arm-none-eabi-g++ -c -o main.o main.cpp". As stated I think compiling any C++ code appears to take 3x longer on these more recent releases.

I haven't checked actual CPU usage (I would probably have to create a huge C++ code file to really test this). Any other tests I could do at this stage, I assume the speed difference comes from the 7 to 8 update, perhaps by some new optimisation stages  ?

Sorry, where did you upload the test case?

To the Arm support cases system accessible from "Support"  on this website: "GCC g++ version 8 very slow to compile - CAS-127711-P6Y6X7"

Any news on this issue ? Is there anything I can do to help track down the problem assuming there is one and it's not due to an extra optimisation stage/stages ?

We saw the same issue.

I am suspicious that the compiler build itself was done with at least some optimizations turned off. In the 7-2018-q2 (7.3.1) release, lib/cc1 is 20MB in size. In the 8-2018-q4 (8.2.1) and 8-2019-q3 (8.3.1) updates, it is 30MB, which is a huge increase.

By comparison, in the Arch build of arm-none-eabi-gcc for gcc8, which is 8.3.0, cc1 is only 21MB.

Perhaps the builder turned off optimization for debugging and forgot to turn it back on? Or was there some other reason? I haven't yet tried to build from source, or examine the source Makefiles.

A co-worker (GitHub @jepler) and I confirmed that the builds are not optimized: they are built without `-O2`. Between the 7-2018-q2 and 8-2018-q4 releases, some changes involving `CXXFLAGS` were made to `build-toolchain.sh`.

This diff makes optimized builds, though you may want to do it a different way, as we don't know the context for the CXXFLAGS changes.

--- /home/someone/eabi8/gcc-arm-none-eabi-8-2019-q3-update/build-toolchain.sh    2019-07-03 21:19:47.000000000 -0500
+++ ./build-toolchain.sh        2019-08-15 11:22:41.081622816 -0500
@@ -149,7 +149,7 @@
        done
 fi
 
-CXXFLAGS=
+CXXFLAGS="-O2 -g"
 if [ "x$BUILD" == "xx86_64-apple-darwin10" ] || [ "x$is_ppa_release" == "xyes" ]; then
     skip_mingw32=yes
     skip_mingw32_gdb_with_python=yes

Terry, Thanks for reporting and analyzing the issue. It is a confirmed bug in the build script and has just been fixed, in a way slightly different to what you shared. The updated script and binary package will be included in the next release.

Thanks for fixing this bug. Note it was Dan Halbert and his co-worker who actually tracked it down.

Joey, thanks for confirming this is the issue. Are you folks willing to make an interim re-release of 8-2019-q3 that fixes the problem? We'd like to move on to a newer version, but would rather not wait until December or January. As it stands the current compile times are so long that they would make our development cycle unpleasant, and make our CI jobs interminably long.

We could build it ourselves, but the build is painful and I haven't yet gotten a completely working gcc build.

Dan, Due to resource constraint we have no plan to introduce an additional release before the planned one. The solution I would suggest is to stay with the old version for a while, or build your own version. May I know which part of building process is painful for you so that we can probably improve the how-to-build manual?