Ship a newer compiler

[pavel-kirienko]

GCC 10 has issues with std::variant support which are addressed in newer compiler versions.

[aentinger]

+1. This core is the only Arduino Core running C++17. Unfortunately the issues with std::variant block an important use case for me -.- Kindly consider packaging a newer version so that up2date language standard comes with an up2date compiler 🙏

[earlephilhower]

GCC 12 already builds using the pico-quick-toolchain scripts, but I'm holding back for a major release (the SDK 1.4->1.5 was a major change and had enough stuff moving to make me not want to throw in a new compiler into the mix).

So, it'll come but not in the short term.

Is there a newer GCC 10.x version out there, or a backported patch, which could be applied? And do you have any links to explain the std::variant issue?

[pavel-kirienko]

The bug is described here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90943

I think the latest GCC 10 is at least v10.3.1 while the platform currently ships v10.3.0.

[earlephilhower]

There's a GCC 10.4.0 out (we build from source, and don't use ARM's versions): https://gcc.gnu.org/gcc-10/

Looking at the bug, there might be a simple patch to backport... (the infra supports patching GCC very simply, assuming the patch (a) applied and (b) works).
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=c46ecb0112e91c80ee111439e79a58a953e4479d

I would not have an issue moving from gcc 10.3 -> 10.4.0 + patch on a regular bump after a few days of testing on my own...

[pavel-kirienko]

I would not have an issue moving from gcc 10.3 -> 10.4.0 + patch on a regular bump after a few days of testing on my own...

Terrific. That's all we need.

[aentinger]

I would not have an issue moving from gcc 10.3 -> 10.4.0 + patch on a regular bump after a few days of testing on my own...

Terrific ;) I'd be most obliged 🙇 .

[earlephilhower]

Well, so much for that idea. The GCC 11 patch to change std::variant can not apply to the 10.4 branch, There was some refactoring and the code changes and logic aren't 1:1. The changes are beyond my ken, so unless someone else can do a backport it'll just have to wait for a major revision. Sorry!

[pavel-kirienko]

@earlephilhower would it still be possible to upgrade to the latest v10 release, variant patch notwithstanding?

[earlephilhower]

It shouldn't be an issue, but I'm not sure I see a reason to go from 10.3 to 10.4. Is there some specific problem? The known bugs (this and the case-of-16 failure) are not patched in 10.4 to the best of my knowledge.

[aentinger]

Ah, too bad. Sounds like I'll have to live without the feature that requires GCC11 for some time. I may stop by from time to time and ask about a compiler upgrade 😊 . Sadly I've got no other Arduino core to go to.

[aentinger]

There's a different thought ... earlier you ( @earlephilhower 😉 ) wrote that

There's a GCC 10.4.0 out (we build from source, and don't use ARM's versions): https://gcc.gnu.org/gcc-10/

Would it be possible to build a GCC11 or 12 for us and just give us the binaries (only Linux required)? There are several (and this one) arduino-pico powered applications and we could use those binaries for testing them as well as reporting back on any compatibility issues that we find.

Perhaps I could interest you for that? 😉 🙇

[earlephilhower]

Yeah, give me a few days and I can put out a 0.0.0 pre-release on the pico-quick-toolchain repo with it. You'll need to manually replace the tarball in your installation, but assuming there are no Pico SDK issues w/GCC 12 it should be simple.

[aentinger]

Great news, thank you 🙇 .

[earlephilhower]

Give https://github.com/earlephilhower/pico-quick-toolchain/releases/tag/0.0.0-gcc12.2 a try, You should be able to delete your current system/arm-none-eabi directory and extract the arm-... tarball/zip appropriate for your OS.

I did not try building or running anything with this, so please do verify the core is still good w/this GCC rev. If not, I'm happy to have PRs which are backwards compatible w/10.x!

[aentinger]

Thank you, I'll let you know about what we find 🙇 CC @generationmake @wuehr1999

[earlephilhower]

Closing this for now. Feel free to add anything you find, or submit PRs if things in the core need changes!

[aentinger]

@generationmake @wuehr1999 : If you run Linux / x86 as your dev platform you'll need i686-linux-gnu.arm-none-eabi-6e3ef1a.230314.tar.gz . Extract the content to /.arduino15/packages/rp2040/tools/pqt-gcc/1.5.0-a-5007782. Alternately use meld for more granular control:

meld ~/.arduino15/packages/rp2040/tools/pqt-gcc/1.5.0-a-5007782 ~/Downloads/i686-linux-gnu.arm-none-eabi-6e3ef1a.230314/arm-none-eabi/

[earlephilhower]

Are you really still using a 32b compiler toolchain? The generated ARM code is the same, 32b compiler or x86_64 compiler, but GCC's probably faster (at the cost of some Linux runtime memory) in 64b mode. If not, the x86_64 file is what you probably want to use...

[aentinger]

Thank you for pointing this out, I've overlooked the x68_64 toolchain.

So far I've found no regressions vs GCC 10, everything works like a charm (incl. our advanced usage of std::variant).

[bjonnh]

I've used it with success as well and was able to use c++ modules ( -std=c++20 -fmodules-ts).
With the arduino core I had to add: -D_GNU_SOURCE to avoid errors in WCharacter.h
(note that this is fixed in https://github.com/arduino/ArduinoCore-API 1.4.0)

Other than that it works really well.

[aentinger]

I've also wanted to come back and say that we didn't experience any regressions in any of our projects which all exercise wide areas of the API (pinMode, digitalWrite, digitalRead, attachInterrupt, SPI, Wire, Serial).

[earlephilhower]

Thanks for the reports, @aentinger and @bjonnh !