-
Notifications
You must be signed in to change notification settings - Fork 158
Update Zephyr SDK to be based upon GCC 14 #740
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
Comments
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 |
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). |
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. |
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. |
@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. https://godbolt.org/z/WdEeEs9hn - is my recent favourite - clang does indexing backwards when going from SSA and messes up ISEL totally.
That could have been simply 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, |
There has been enough demand for a newer GCC version to justify the upgrade -- to list a few:
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. |
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. |
GCC 14.2 has been release on 2024-08-01, any update on getting GCC 14 into the SDK? |
It appears to be deferred until 0.18 in favor of the clang additions. Seems like it should be in the opposite order. |
Personally I am excited for C23 in Zephyr, should bring some nice improvements! |
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.... |
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:
Is now the right time to ask for the TSC to discuss and make a decision here? |
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.
|
@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. |
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 |
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... |
@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. |
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 |
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 :) |
Fair enough :) |
Making slow progress in getting full twister run passing. Posted a couple of PRs: |
@nashif somewhat relevant to this issue, the Github Org's README.rst still reads
Nios II support will be removed soon right? |
it is removed |
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.
The text was updated successfully, but these errors were encountered: