Skip to content

Masked the SMP remap core maps to silence a false -O2 array bounds error - #728

Merged
fdesbiens merged 1 commit into
eclipse-threadx:devfrom
fdesbiens:fix/issue-469
Sep 15, 2026
Merged

fdesbiens merged 1 commit into
eclipse-threadx:devfrom
fdesbiens:fix/issue-469

Conversation

@fdesbiens

@fdesbiens fdesbiens commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

Fixes #469

_tx_thread_smp_remap_solution_find indexes _tx_thread_smp_schedule_list with
the lowest set bit of the core maps it is given. Every caller already masks
those maps with TX_THREAD_SMP_CORE_MASK, but the compiler cannot see it, so
when the function is inlined into _tx_thread_system_suspend at -O2 GCC
assumes a bit number as high as 31 and reports an out-of-bounds subscript.
-Werror turns that into a build failure.

Masked the three incoming maps at the top of the function, in both the inline
version in common_smp/inc/tx_thread.h and the twin in
tx_thread_smp_utilities.c. The masks are semantic no-ops, so scheduling is
unchanged, but the range is now visible to the optimizer. The first core queue
entry is also initialized, because the narrowed range lets GCC consider an empty
queue and warn about that instead.

Reproduced on the Cortex-A9 SMP port with arm-none-eabi-gcc 13.2.1, and clean
afterwards across -O2, -O3 and -Os and 2, 4 and 8 core configurations. SMP suite
116/116.

…TX_THREAD_SMP_CORE_MASK, so the computed core index is provably within the schedule list and GCC no longer reports a false array bounds error at -O2

The remap solution search derives a core number from the lowest set bit of
the supplied core maps and uses it to index _tx_thread_smp_schedule_list and
the local remap list, both of which have TX_THREAD_SMP_MAX_CORES entries.
Every map reaching the function is already restricted to the cores that are
present, because tx_thread_smp_cores_allowed is masked with
TX_THREAD_SMP_CORE_MASK in tx_thread_create and tx_thread_smp_core_exclude.
The compiler cannot see that invariant, however, so when the function is
inlined into _tx_thread_system_suspend at -O2 GCC assumes the bit number can
be as high as 31 and reports an out of bounds array subscript, which fails
the build under -Werror.

Masking the three incoming maps with TX_THREAD_SMP_CORE_MASK makes the
invariant explicit. The masks are semantic no-ops, so scheduling behaviour is
unchanged. The first core queue entry is now initialized as well, since the
narrowed value range lets the compiler consider an empty queue on entry.

Fixes eclipse-threadx#469

Assisted-by: Copilot (Opus 5) <noreply@github.com>
@fdesbiens fdesbiens changed the title Masked the core maps passed to the SMP remap solution search against TX_THREAD_SMP_CORE_MASK, so the computed core index is provably within the schedule list and GCC no longer reports a false array bounds error at -O2 Masked the SMP remap core maps to silence a false -O2 array bounds error Sep 15, 2026
@fdesbiens
fdesbiens merged commit d15f28a into eclipse-threadx:dev Sep 15, 2026
14 checks passed
@fdesbiens
fdesbiens deleted the fix/issue-469 branch September 16, 2026 13:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant