-
-
Notifications
You must be signed in to change notification settings - Fork 37.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GCC 9.x compatibility #6719
Comments
|
I guess I'm hitting this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91189 |
|
@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. |
|
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. |
|
@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. |
|
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. |
|
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. |
|
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. |
avr-gcc 9.x versions have an unresolved regression which make them unusable for building the QMK keyboard firmware: qmk/qmk_firmware#6719 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 Add a separate 'avr-gcc8' package which can be installed instead of 'avr-gcc'.
|
It's looking like this may never be fixed and that GCC may drop AVR support. clang might have better results |
|
I'm having trouble reproducing this. Built the same keymap on 3 different versions of avr-gcc, see below. 5.4.0
8.3.0
10.2.0
8.3 is an improvement over 5.4 when considering target size, but I don't see the huge regressions people are talking about in 10.2. The |
|
@itspngu 10.2 may be fixed. I was just able to successfully build + flash with gcc 9.3 where I previously had issues with 9.2 |
That sounds great, but uh... as outlined in my post I had trouble reproducing the regressions everyone was talking about. 9.3 being fixed (whatever that means) compared to 9.2 seems like a great thing, so perhaps it'd make sense to make the maintainers aware. I suppose if you could provide some more background info, such as build outputs comparing 9.2 to 9.3 and then tag drashna and yanfali as they'd probably be in the best position to evaluate bumping the GCC version from 8.x to 9.x or 10.x :) |
qmk now flashes just fine with 10.x. Perhaps 9.x was the issue. See also: qmk/qmk_firmware#6719
|
I did some more testing, and unfortunately I don't have any real breakthroughs to share. I am able to build my keymap on gcc 7.3, 9.2, and 9.3 successfully, but when compiling the production target (keymap + DFU bootloader) I get the same issue I had before in #8391 on the 9.x versions. Also able to reproduce firmware size issue with planck rev 5 & 6 with gcc 9.3 |
|
I also experience the issue when compiling the lufa DFU bootloader on GCC 11.2.0 Depending on how much space is missing on other bootloaders it may make sense to use this for a general solution. |
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:
I manage to bring this down a little by modifying makefile
tmk_core/avr.mkand adding flags-flto -Osbut it's still too large.For arm board i have both planck rev6 and preonic rev3 so i tested by building default keymap. I stumbled upon some deprecation warnings which were treated like errors.
After that i tried to modify
tmk_core/arm_atsam.mkto ALLOW_WARNINGS=yes, but i also had to modifyrules.mkto add-Wno-deprecatedto CFLAGS and CPPFLAGS because-Wallinfers-Wdeprecatedflag. 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.shscript 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.
The text was updated successfully, but these errors were encountered: