[EXT] Re: [PATCH] ring: compilation fix with GCC-12

Thomas Monjalon thomas at monjalon.net
Thu Jan 12 22:41:45 CET 2023


23/08/2022 11:38, Amit Prakash Shukla:
> From: Konstantin Ananyev <konstantin.v.ananyev at yandex.ru>
> > 06/08/2022 19:35, Honnappa Nagarahalli пишет:
> > >> Replacing memcpy with rte_memcpy fixes the GCC-12 compilation issue.
> > > 
> > > Any reason why this replacement fixes the problem?
> > > Do you have any performance numbers with this change?
> > >
> > >> Also it would be better to change to rte_memcpy as the function is
> > >> called in fastpath.
> > > 
> > > On Arm platforms, memcpy in the later versions has the best performance.
> > 
> > I agree with Honnappa, it is better to keep memcpy() here.
> > Actually what is strange - why it ends up in
> > __rte_ring_dequeue_elems_128() at all?
> > Inside rxa_intr_ring_dequeue() we clearly doing: rte_ring_dequeue(), which
> > should boil down to ___rte_ring_dequeue_elems_64().
> > it should go to __rte_ring_dequeue_elems_128() at all.
> 
> I agree. After having close look and doing few experiments,
> ideally it should not be going to __rte_ring_dequeue_elems_128().
> Sizeof(in call of rte_ring_enqueue_elem) gets evaluated at compile time
> which in this case it is evaluated to 8 bytes so 
> __rte_ring_dequeue_elems_128() shall not be in the path. Looks like more of a gcc-12 bug.?
> 
> > Another q - is this warning happens only on arm platforms?
> 
> Warning is observed on x86 with build type as debug.
> "meson --werror --buildtype=debug build"

I confirm the compilation issue on x86 with GCC 12 in a debug build.

We need to find a workaround.
Is it reported to GCC already?




More information about the dev mailing list