[PATCH] stack: fix pile GCC memcpy warnings

[PATCH] stack: fix pile GCC memcpy warnings

[Morten Brørup]

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);
 	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);
+#if defined(RTE_TOOLCHAIN_GCC) && (GCC_VERSION >= 100000)
+#pragma GCC diagnostic pop
+#endif
 
 	/* Push them to the bulk list. */
 	__rte_stack_pile_bulk_push_elems(&pile->bulk, bulk_first, bulk_last, n_bulk);
@@ -271,7 +284,20 @@ __rte_stack_pile_pop(struct rte_stack *s,
 
 bulk:
 	/* Fetch n_bulk * RTE_STACK_PILE_BULK_SIZE objects as bulk elements. */
+#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 destination's size is smaller than
+ * RTE_STACK_PILE_BULK_SIZE, it still warns about memcpy() destination overflow.
+ * So we disable the compiler warning for this memcpy() instance.
+ */
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wstringop-overflow"
+#endif
 	bulk_first = __rte_stack_pile_bulk_pop_elems(&pile->bulk, n_bulk, obj_table, &bulk_last);
+#if defined(RTE_TOOLCHAIN_GCC) && (GCC_VERSION >= 100000)
+#pragma GCC diagnostic pop
+#endif
 	if (unlikely(bulk_first == NULL)) {
 		/*
 		 * Not available.
-- 
2.43.0

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

[Bruce Richardson]

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);
>  	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?

> +#if defined(RTE_TOOLCHAIN_GCC) && (GCC_VERSION >= 100000)
> +#pragma GCC diagnostic pop
> +#endif

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

[Morten Brørup]

> 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

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

[Ali Alnubani]

On 10/20/26 11:49 AM, 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>
> ---

Build passes with this patch.

Tested-by: Ali Alnubani <alialnu@nvidia.com>

Thanks,
Ali

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

[Stephen Hemminger]

On Tue, 20 Oct 2026 08:49:44 +0000
Morten Brørup <mb@smartsharesystems.com> 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>
> ---

I don't like using compiler pragmas for this. It also means that if
compiler gets fixed or behaves differently you will never see it.


AI analysis shows some other options.

Root cause is --buildtype=debug, i.e. -O0, not the GCC version. At -O0 nothing removes the dead n_bulk > 0 path for rte_stack_push(s, &obj, 1), so the constant 256-byte memcpy is checked against obj (8 bytes) and warns. Reproduced with GCC 13.3 and 14.2 at -O0; silent at -Og and above. That means the GCC_VERSION >= 100000 gate is wrong at both ends: any GCC with the warning fires (overflow since 8, overread since 11), and on GCC 10 the -Wstringop-overread pragma itself is a -Wpragmas error under -Werror. If the pragma stays, drop the version gate (keep RTE_TOOLCHAIN_GCC) and fix the comment: GCC does not “know” the path is dead, that is the whole problem.


This should have a big ass comment, and it should use same pragma set as existing one in lib/ring.

Other alternative is to use bulk object array as structure and do assignment.
But that replaces ugly pragmas with ugly casts...

--- a/lib/stack/rte_stack_pile.h
+++ b/lib/stack/rte_stack_pile.h
@@
+/* Bulk object array as a single object, so a copy is one assignment. */
+struct rte_stack_pile_bulk_objs {
+	void *objs[RTE_STACK_PILE_BULK_SIZE];
+};
+
@@ __rte_stack_pile_bulk_pop_elems
 		for (unsigned int i = 0; i < num; i++, tmp = tmp->next)
-			rte_memcpy(&obj_table[i * RTE_STACK_PILE_BULK_SIZE],
-					((struct rte_stack_pile_bulk_elem *)tmp)->objs,
-					sizeof(void *) * RTE_STACK_PILE_BULK_SIZE);
+			*(struct rte_stack_pile_bulk_objs *)&obj_table[i * RTE_STACK_PILE_BULK_SIZE] =
+				*(struct rte_stack_pile_bulk_objs *)((struct rte_stack_pile_bulk_elem *)tmp)->objs;
@@ __rte_stack_pile_push
 	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);
+		*(struct rte_stack_pile_bulk_objs *)((struct rte_stack_pile_bulk_elem *)tmp)->objs =
+			*(const struct rte_stack_pile_bulk_objs *)&obj_table[(n_bulk - i - 1) * RTE_STACK_PILE_BULK_SIZE];

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

[Morten Brørup]

> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Tuesday, 20 October 2026 16.24
> 
> On Tue, 20 Oct 2026 08:49:44 +0000
> Morten Brørup <mb@smartsharesystems.com> 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>
> > ---
> 
> I don't like using compiler pragmas for this. It also means that if
> compiler gets fixed or behaves differently you will never see it.
> 
> 
> AI analysis shows some other options.
> 
> Root cause is --buildtype=debug, i.e. -O0, not the GCC version. At -O0
> nothing removes the dead n_bulk > 0 path for rte_stack_push(s, &obj,
> 1), so the constant 256-byte memcpy is checked against obj (8 bytes)
> and warns. Reproduced with GCC 13.3 and 14.2 at -O0; silent at -Og and
> above. That means the GCC_VERSION >= 100000 gate is wrong at both ends:
> any GCC with the warning fires (overflow since 8, overread since 11),
> and on GCC 10 the -Wstringop-overread pragma itself is a -Wpragmas
> error under -Werror. If the pragma stays, drop the version gate (keep
> RTE_TOOLCHAIN_GCC) and fix the comment: GCC does not “know” the path is
> dead, that is the whole problem.

Continuing this line of thinking...
GCC defines an "__OPTIMIZE__" macro if any optimization above level 0 is turned on.
We could gate such pragmas with:
#if defined(RTE_TOOLCHAIN_GCC) && !defined(__OPTIMIZE__)

> 
> 
> This should have a big ass comment, and it should use same pragma set
> as existing one in lib/ring.

I generally prefer having the pragma coverage as narrow as possible, so they don't prevent catching unrelated bugs in the same file.

On the other hand,
I also like the suggestion in your other email - disabling these false-positive GCC warnings globally across DPDK for non-optimized builds.

And since the default build type is debugoptimized, it will not prevent GCC from emitting relevant warnings during normal development.

> 
> Other alternative is to use bulk object array as structure and do
> assignment.
> But that replaces ugly pragmas with ugly casts...

Yeah, let's not do that.

But thank you for exploring!

> 
> --- a/lib/stack/rte_stack_pile.h
> +++ b/lib/stack/rte_stack_pile.h
> @@
> +/* Bulk object array as a single object, so a copy is one assignment.
> */
> +struct rte_stack_pile_bulk_objs {
> +	void *objs[RTE_STACK_PILE_BULK_SIZE];
> +};
> +
> @@ __rte_stack_pile_bulk_pop_elems
>  		for (unsigned int i = 0; i < num; i++, tmp = tmp->next)
> -			rte_memcpy(&obj_table[i * RTE_STACK_PILE_BULK_SIZE],
> -					((struct rte_stack_pile_bulk_elem *)tmp)-
> >objs,
> -					sizeof(void *) *
> RTE_STACK_PILE_BULK_SIZE);
> +			*(struct rte_stack_pile_bulk_objs *)&obj_table[i *
> RTE_STACK_PILE_BULK_SIZE] =
> +				*(struct rte_stack_pile_bulk_objs *)((struct
> rte_stack_pile_bulk_elem *)tmp)->objs;
> @@ __rte_stack_pile_push
>  	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);
> +		*(struct rte_stack_pile_bulk_objs *)((struct
> rte_stack_pile_bulk_elem *)tmp)->objs =
> +			*(const struct rte_stack_pile_bulk_objs
> *)&obj_table[(n_bulk - i - 1) * RTE_STACK_PILE_BULK_SIZE];
> 

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

[Morten Brørup]

> From: Morten Brørup [mailto:mb@smartsharesystems.com]
> Sent: Tuesday, 20 October 2026 17.16
> To: Stephen Hemminger
> Cc: dev@dpdk.org; Thomas Monjalon; Konstantin Ananyev; Andrew
> Rybchenko; Bruce Richardson; Ali Alnubani
> Subject: RE: [PATCH] stack: fix pile GCC memcpy warnings
> 
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Tuesday, 20 October 2026 16.24
> >
> > On Tue, 20 Oct 2026 08:49:44 +0000
> > Morten Brørup <mb@smartsharesystems.com> 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>
> > > ---
> >
> > I don't like using compiler pragmas for this. It also means that if
> > compiler gets fixed or behaves differently you will never see it.
> >
> >
> > AI analysis shows some other options.
> >
> > Root cause is --buildtype=debug, i.e. -O0, not the GCC version. At -
> O0
> > nothing removes the dead n_bulk > 0 path for rte_stack_push(s, &obj,
> > 1), so the constant 256-byte memcpy is checked against obj (8 bytes)
> > and warns. Reproduced with GCC 13.3 and 14.2 at -O0; silent at -Og
> and
> > above. That means the GCC_VERSION >= 100000 gate is wrong at both
> ends:
> > any GCC with the warning fires (overflow since 8, overread since 11),
> > and on GCC 10 the -Wstringop-overread pragma itself is a -Wpragmas
> > error under -Werror. If the pragma stays, drop the version gate (keep
> > RTE_TOOLCHAIN_GCC) and fix the comment: GCC does not “know” the path
> is
> > dead, that is the whole problem.
> 
> Continuing this line of thinking...
> GCC defines an "__OPTIMIZE__" macro if any optimization above level 0
> is turned on.
> We could gate such pragmas with:
> #if defined(RTE_TOOLCHAIN_GCC) && !defined(__OPTIMIZE__)
> 
> >
> >
> > This should have a big ass comment, and it should use same pragma set
> > as existing one in lib/ring.
> 
> I generally prefer having the pragma coverage as narrow as possible, so
> they don't prevent catching unrelated bugs in the same file.
> 
> On the other hand,
> I also like the suggestion in your other email - disabling these false-
> positive GCC warnings globally across DPDK for non-optimized builds.
> 
> And since the default build type is debugoptimized, it will not prevent
> GCC from emitting relevant warnings during normal development.

The "other email" I'm referring to:
https://patchwork.dpdk.org/project/dpdk/patch/20261020145541.388371-1-stephen@networkplumber.org/

I prefer that solution over my patch.
Marking my patch as superseded.

> 
> >
> > Other alternative is to use bulk object array as structure and do
> > assignment.
> > But that replaces ugly pragmas with ugly casts...
> 
> Yeah, let's not do that.
> 
> But thank you for exploring!
> 
> >
> > --- a/lib/stack/rte_stack_pile.h
> > +++ b/lib/stack/rte_stack_pile.h
> > @@
> > +/* Bulk object array as a single object, so a copy is one
> assignment.
> > */
> > +struct rte_stack_pile_bulk_objs {
> > +	void *objs[RTE_STACK_PILE_BULK_SIZE];
> > +};
> > +
> > @@ __rte_stack_pile_bulk_pop_elems
> >  		for (unsigned int i = 0; i < num; i++, tmp = tmp->next)
> > -			rte_memcpy(&obj_table[i * RTE_STACK_PILE_BULK_SIZE],
> > -					((struct rte_stack_pile_bulk_elem *)tmp)-
> > >objs,
> > -					sizeof(void *) *
> > RTE_STACK_PILE_BULK_SIZE);
> > +			*(struct rte_stack_pile_bulk_objs *)&obj_table[i *
> > RTE_STACK_PILE_BULK_SIZE] =
> > +				*(struct rte_stack_pile_bulk_objs *)((struct
> > rte_stack_pile_bulk_elem *)tmp)->objs;
> > @@ __rte_stack_pile_push
> >  	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);
> > +		*(struct rte_stack_pile_bulk_objs *)((struct
> > rte_stack_pile_bulk_elem *)tmp)->objs =
> > +			*(const struct rte_stack_pile_bulk_objs
> > *)&obj_table[(n_bulk - i - 1) * RTE_STACK_PILE_BULK_SIZE];
> >

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

[Stephen Hemminger]

On Tue, 20 Oct 2026 08:49:44 +0000
Morten Brørup <mb@smartsharesystems.com> 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.

Rather than playing "what a bug with pragmas" a better solution is to disable
the warning globally if optimization is disabled.

From d79d5a1c4d7b7d43e31b26f5d5e218155f699ac0 Mon Sep 17 00:00:00 2001
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 20 Oct 2026 07:26:42 -0700
Subject: [PATCH] build: disable GCC string op warnings when unoptimized

Without optimization GCC's -Wstringop-overflow and -Wstringop-overread
are flow-insensitive: they check a memcpy() against the object size
even on paths that are dead for the inlined arguments. This breaks
debug builds of app/test with -Werror on lib/stack/rte_stack_pile.h,
and has required local pragma workarounds elsewhere.

Disable both warnings when optimization is 0. They stay enabled for
optimized builds, where the analysis is flow-sensitive.

Bugzilla ID: 2061

Reported-by: Ali Alnubani <alialnu@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 config/meson.build | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/config/meson.build b/config/meson.build
index 745097e8aa..ac90b9d4fa 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -378,6 +378,12 @@ if cc.has_argument('-Wno-comma')
     no_comma_cflag = '-Wno-comma'
 endif
 
+# GCC's string/memory access warnings are flow-insensitive without
+# optimization and produce false positives on dead paths of inlined code.
+if get_option('optimization') == '0' and cc.get_id() == 'gcc'
+    global_cflags += ['-Wno-stringop-overflow', '-Wno-stringop-overread']
++endif
+
 foreach arg: global_cflags
     if cc.has_argument(arg)
         add_project_arguments(arg, language: 'c')
-- 
2.53.0

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

[Morten Brørup]

> From: Stephen Hemminger <stephen@networkplumber.org>
> Date: Tue, 20 Oct 2026 07:26:42 -0700
> Subject: [PATCH] build: disable GCC string op warnings when unoptimized
> 
> Without optimization GCC's -Wstringop-overflow and -Wstringop-overread
> are flow-insensitive: they check a memcpy() against the object size
> even on paths that are dead for the inlined arguments. This breaks
> debug builds of app/test with -Werror on lib/stack/rte_stack_pile.h,
> and has required local pragma workarounds elsewhere.
> 
> Disable both warnings when optimization is 0. They stay enabled for
> optimized builds, where the analysis is flow-sensitive.
> 
> Bugzilla ID: 2061
> 
> Reported-by: Ali Alnubani <alialnu@nvidia.com>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
>  config/meson.build | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/config/meson.build b/config/meson.build
> index 745097e8aa..ac90b9d4fa 100644
> --- a/config/meson.build
> +++ b/config/meson.build
> @@ -378,6 +378,12 @@ if cc.has_argument('-Wno-comma')
>      no_comma_cflag = '-Wno-comma'
>  endif
> 
> +# GCC's string/memory access warnings are flow-insensitive without
> +# optimization and produce false positives on dead paths of inlined
> code.
> +if get_option('optimization') == '0' and cc.get_id() == 'gcc'
> +    global_cflags += ['-Wno-stringop-overflow', '-Wno-stringop-
> overread']
> ++endif
> +
>  foreach arg: global_cflags
>      if cc.has_argument(arg)
>          add_project_arguments(arg, language: 'c')
> --
> 2.53.0


Also '-Warray-bounds'?

Consider making it a series, and also remove existing overflow/overread pragmas in the code (if viable):
lib/ring/rte_ring_elem_pvt.h
lib/eal/ppc/include/rte_memcpy.h

With or without suggested changes,
Acked-by: Morten Brørup <mb@smartsharesystems.com>