Future of AVR with GCC v10 and later

[mfp20]

TLTR: Are you going to keep an edgy profile and bump gcc minimum version again or ... ?

A few months ago I was playing with modm, then I got frustrated by scons, the lack of distributions support to gcc9, and an overall idea of modm being a bit too experimental for my taste. Then promised myself to go back to modm after a few months.

Gentoo right now got pretty awesome: dropped a few old projects, raised ebuilds quality and ... defaulted to gcc9. So I came back here and I've found modm depending on gcc10: I HATE YOU! (smile, please)
Luckily enough gentoo's crossdev is pretty smart, so I could easily build a gcc10-based avr toolchain.
In the while, I've been working on QEMU's AVR support and after bugging his creator, he managed to have AVR support mainlined in QEMU. And using QEMU (and its integrated gdb support) gets pretty good together with modm.
So I'd like to make a new attempt to base my firmware on top of modm but considering gcc10 as the last version to support AVR... I'm pretty scared by the idea you are going to bump gcc version again.
I've no idea what new C++ features are in newer standards and no idea what kind of feature you might need for modm; but I need a stable project to base my code on; can't be something constantly kept on the edge of innovation...

[salkinium]

modm has previously had a minimum GCC requirement of v7 for C++17. However, we usually upgrade our CI and install instructions to the latest GCC as soon as it is available to get access to new warnings and optimizations. We've wanted to upgrade to C++20 for a long, long time due to all the new features, so the new requirement is GCC 10. Looking at the GCC C++ language page, we will probably have to make GCC 11 the minimum (next year) to get full C++20 support.

So: Minimum is GCC10 and then GCC11 in 2022 earliest. Then it'll be stable until C++23 comes around in 2025 maybe?

I understand it's annoying to chase dependencies and keep everything up-to-date, however, modm is still our (unpaid) hobby and thus we do with it what we enjoy, otherwise we'll lose interest and stop maintaining it. It was already very much work getting it to the point where it is now, so we simply don't have the time or motivation to do "stable" releases, so modm will always keep an edgy profile.

[salkinium]

We also host a stand-alone AVR-GCC v10.2.0 here: https://github.com/modm-io/avr-gcc
This will always be up-to-date since we cannot upgrade modm without our CI.

[mfp20]

modm has previously had a minimum GCC requirement of v7 for C++17. However, we usually upgrade our CI and install instructions to the latest GCC as soon as it is available to get access to new warnings and optimizations. We've wanted to upgrade to C++20 for a long, long time due to all the new features, so the new requirement is GCC 10. Looking at the GCC C++ language page, we will probably have to make GCC 11 the minimum (next year) to get full C++20 support.

So: Minimum is GCC10 and then GCC11 in 2022 earliest. Then it'll be stable until C++23 comes around in 2025 maybe?

I understand it's annoying to chase dependencies and keep everything up-to-date, however, modm is still our (unpaid) hobby and thus we do with it what we enjoy, otherwise we'll lose interest and stop maintaining it. It was already very much work getting it to the point where it is now, so we simply don't have the time or motivation to do "stable" releases, so modm will always keep an edgy profile.

Of course! At the time of my writing my heart was very far from the idea to dictate anything. And thanks for the fast and comprehensive answer to my question.

But what you just wrote imply that you are going to drop AVR in 2022, as GCC11 will disable AVR support unless someone (ex: Microchip) will re-write the AVR code to cope with new gcc's code architecture. Is it right?

[salkinium]

Yeah, I read about that too, but we're not going to throw away AVR support just like that, since we invested so much work over the years. We'll probably switch to LLVM for AVR and probably also ARM, since active Cortex-M development has switched to LLVM too some years ago. In general, the issue is that the official avr-gcc from Atmel is stuck at v5.4.0, so we have use either GCC or LLVM upstream support anyways, so the work is pretty much the same for us.

[mfp20]

Yeah, I read about that too, but we're not going to throw away AVR support just like that, since we invested so much work over the years. We'll probably switch to LLVM for AVR and probably also ARM, since active Cortex-M development has switched to LLVM too some years ago. In general, the issue is that the official avr-gcc from Atmel is stuck at v5.4.0, so we have use either GCC or LLVM upstream support anyways, so the work is pretty much the same for us.

LLVM? Is it possible to use LLVM for modm now?

[salkinium]

Not yet, we would have to adapt our :build script generator module to call LLVM and translate our GCC flags to it.

However, the difficult part will be translating/"macro-ing" our GCC specific code and also dealing with the LLD linker, which does not support all the things we're currently doing with GNU LD (or we continue using GNU LD). It's probably not that difficult, but verifying that we didn't mess up is important (there'll probably be a time when we can generate the library for both GCC and LLVM for testing).

[mfp20]

Ok, so basically policies are "we stay on the edge for fun" and "we don't want to trash all the work done on AVR", but there's no continuity solution at the moment.

Thanks again for your support and all the best for future work!