> From: Bruce Richardson [mailto:[email protected]]
> Sent: Tuesday, 20 October 2026 11.19
>
> On Tue, Oct 20, 2026 at 08:49:44AM +0000, Morten Brørup wrote:
> > On architectures where rte_memcpy() is defined as memcpy(),
> > GCC warns about source/destination overflow when copying more than
> the
> > source/destination size, even for code paths that are not taken in
> cases
> > where the sizes are smaller.
> >
> > The relevant compiler warnings were disabled for GCC at the two
> > occurrences, and comments describing the reason were added.
> >
> > NB:
> > It has not been investigated which GCC versions are affected.
> > GCC version 10 and up was chosen because that was what the previous
> > versions of x86 rte_memcpy() disabled sligthly similar warnings for.
> >
> > PS:
> > The alternative was to obfuscate the code, but that would make the
> code
> > less readable, and might have unintended effects on architectures and
> > compilers not suffering by this issue.
> >
> > Bugzilla ID: 2061
> > Fixes: ee0822a0ef41 ("stack: introduce pile")
> >
> > The pile was introduce with this DPDK release, so no need to
> backport.
> >
> > Reported-by: Ali Alnubani <[email protected]>
> > Signed-off-by: Morten Brørup <[email protected]>
> > ---
> > lib/stack/rte_stack_pile.h | 26 ++++++++++++++++++++++++++
> > 1 file changed, 26 insertions(+)
> >
> > diff --git a/lib/stack/rte_stack_pile.h b/lib/stack/rte_stack_pile.h
> > index 819bd1d47a..69aa0cbf88 100644
> > --- a/lib/stack/rte_stack_pile.h
> > +++ b/lib/stack/rte_stack_pile.h
> > @@ -154,12 +154,25 @@ __rte_stack_pile_push(struct rte_stack *s,
> > * Construct the bulk elements.
> > * Copy bulks in reverse order, but ignore the object order
> within each bulk.
> > */
> > +#if defined(RTE_TOOLCHAIN_GCC) && (GCC_VERSION >= 100000)
> > +/*
> > + * On architectures where rte_memcpy() is defined as memcpy(),
> > + * although GCC knows that this code path is not taken when the
> source's size is smaller than
> > + * RTE_STACK_PILE_BULK_SIZE, it still warns about memcpy() source
> overread.
> > + * So we disable the compiler warning for this memcpy() instance.
> > + */
> > +#pragma GCC diagnostic push
> > +#pragma GCC diagnostic ignored "-Wstringop-overread"
> > +#endif
> > tmp = (struct rte_stack_lf_elem *)bulk_first;
> > __rte_assume(n_bulk > 0);
I also tried removing this __rte_assume(). No effect.
> > for (i = 0; i < n_bulk; i++, tmp = tmp->next)
> > rte_memcpy(((struct rte_stack_pile_bulk_elem *)tmp)->objs,
> > &obj_table[(n_bulk - i - 1) *
> RTE_STACK_PILE_BULK_SIZE],
> > sizeof(void *) * RTE_STACK_PILE_BULK_SIZE);
>
> An rte_assume before the memcpy asserting the sizes doesn't help?
GCC complains about the size of the obj_table.
memcpy() overruns it when n==1, and thus the compiler knows that the size of
obj_table is only one object.
Which is true, because this instance of memcpy() copies 32
(RTE_STACK_PILE_BULK_SIZE) objects.
But GCC ignores the fact that this code path is not taken when n==1, and warns
anyway.
GCC completely ignores that the code path is not taken.
Referring to description in Bugzilla, it warns when called with pushing/popping
1 object.
For verifying that the compiler knows that the problematic code is part of the
code path when handling 1 object, and ignores this fact anyway, I even tried
something like:
if (n >= RTE_STACK_PILE_BULK_SIZE) {
bulk copy loop;
}
And it still warns.
>
> > +#if defined(RTE_TOOLCHAIN_GCC) && (GCC_VERSION >= 100000)
> > +#pragma GCC diagnostic pop
> > +#endif
