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
View all questions in GNU Toolchain forum