> From: Stephen Hemminger [mailto:[email protected]] > Sent: Friday, 16 January 2026 07.46 > > When building with LTO (Link Time Optimization), GCC performs > aggressive cross-compilation-unit inlining. This causes the compiler > to analyze all code paths in __rte_ring_do_dequeue_elems(), including > the 16-byte element path (__rte_ring_dequeue_elems_128), even when > the runtime element size is only 4 bytes. > > The static analyzer sees that the 16-byte path would copy > 32 elements * 16 bytes = 512 bytes into a 128-byte buffer > (uint32_t[32]), > triggering -Wstringop-overflow warnings. > > The existing #pragma GCC diagnostic suppression in rte_ring_elem_pvt.h > doesn't help because with LTO the warning context shifts to the test > file where the inlined code is instantiated. > > Fix by sizing all buffers passed to soring acquire/dequeue functions > for the worst-case element size (16 bytes = 4 * sizeof(uint32_t)). > This satisfies the static analyzer without changing runtime behavior.
Using wildly oversized buffers doesn't seem like a recommendable solution. If the ring library is ever updated to support cache size elements (64 byte), the buffers would have to be oversize by factor 16. Maybe adding __rte_assume(sor->esize == sizeof(uint32_t)); immediately before calling each of the affected soring functions would fix the problem instead? It's only a test application, so oversized buffers as a workaround is acceptable. But if it serves as guidance for real applications, a better solution/workaround would be preferable. > > Bugzilla ID: 1458 > > Signed-off-by: Stephen Hemminger <[email protected]> > --- > app/test/test_soring.c | 29 ++++++++++++++++++++++------- > 1 file changed, 22 insertions(+), 7 deletions(-) > > diff --git a/app/test/test_soring.c b/app/test/test_soring.c > index 3c1944424e..96be3935d4 100644 > --- a/app/test/test_soring.c > +++ b/app/test/test_soring.c > @@ -31,6 +31,19 @@ > > #define MAX_ACQUIRED 20 > > +/* > + * Buffer scaling factor for static analyzer appeasement. > + * > + * With LTO, GCC analyzes all code paths in > __rte_ring_do_dequeue_elems(), > + * including the 16-byte element path, even when runtime esize is > smaller. > + * Buffers passed to soring acquire/dequeue must be sized for the > worst-case > + * element size (16 bytes) to avoid -Wstringop-overflow warnings. > + * > + * Scale factor of 4 converts uint32_t count to 16-byte element > capacity: > + * N elements * 4 * sizeof(uint32_t) = N * 16 bytes > + */ > +#define SORING_TEST_BUFSIZE(n) ((n) * 4) > + > #define SORING_TEST_ASSERT(val, expected) do { \ > RTE_TEST_ASSERT(expected == val, \ > "%s: expected %u got %u\n", #val, expected, val); \ > @@ -58,7 +71,8 @@ move_forward_stage(struct rte_soring *sor, > { > uint32_t acquired; > uint32_t ftoken; > - uint32_t *acquired_objs[MAX_ACQUIRED]; > + /* Sized for 16-byte elements to satisfy LTO static analysis */ > + uint32_t *acquired_objs[SORING_TEST_BUFSIZE(MAX_ACQUIRED)]; > > acquired = rte_soring_acquire_bulk(sor, acquired_objs, stage, > num_packets, &ftoken, NULL); > @@ -149,12 +163,13 @@ test_soring_stages(void) > { > struct rte_soring *sor = NULL; > struct rte_soring_param prm; > - uint32_t objs[32]; > - uint32_t rcs[32]; > - uint32_t acquired_objs[32]; > - uint32_t acquired_rcs[32]; > - uint32_t dequeued_rcs[32]; > - uint32_t dequeued_objs[32]; > + /* Buffers sized for 16-byte elements to satisfy LTO static > analysis */ > + uint32_t objs[SORING_TEST_BUFSIZE(32)]; > + uint32_t rcs[SORING_TEST_BUFSIZE(32)]; > + uint32_t acquired_objs[SORING_TEST_BUFSIZE(32)]; > + uint32_t acquired_rcs[SORING_TEST_BUFSIZE(32)]; > + uint32_t dequeued_rcs[SORING_TEST_BUFSIZE(32)]; > + uint32_t dequeued_objs[SORING_TEST_BUFSIZE(32)]; > size_t ssz; > uint32_t stage, enqueued, dequeued, acquired; > uint32_t i, ftoken; > -- > 2.51.0
