With the latest gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2 compiler tools release, g++ is very slow to compile relative to the older gcc-arm-none-eabi-7-2017-q4-major-linux.tar.bz2 release.
I am seeing it take over 3 times longer than the previous compiler. A previously 45 second build now takes 2.5 minutes.
Is this to be expected ?
Are there any compiler flags that will speed this up (less optimisations) as it is now taking a significant time to build things ?
We've just released 8-2019-q3-update. Could you please give it a try and check if you're still seeing this issue? If you are, then a narrowed down test case with commandline options would be useful.
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.
Have you seen these - things which can ...s...l...o...w... you down:
Yes, but this issue is under Linux and on the same OS version. gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2 compiler tools release, g++ is 3x slower than the gcc-arm-none-eabi-7-2017-q4-major-linux.tar.bz2 release at compiling C++ code in general. I suspect it is the same under MsWindows, can anyone that has MsWindows try this ?
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 @@
if [ "x$BUILD" == "xx86_64-apple-darwin10" ] || [ "x$is_ppa_release" == "xyes" ]; then
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.
Bug confirmed and will be fixed 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?