DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Mattias Rönnblom" <hofors@lysator.liu.se>
To: Tyler Retzlaff <roretzla@linux.microsoft.com>, bugzilla@dpdk.org
Cc: dev@dpdk.org
Subject: Re: [DPDK/core Bug 1425] enable_stdatomic=true breaks C++ on GCC 11 and earlier
Date: Tue, 30 Apr 2024 22:06:08 +0200	[thread overview]
Message-ID: <f88b14dc-373d-4917-a8fa-443f44481460@lysator.liu.se> (raw)
In-Reply-To: <20240429231458.GB17852@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>

On 2024-04-30 01:14, Tyler Retzlaff wrote:
> On Mon, Apr 29, 2024 at 06:21:13AM +0000, bugzilla@dpdk.org wrote:
>> https://bugs.dpdk.org/show_bug.cgi?id=1425
>>
>>              Bug ID: 1425
>>             Summary: enable_stdatomic=true breaks C++  on GCC 11 and
>>                      earlier
>>             Product: DPDK
>>             Version: 23.11
>>            Hardware: All
>>                  OS: Linux
>>              Status: UNCONFIRMED
>>            Severity: normal
>>            Priority: Normal
>>           Component: core
>>            Assignee: dev@dpdk.org
>>            Reporter: mattias.ronnblom@ericsson.com
>>    Target Milestone: ---
>>
>> On GCC 11 and earlier, configuring enable_stdatomic=true prevents the use of
>> all DPDK header files that directly or indirectly include <rte_stdatomic.h>
>> from a C++ translation unit (e.g., app).
>>
>> <rte_stdatomic.h> includes <stdatomic.h>, which in turn is not necessarily
>> C++-compatible.
> 
> This is known but to add some information.
> 

Is it also documented?

> C++ and enable_stdatomic=true for llvm and gcc are not currently
> supported. the combination will remain unsupported for C++ compilers
> that do not support -std=c++23 which is the first C++ standard that
> requires interoperability with C11 stdatomic.h >
> When enable_stdatomic=true there are bugs/incorrect usages of atomic
> qualifier in casts that (even when using C++23) cause compilation
> failure. These are a fixable but are low priority without -std=c++23.
> 
> Finally, the legacy atomics remain unconverted to stdatomic. This will
> cause enable_stdatomic=true not to build when using llvm (but not gcc)
> because llvm strictly enforces qualification when using atomic generics.
>

OK, I see. It'll be a while until enable_stdatomic is usable outside 
Windows then, for generic builds.

Am I right if I say that C++23-capable compilers/run-times are supposed 
to have a <stdatomic.h> which interoperates with C++ even in C++11-mode? 
Or need the application be compiled as C++23.

>>
>> -- 
>> You are receiving this mail because:
>> You are the assignee for the bug.

  reply	other threads:[~2024-04-30 20:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-29  6:21 bugzilla
2024-04-29 23:14 ` Tyler Retzlaff
2024-04-30 20:06   ` Mattias Rönnblom [this message]
2024-04-30 20:37     ` Tyler Retzlaff

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=f88b14dc-373d-4917-a8fa-443f44481460@lysator.liu.se \
    --to=hofors@lysator.liu.se \
    --cc=bugzilla@dpdk.org \
    --cc=dev@dpdk.org \
    --cc=roretzla@linux.microsoft.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).