diff mbox series

[01/13] tools: disable -Wno-type-limits

Message ID 20210316015424.1999082-2-yury.norov@gmail.com (mailing list archive)
State New
Headers show
Series lib/find_bit: fast path for small bitmaps | expand

Commit Message

Yury Norov March 16, 2021, 1:54 a.m. UTC
GENMASK(h, l) may be passed with unsigned types. In such case, type-limits
warning is generated for example in case of GENMASK(h, 0).

Signed-off-by: Yury Norov <yury.norov@gmail.com>
---
 tools/scripts/Makefile.include | 1 +
 1 file changed, 1 insertion(+)

Comments

Rasmus Villemoes March 16, 2021, 8:17 a.m. UTC | #1
On 16/03/2021 02.54, Yury Norov wrote:
> GENMASK(h, l) may be passed with unsigned types. In such case, type-limits
> warning is generated for example in case of GENMASK(h, 0).
> 
> Signed-off-by: Yury Norov <yury.norov@gmail.com>
> ---
>  tools/scripts/Makefile.include | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
> index 84dbf61a7eca..15e99905cb7d 100644
> --- a/tools/scripts/Makefile.include
> +++ b/tools/scripts/Makefile.include
> @@ -38,6 +38,7 @@ EXTRA_WARNINGS += -Wswitch-enum
>  EXTRA_WARNINGS += -Wundef
>  EXTRA_WARNINGS += -Wwrite-strings
>  EXTRA_WARNINGS += -Wformat
> +EXTRA_WARNINGS += -Wno-type-limits
>

I don't like that kind of collateral damage. I seem to recall another
instance where a macro was instead rewritten to avoid triggering the
type-limits warning (with a comment explaining the uglyness). Something like

foo > bar      is the same as
!(foo <= bar)  which is the same as
!(foo == bar || foo < bar)

Dunno if that would work here, but if it did, it would have the bonus
that when somebody builds the kernel proper with Wtype-limits enabled
(maybe W=1 or W=2) there would be no false positives from GENMASK to
wade through.

Alternatively, we really should consider making use of _Pragma to
locally disable/re-enable certain warnings.

Rasmus
Andy Shevchenko March 16, 2021, 11:39 a.m. UTC | #2
On Tue, Mar 16, 2021 at 09:17:24AM +0100, Rasmus Villemoes wrote:
> On 16/03/2021 02.54, Yury Norov wrote:
> > GENMASK(h, l) may be passed with unsigned types. In such case, type-limits
> > warning is generated for example in case of GENMASK(h, 0).

...

> I don't like that kind of collateral damage. I seem to recall another
> instance where a macro was instead rewritten to avoid triggering the
> type-limits warning (with a comment explaining the uglyness). Something like
> 
> foo > bar      is the same as
> !(foo <= bar)  which is the same as
> !(foo == bar || foo < bar)
> 
> Dunno if that would work here, but if it did, it would have the bonus
> that when somebody builds the kernel proper with Wtype-limits enabled
> (maybe W=1 or W=2) there would be no false positives from GENMASK to
> wade through.
> 
> Alternatively, we really should consider making use of _Pragma to
> locally disable/re-enable certain warnings.

Rasmus, in the kernel the same was fixed as per 355a3587d4ca.
I don't know why tools should be different to that.
diff mbox series

Patch

diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
index 84dbf61a7eca..15e99905cb7d 100644
--- a/tools/scripts/Makefile.include
+++ b/tools/scripts/Makefile.include
@@ -38,6 +38,7 @@  EXTRA_WARNINGS += -Wswitch-enum
 EXTRA_WARNINGS += -Wundef
 EXTRA_WARNINGS += -Wwrite-strings
 EXTRA_WARNINGS += -Wformat
+EXTRA_WARNINGS += -Wno-type-limits
 
 CC_NO_CLANG := $(shell $(CC) -dM -E -x c /dev/null | grep -Fq "__clang__"; echo $$?)