From: Michael Barker <mikeb01@gmail.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, Ray Kinsella <mdr@ashroe.eu>
Subject: Re: [PATCH v2] Add pragma to ignore gcc-compat warnings in clang when used with diagnose_if.
Date: Mon, 24 Jan 2022 10:17:37 +1300 [thread overview]
Message-ID: <CALwNKeR6h2TC9RjUt0597Zj+WS_jvpc86zfNPXJiXzP5XX35pA@mail.gmail.com> (raw)
In-Reply-To: <10018405.DAOxP5AVGn@thomas>
[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]
On Fri, 21 Jan 2022 at 03:16, Thomas Monjalon <thomas@monjalon.net> wrote:
> 18/01/2022 00:23, Michael Barker:
> > When using clang with -Wall the use of diagnose_if kicks up a warning,
>
> Please could you copy the warning in the commit log?
>
I've updated the commit log to be more descriptive (and included the
associated warning).
> requiring all dpdk includes to be wrapped with the pragma. This change
> > isolates the ignore just the appropriate location and makes it easier
> > for users to apply -Wall,-Werror
>
> Please could you explain how it is related to -Wgcc-compat?
>
I'm currently working on some code that makes use of DPDK, which is built
with '-Wall,-Werror' enabled. When using the clang toolchain the build
fails as a result of this macro that this patch updates. The workaround
from my application is to wrap all of the DPDK header includes in pragma to
disable the warnings (see below). This has the unfortunate side effect of
disabling this warning across all of the included DPDK headers, which is
not ideal. Hence the reason to submit the patch which disables the warning
just in the location where it occurs.
#if defined(__clang__)
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wgcc-compat"
#endif
#include <rte_ethdev.h>
#if defined(__clang__)
#pragma GCC diagnostic pop "-Wgcc-compat"
#endif
>
> [...]
> > #define __rte_internal \
> > +_Pragma("GCC diagnostic push") \
> > +_Pragma("GCC diagnostic ignored \"-Wgcc-compat\"") \
> > __attribute__((diagnose_if(1, "Symbol is not public ABI", "error"), \
> > -section(".text.internal")))
> > +section(".text.internal"))) \
> > +_Pragma("GCC diagnostic pop")
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 3549 bytes --]
next prev parent reply other threads:[~2022-01-23 21:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-17 23:14 [PATCH] " Michael Barker
2022-01-17 23:23 ` [PATCH v2] " Michael Barker
2022-01-20 14:16 ` Thomas Monjalon
2022-01-23 21:17 ` Michael Barker [this message]
2022-01-23 23:53 ` Stephen Hemminger
2022-01-23 21:07 ` [PATCH v3] " Michael Barker
2022-01-23 21:20 ` [PATCH v4] " Michael Barker
2022-01-23 23:55 ` Stephen Hemminger
2022-01-31 0:08 ` Michael Barker
2022-01-25 10:33 ` Ray Kinsella
2022-01-31 0:10 ` Michael Barker
2022-01-31 0:05 ` [PATCH v5] " Michael Barker
2022-02-12 14:00 ` Thomas Monjalon
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=CALwNKeR6h2TC9RjUt0597Zj+WS_jvpc86zfNPXJiXzP5XX35pA@mail.gmail.com \
--to=mikeb01@gmail.com \
--cc=dev@dpdk.org \
--cc=mdr@ashroe.eu \
--cc=thomas@monjalon.net \
/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).