[v2] Add pragma to ignore gcc-compat warnings in clang when used with diagnose_if.

  When using clang with -Wall the use of diagnose_if kicks up a 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

Signed-off-by: Michael Barker <mikeb01@gmail.com>
---
 lib/eal/include/rte_compat.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
  

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?

> 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?

[...]
>  #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")
  

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")
>
>
>
>
  

On Mon, 24 Jan 2022 10:17:37 +1300
Michael Barker <mikeb01@gmail.com> wrote:

> 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.
> 

Fix the issue please, don't suppress it.