SDK 1.0 compatibility fixes #94360
Merged
SDK 1.0 compatibility fixes #94360
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Disable the default startup file with -nostartfiles. Signed-off-by: Keith Packard <[email protected]>
When the target has only a single CPU, this function cannot ever succeed. Skip all of the drama and just return -EINVAL. This makes GCC 14 happy as it doesn't get confused about possible out of bounds access of the soc_cpus_active array. Signed-off-by: Keith Packard <[email protected]>
The stm32u3x header files defines LL_ADC_SINGLE_ENDED but not LL_ADC_DIFFERENTIAL as the device doesn't support differential mode. The driver only checked for LL_ADC_SINGLE_ENDED and assumed that when that was defined, LL_ADC_DIFFERENTIAL would also be defined. Check for both when figuring out which calibration type will be required. Signed-off-by: Keith Packard <[email protected]>
Zephyr replaces the toolchain version of stdint.h to define uint32_t and int32_t as int rather than long. This breaks the ARM MVE intrinics which require uint32_t to be defined as unsigned long. Define 'ZEPHYR_USE_TOOLCHAIN_STDINT_H_' as that causes zephyr_stdint.h to be skipped, ensuring that the normal stdint.h types are used instead. Signed-off-by: Keith Packard <[email protected]>
zephyrbot
added
platform: Intel ADSP
zephyrbot
requested review from
FRASTM,
GeorgeCGV,
TaiJuWu,
andyross,
ceolin,
cfriedt,
dcpleung,
edersondisouza,
erwango,
gautierg-st,
laurenmurphyx64,
marwaiehm-st,
nashif,
npitre and
peter-mitsis
peter-mitsis
previously approved these changes
Aug 11, 2025
Contributor
peter-mitsis
left a comment
peter-mitsis
left a comment
There was a problem hiding this comment.
Looks good -- just one minor nitpick.
28 tasks
keith-packard
force-pushed
the
keithp-sdk-1.0-dev
branch
3 times, most recently
from
02a374b to
cff7080
Compare
dcpleung
previously approved these changes
Aug 11, 2025
GCC 14.3 will happily delete any code that appears before __builtin_unreachable that isn't separated with an obvious branch. That includes __asm__ statements, even those which generate traps. The failure case that I debugged was on x86 in z_check_stack_sentinel. There is a store to restore the sentinel to the correct value just before the ARCH_EXCEPT, and that macro emits 'int $32' followed by CODE_UNREACHABLE. Because the compiler didn't understand that ARCH_EXCEPT was changing execution flow, it decided that the sentinel restoring store 'couldn't' be reached and elided it. I added the "memory" clobber to the asm statement in ARCH_EXCEPT before CODE_UNREACHABLE to enforce that all pending store operations be performed before the asm statement occurs. This ensures that they are not deleted by the compiler. I think this might be a GCC bug. The GCC documentation explicitly documents that asm statements which change the flow of control should be followed by __builtin_unreachable. Signed-off-by: Keith Packard <[email protected]>
On arm64, GCC feels free to use floating point registers for essentially anything unless we build with -mgeneral-regs-only. After the FPU gets used in an interrupt handler, interrupts are disabled as there's no place to save the registers during a nested exception. As the C library may be built separately without this flag, we cannot use any of its functions or risk having nested exceptions fail. Switch printk usage to k_str_out and stick to (mostly) Zephyr internal functions to ensure nested interrupts work correctly. Signed-off-by: Keith Packard <[email protected]>
GCC 14 takes a look these functions which are just 'return true' and inlines them even though they has the noinline attribute set. This happens because the compiler computes the possible range of values from the function call, and as that is a single value (true), it replaces the call with that value. So it's not strictly inlining the function? Insist a bit harder by adding a compiler_barrier to the functions which seems to solve the issue. Signed-off-by: Keith Packard <[email protected]>
…stems RX consistently fails this test by a tiny amount. Loosen the tolerance to let it work. Signed-off-by: Keith Packard <[email protected]>
keith-packard
force-pushed
the
keithp-sdk-1.0-dev
branch
from
cff7080 to
c590e76
Compare
Contributor
Author
|
argh. my blanket addition of a compiler barrier before CODE_UNREACHABLE broke tests. I've fallen back to adding "memory" clobbers to a bunch of asm statements which change code flow. |
peter-mitsis
previously approved these changes
Aug 12, 2025
cfriedt
previously approved these changes
Aug 13, 2025
This test is failing; perhaps we've shrunk the kernel enough to change what this value needs to be? Signed-off-by: Keith Packard <[email protected]>
keith-packard
dismissed stale reviews from cfriedt and peter-mitsis
via
20cc118
|
Contributor
Author
|
Had to adjust the amount of backing store for the demand paging tests. |
peter-mitsis
approved these changes
Aug 15, 2025
erwango
approved these changes
Aug 18, 2025
This was referenced Aug 19, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These patches improve compiler compatibility with the upcoming SDK 1.0 which includes GCC 14.3. They are ready for review and merging.