All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>,
	Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
	Amit Prakash Shukla <amitprakashs@marvell.com>
Cc: dev@dpdk.org, Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
	david.marchand@redhat.com, bruce.richardson@intel.com,
	ferruh.yigit@amd.com
Subject: Re: [EXT] Re: [PATCH] ring: compilation fix with GCC-12
Date: Thu, 12 Jan 2023 22:41:45 +0100	[thread overview]
Message-ID: <837071028.0ifERbkFSE@thomas> (raw)
In-Reply-To: <PH0PR18MB5167F3DCD49D1EFEBB8A6EA1C8709@PH0PR18MB5167.namprd18.prod.outlook.com>

23/08/2022 11:38, Amit Prakash Shukla:
> From: Konstantin Ananyev <konstantin.v.ananyev@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?



  parent reply	other threads:[~2023-01-12 21:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-05  9:03 [PATCH] ring: compilation fix with GCC-12 Amit Prakash Shukla
2022-08-05 15:37 ` Stephen Hemminger
2022-08-06 18:35 ` Honnappa Nagarahalli
2022-08-07 12:26   ` Konstantin Ananyev
2022-08-23  9:38     ` [EXT] " Amit Prakash Shukla
2022-08-23  9:41       ` Amit Prakash Shukla
2023-01-12 21:41       ` Thomas Monjalon [this message]
2023-01-13 12:39         ` Amit Prakash Shukla
2023-01-13 13:11           ` Thomas Monjalon
2023-02-13  1:48             ` Konstantin Ananyev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=837071028.0ifERbkFSE@thomas \
    --to=thomas@monjalon.net \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=amitprakashs@marvell.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=jerinj@marvell.com \
    --cc=konstantin.v.ananyev@yandex.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.