RE: [PATCH] stack: fix pile GCC memcpy warnings

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> 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 <alialnu@nvidia.com>
> > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > ---
> >  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