Update Zephyr SDK to be based upon GCC 14

[tejlmand]

trafficstars

New extensions related to riscv has been added in gcc 14.

Zephyr SDK should be updated to support use of new features which has been introduced in later gcc versions.

@abrodkin feel free to provide additional details.

[keith-packard]

there's a bug with arm v8.1m PACBTI support in gcc14, and as gcc14 includes that as a default multi-lib target, it would be good to include the fix from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113780

[stephanosio]

To be addressed after GCC 14.1 is released (expected around April 2024).

Unless there is an immediate need for the upgrade, it would be good to wait until 14.2 for further stabilisation (likely going to be August 2024).

[piotrrak]

I am working on adding cortex-m85 support to zephyr. It'd greatly aid me in that efforts. Current zephyr-sdk gcc doesn't support cortex-m85. Right now I am using 12.2 with arm backported support and 13.2 gnuarmemb toolchain. Also adding llvm-embedded-toolchain-for-arm adding targetting comming soon 18.0. Adding GCC 14.1 would put it on par with those and allow me to to not special case zephyr-sdk.

[keith-packard]

I am working on adding cortex-m85 support to zephyr. Adding GCC 14.1 would put it on par with those and allow me to to not special case zephyr-sdk.

To @stephanosio 's point, the m85 includes PACBTI support which just had some code generation bugs fixed. 14.1 should include those and current trunk is looking good in my v8.1m testing.

[piotrrak]

@keith-packard @stephanosio Please do count me in if'll need help testing of armv8.1m.

Doesn't mean it to sound as rant, I just noted would be helpful to avoid lying to gcc zephyr-sdk that -mcpu is cortex-m55, rather than cortex-m85 eventually. And that really depends what you mean by looking good. I've spend last year optimising/writing MVE code at day job and for me it is playing hit-and-miss with compilers - every compiler in each version has own little quirks - nothing big just 7% perf here, 20% perf there :)

https://godbolt.org/z/WdEeEs9hn - is my recent favourite - clang does indexing backwards when going from SSA and messes up ISEL totally. Doesn't pick proper post-inc adressing mode and insist on adding useless scalar instructions in hot loop.

.LBB0_1:                                @ =>This Inner Loop Header: Depth=1
        vld20.16        {q0, q1}, [r1]
        mov     r5, r1
        adds    r1, #64
        vld21.16        {q0, q1}, [r5]!

That could have been simply [r1]! for all vld2 all the way. Get's even worse with agressive unwind. Ditto for stores :)

Still have not finished opt pass for cleaning up those. I switched meanwhile to zephyr for night hacking, since got nice m85 toy boards, but I will have time for that in 2H of this year I hope.

It's getting better with recent version, but I will be trying to get as many toolchains/versions working for armv8.1m, so one can simply compile measure pick the best.

Cheers, /P

[stephanosio]

There has been enough demand for a newer GCC version to justify the upgrade -- to list a few:

• Support for new ARM extensions such as PACBTI and SME
• Support for new RISC-V extensions such as vector crypto extension (Zv*) and code size reduction extension (Zc*)
• Support for newer processor types (e.g. cortex-m85)

Once GCC 14.1 is out (expected around 7 May 2024), I will open a development branch for the 24H1 toolchain updates. This should include Binutils 2.42, GCC 14.1 and QEMU 9.0.

[janhenke]

GCC 14.1 has been release, but I do not see the 24H1 branch yet?

Adding to this: GCC add more of the standard library in freestanding mode (from C++23 and C++26 changes). These greatly improve what is possible with the C++ STL in embedded code (e.g. std::expected).

[janhenke]

GCC 14.2 has been release on 2024-08-01, any update on getting GCC 14 into the SDK?