Qmk_firmware: GCC 9.x compatibility

[chax]

Hi, i'm a Solus user and maintainer of avr-gcc and arm-none-eabi-gcc packages in Solus.
Solus currently has main GCC version upgraded to 9.2.0, but I as a maintainer of avr/arm variants held back GCC to version 8.3.0 because of some compatibiliy issues with GCC 9.x and QMK.

Recently this PR #5947 has also been merged into QMK, giving Solus users ability to build their firmwares on their Solus machines. Since Solus is rolling release distro (like Arch or openSUSE Tumbleweed), all users who keep their system up to date will get latest versions of every package in repo, which includes avr/arm GCC if i update them.

Currently i've been testing new versions of GCC 9.2.0 locally and i had some issues building both avr and arm versions of QMK firmware.

First to tackle AVR boards, i tested by trying to build planck rev5 and rev4 (which i don't have in possession but i can at least try to build it). I successfully built firmware but resulting .hex file appears to be to large and it finishes with error:

Copying planck_rev5_default.hex to qmk_firmware folder                                              [OK]
Checking file size of planck_rev5_default.hex                                                      
 * The firmware is too large! 30216/28672 (1544 bytes over)

Copying planck_rev4_default.hex to qmk_firmware folder                                              [OK]
Checking file size of planck_rev4_default.hex                                                      
 * The firmware is too large! 30212/28672 (1540 bytes over)



md5-7f6dfb4a6b4408aadce1d8ef8f82d34f



Checking file size of planck_rev5_default.hex                                                      
 * The firmware is too large! 29634/28672 (962 bytes over)



md5-d134cac6c271a8c15d8c32718d84bd2e



Compiling: tmk_core/common/chibios/bootloader.c                                                    In file included from ./lib/chibios/os/common/ext/CMSIS/ST/STM32F3xx/stm32f303xc.h:168,
                 from ./lib/chibios/os/common/ext/CMSIS/ST/STM32F3xx/stm32f3xx.h:153,
                 from ./lib/chibios/os/common/startup/ARMCMx/devices/STM32F3xx/cmparams.h:72,
                 from ./lib/chibios/os/common/ports/ARMCMx/chcore.h:70,
                 from ./lib/chibios/os/rt/include/ch.h:81,
                 from tmk_core/common/chibios/bootloader.c:3:
./lib/chibios/os/common/ext/CMSIS/include/cmsis_gcc.h: In function 'enter_bootloader_mode_if_requested':
./lib/chibios/os/common/ext/CMSIS/include/core_cm4.h:93:28: error: listing the stack pointer register 'sp' in a clobber list is deprecated [-Werror=deprecated]
   93 |   #define __ASM            __asm                                      /*!< asm keyword for GNU Compiler */
      |                            ^~~~~
./lib/chibios/os/common/ext/CMSIS/include/cmsis_gcc.h:190:3: note: in expansion of macro '__ASM'
  190 |   __ASM volatile ("MSR msp, %0\n" : : "r" (topOfMainStack) : "sp");
      |   ^~~~~
./lib/chibios/os/common/ext/CMSIS/include/core_cm4.h:93:28: note: the value of the stack pointer after an 'asm' statement must be the same as it was before the statement
   93 |   #define __ASM            __asm                                      /*!< asm keyword for GNU Compiler */
      |                            ^~~~~
./lib/chibios/os/common/ext/CMSIS/include/cmsis_gcc.h:190:3: note: in expansion of macro '__ASM'
  190 |   __ASM volatile ("MSR msp, %0\n" : : "r" (topOfMainStack) : "sp");
      |   ^~~~~
cc1: all warnings being treated as errors

After that i tried to modify tmk_core/arm_atsam.mk to ALLOW_WARNINGS=yes, but i also had to modify rules.mk to add -Wno-deprecated to CFLAGS and CPPFLAGS because -Wall infers -Wdeprecated flag. After these modifications i was able to successfully build and flash working firmware for planck rev6.

I also saw that for some compatibility issues with GCC 9.x utils/linux_install.sh script has been modified for Arch/Manjaro to pin avr-gcc to version 8.3.0.

For now, i'm still holding back upgrade to GCC 9.x on Solus, but if these issues could be fixed in QMK firmware, that would be great. Maybe even avr needs just a little more tweaking of flags and makefiles to turn down compiled firmware size.

Keep in mind that i'm not C/C++ guru, so i'm leaving this for experts.

[chax]

I guess I'm hitting this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91189

[yanfali]

@chax you have our sympathies. We've had a lot of issues with almost every GCC release. The 8 series was not compatible with QMK until 8.3, it kept producing bad code for us. On ARM we recommend 6.3.1 at this time, though I have been reliably informed that 8.3 is also producing good code at this time. For AVR 8.3 is our current recommendation. We do not currently recommend any 9 series GCC releases for use with AVR and have not done any real testing with ARM, but we do know that 9 has had issues in previous releases. Fingers crossed 9.3 will be a good release for us.

[chax]

Like i said, for ARM (planck rev6) i successfully built and flashed qmk (with makefiles modifications to ignore deprecations) and it works on my planck. For AVR i think this bug report that i posted is the same issue i have. GCC 9.2 works with Arduino and i can easily and successfully flash Arduino UNO through Arduino IDE, other than the issue that i get larger firmware binary image.

[yanfali]

@chax appreciate the suggestions, but we have hundreds of keyboards in our repo, so things take time to verify their impact. Also, arduino is a comparatively small flash size target, we tend to create images that get close to the 28k limit on a pro micro, so we would run into this before most IDE users.

[chax]

I know, i just wrote my observations. For now i will keep holding back upgrade of these GCC packages on Solus, after all, there is no real value-add by upgrading them.

[yanfali]

There's a bigger user base of arduino users than QMK I would wager, so you'll have to make that call. When people run into this kind of issue on a rolling linux distro, we strongly recommend the docker container for consistency.

[drashna]

Also, one thing to note here, is that GCC 9.x generates larger images than previous versions. So we may not want to update, even if we do get this working. 8.3 is probably the best version to use, at this time.

[magnusmorton]

It's looking like this may never be fixed and that GCC may drop AVR support. clang might have better results