Update Zephyr SDK to be based upon GCC 14

[tejlmand]

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?

[jadejr]

It appears to be deferred until 0.18 in favor of the clang additions. Seems like it should be in the opposite order.

[JPHutchins]

Personally I am excited for C23 in Zephyr, should bring some nice improvements!

[dantti]

Is there some way to get gcc 14 or 15 as experimental feature? I wrote a code with coroutines and it built/run fine using IDF (esp32) gcc 14, so I'm wondering if I can just copy their cross-compiler as I liked Zephyr API's nicer and decided to use it instead....

[carlescufi]

Today GCC released 15.1, we may as well skip 14.x and go straight to 15.1.

[ajf58]

Today GCC released 15.1, we may as well skip 14.x and go straight to 15.1.

Is that's the decision then let's get the issue's title updated to reflect that.

@carlescufi two questions come to mind:

1. What's the fastest way to get an updated GCC toolchain?
2. What's the 'best'? Personally I err on cautious, preferring to make a number of incremental updates (so I'd update the toolchain to the latest 14.x use that with one Zephyr release, then update again), but that might not match other people's preferences (this might feel like duplicating effort).

Is now the right time to ask for the TSC to discuss and make a decision here?

[nashif]

Today GCC released 15.1, we may as well skip 14.x and go straight to 15.1.

i would rather do this incrementally and move to 14.2 first. There is lots of cleanup needed and some targets we have are not upstream in 15.1. Also, crosstool-ng does not support 15.1 yet (https://crosstool-ng.github.io/).

Spent some time on this the last few days and have first signs of life. Will start pushing progress to dev branches shortly to get this moving fast.

(.venv) i9:zephyr(main): west build  -p -b qemu_x86_64 samples/hello_world/ -- -DSYSROOT_DIR=/home/nashif/zephyrproject/build-workspace/output/x86_64-zephyr-elf/picolibc -DCONFIG_MINIMAL_LIBC=y
-- west build: making build dir /home/nashif/zephyrproject/zephyr/build pristine
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: /home/nashif/zephyrproject/zephyr/samples/hello_world
-- CMake version: 3.31.4
-- Found Python3: /home/nashif/zephyrproject/.venv/bin/python3 (found suitable version "3.12.3", minimum required is "3.10") found components: Interpreter
-- Cache files will be written to: /home/nashif/.cache/zephyr
-- Zephyr version: 4.1.99 (/home/nashif/zephyrproject/zephyr)
-- Found west (found suitable version "1.3.0", minimum required is "0.14.0")
-- Board: qemu_x86_64, qualifiers: atom
-- Found toolchain: cross-compile (/home/nashif/zephyrproject/build-workspace/output/x86_64-zephyr-elf/bin/x86_64-zephyr-elf-)
-- Found Dtc: /usr/bin/dtc (found suitable version "1.7.0", minimum required is "1.4.6")
-- Found BOARD.dts: /home/nashif/zephyrproject/zephyr/boards/qemu/x86/qemu_x86_64.dts
-- Generated zephyr.dts: /home/nashif/zephyrproject/zephyr/build/zephyr/zephyr.dts
-- Generated pickled edt: /home/nashif/zephyrproject/zephyr/build/zephyr/edt.pickle
-- Generated devicetree_generated.h: /home/nashif/zephyrproject/zephyr/build/zephyr/include/generated/zephyr/devicetree_generated.h
-- Including generated dts.cmake file: /home/nashif/zephyrproject/zephyr/build/zephyr/dts.cmake
Parsing /home/nashif/zephyrproject/zephyr/Kconfig
Loaded configuration '/home/nashif/zephyrproject/zephyr/boards/qemu/x86/qemu_x86_64_defconfig'
Merged configuration '/home/nashif/zephyrproject/zephyr/samples/hello_world/prj.conf'
Merged configuration '/home/nashif/zephyrproject/zephyr/build/zephyr/misc/generated/extra_kconfig_options.conf'
Configuration saved to '/home/nashif/zephyrproject/zephyr/build/zephyr/.config'
Kconfig header saved to '/home/nashif/zephyrproject/zephyr/build/zephyr/include/generated/zephyr/autoconf.h'
-- Found GnuLd: /home/nashif/zephyrproject/build-workspace/output/x86_64-zephyr-elf/x86_64-zephyr-elf/bin/ld.bfd (found version "2.43.1")
-- The C compiler identification is GNU 14.2.0
-- The CXX compiler identification is GNU 14.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /home/nashif/zephyrproject/build-workspace/output/x86_64-zephyr-elf/bin/x86_64-zephyr-elf-gcc
CMake Warning at /home/nashif/zephyrproject/zephyr/subsys/random/CMakeLists.txt:12 (message):


      Warning: CONFIG_TIMER_RANDOM_GENERATOR and CONFIG_TEST_CSPRNG_GENERATOR are
      not truly random generators. This capability is not secure and it is
      provided for testing purposes only. Use it carefully.


-- Using ccache: /usr/bin/ccache
-- Configuring done (5.1s)
-- Generating done (0.1s)
-- Build files have been written to: /home/nashif/zephyrproject/zephyr/build
-- west build: building application
[1/127] Preparing syscall dependency handling

[3/127] Generating include/generated/zephyr/version.h
-- Zephyr version: 4.1.99 (/home/nashif/zephyrproject/zephyr), build: v4.1.0-3062-g29197ac9633c
[122/127] Linking C executable zephyr/zephyr_pre0.elf
/home/nashif/zephyrproject/build-workspace/output/x86_64-zephyr-elf/lib/gcc/x86_64-zephyr-elf/14.2.0/../../../../x86_64-zephyr-elf/bin/ld.bfd: warning: zephyr/zephyr_pre0.elf has a LOAD segment with RWX permissions
[127/127] Linking C executable zephyr/zephyr.elf
/home/nashif/zephyrproject/build-workspace/output/x86_64-zephyr-elf/lib/gcc/x86_64-zephyr-elf/14.2.0/../../../../x86_64-zephyr-elf/bin/ld.bfd: warning: zephyr/zephyr.elf has a LOAD segment with RWX permissions
Memory region         Used Size  Region Size  %age Used
             RAM:        188 KB        31 MB      0.59%
          LOCORE:         16 KB        60 KB     26.67%
Generating files from /home/nashif/zephyrproject/zephyr/build/zephyr/zephyr.elf for board: qemu_x86_64

[jadejr]

@nashif : If that was planning to come out anytime soon then sure. It's just that gcc 14 was scheduled to come out in 0.19, and 0.18 still isn't even out yet. Seems like about that'd mean no upgraded gcc until maybe july or august.

[nashif]

FYI, I started pushing branches with initial support, mostly with minimal zephyr related patches and changes:

https://github.com/zephyrproject-rtos/binutils-gdb/tree/zephyr-gdb-16.2
https://github.com/zephyrproject-rtos/binutils-gdb/tree/zephyr-binutils-2_43_1
https://github.com/zephyrproject-rtos/crosstool-ng/tree/zephyr-crosstool-ng-1.27.0
https://github.com/zephyrproject-rtos/gcc/tree/zephyr-gcc-14.2.0
https://github.com/zephyrproject-rtos/newlib-cygwin/tree/zephyr-newlib-4.5.0

[nashif]

@nashif : If that was planning to come out anytime soon then sure. It's just that gcc 14 was scheduled to come out in 0.19, and 0.18 still isn't even out yet. Seems like about that'd mean no upgraded gcc until maybe july or august.

we can always repurpose/skip unreleased version numbers I guess or follow some other new scheme. So we could skip 0.18 if we have something ready with a newer gcc and have llvm go into 0.20...

[ajf58]

@nashif would it be worthwhile reassigning this issue to you? @stephanosio is the assignee but hasn't comment on the issue for over a year.

[keith-packard]

We'll need some of the patches from add_support_rx_gcc_build_zephyr branch, including the two patches that adjust the linker spec fragments for rx and microblazeel targets as those are necessary to build picolibc. The two RX patches to fix
rx_cmpstrn is also necessary as those fix a crashing bug in string functions.

[harristomy]

Crosstool-ng just added GCC 15.1 support crosstool-ng/crosstool-ng@a0a10f5

[nashif]

Crosstool-ng just added GCC 15.1 support crosstool-ng/crosstool-ng@a0a10f5

we will start looking at 15.1 once we have 14.2 completed. There are way too many variables and issues we have to deal with first, jumping 3 major versions in one go is not going to help :)

[harristomy]

Fair enough :)

[keith-packard]

Making slow progress in getting full twister run passing. Posted a couple of PRs:

• modules/cmsis-dsp: Don't use Zephyr stdint.h zephyr#90173
• arch/x86: Support picolibc with zefi zephyr#90187
• Use picolibc instead of newlib-nano trusted-firmware-m#134

[harristomy]

@nashif somewhat relevant to this issue, the Github Org's README.rst still reads

The Zephyr kernel supports multiple architectures, including ARM Cortex-M, Intel x86, ARC, Nios II, Tensilica Xtensa, and RISC-V, and a large number of supported boards.

Nios II support will be removed soon right?

[nashif]

Nios II support will be removed soon right?

it is removed