Update arm gcc toolchain from gcc 7.3.1 to gcc 8

[dhalbert]

Currently we are using gcc-arm-none-eabi-7-2018-q2-update. 8-2018q4-major is available. There will probably be another release sometime in June 2019.

See this comment, which is interesting, and is cautious about moving forward: https://bugs.launchpad.net/gcc-arm-embedded/+bug/1820593/comments/1.

Compiling the en_US Trinket M0 build with the new release produces slightly smaller code:
2972 bytes free in flash out of 188160 bytes ( 183.75 kb )
vs
2836 bytes free in flash out of 188160 bytes ( 183.75 kb )

This is not that significant, so we could hold off until the June release and see how that works.

[dhalbert]

The ARM 8-2019-q3 release, using gcc 8.3.1, was released on July 10. It is not available in a Linux ppa, only as a tarball. It fixes some issues in the previous gcc8 release related to LTO.

[jepler]

I found, and @dhalbert confirmed, that the 8-2019-q3 compiler is significantly slower (more than 3x as long!) to build. The whole build doesn't succeed on travis, because it exceeds the 50 minute timeout for jobs.

Old compiler (7-2018-q3-update):

Build trinket_m0_haxpress for pl took 72.58s and succeeded
Build trinket_m0_haxpress for zh_Latn_pinyin took 18.23s and succeeded

https://travis-ci.com/adafruit/circuitpython/jobs/221025799

New compiler (8-2019-q3-update):

Build trinket_m0_haxpress for pl took 199.69s and succeeded
Build trinket_m0_haxpress for zh_Latn_pinyin took 61.75s and succeeded

https://travis-ci.org/jepler/circuitpython/jobs/566215443

[dhalbert]

I speculated this might be -flto, but other people are also seeing much slower compile times: https://community.arm.com/developer/tools-software/oss-platforms/f/gnu-toolchain-forum/13503/gcc-g-version-8-very-slow-to-compile

[dhalbert]

I left this comment in the ARM community thread linked above:
https://community.arm.com/developer/tools-software/oss-platforms/f/gnu-toolchain-forum/13503/gcc-g-version-8-very-slow-to-compile/159410#159410

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.

[dhalbert]

@jepler and I confirmed that the downloadable toolchains are not built optimized: https://community.arm.com/developer/tools-software/oss-platforms/f/gnu-toolchain-forum/13503/gcc-g-version-8-very-slow-to-compile/159420#159420:

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

...