From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) by sourceware.org (Postfix) with ESMTPS id CDF043858C83 for ; Wed, 27 Apr 2022 02:59:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CDF043858C83 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=wanadoo.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-2f7d7e3b5bfso4537997b3.5 for ; Tue, 26 Apr 2022 19:59:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0vL0sN0rEAukjQ21K/pOOPY/pAChiTkKbeSfIxoIjIg=; b=VV6uljQR52HGPosc9o6ic5UorZ2QTheSc/E9KVC+1F7fWQDpZj2aY7lvSWZEmO+dJB TAu/a0U0wFcKv9Trl0WBL4iiC8riw8kfdCbYRBH55ZwrdV/po79V68IJCGJBzv5EkbuW ZdspiBl2dLiH8i4Fij6HDY94LEMqlRWMOJSQJAI3kV4KanMP2flNIm0wSHlLusmneJci VAyHTlNf4ANQPTltx4aXeM/9oju4tgt8/XS4IqO4TB190B+RU/X/E+G8xxeqiByepYm1 jDkzhBNofYqSKc3g9bXfe7rzfR9s7hED0BhSL5U54eRITxq2ONL+T6uDQx5ivdbZkH2n Gx+w== X-Gm-Message-State: AOAM533J28598fX7Aq55NMwep57d/RGEFrMkT6gHWSYZY+RLiFPW5Pxp RetqigmeVv4p9hosPdKEzSBWDyGvkzDwuPya2B0= X-Google-Smtp-Source: ABdhPJxuOKbSbtSYEK2PscBj01MMpuiLKLLk1ppADQSGSStMpoHVCu1Ypg4NI92XNWkLQ6BXRDTo3BHFyJMSn2N0xFg= X-Received: by 2002:a81:8cf:0:b0:2f4:da59:9eef with SMTP id 198-20020a8108cf000000b002f4da599eefmr25834657ywi.78.1651028349276; Tue, 26 Apr 2022 19:59:09 -0700 (PDT) MIME-Version: 1.0 References: <20220426161658.437466-1-mailhol.vincent@wanadoo.fr> In-Reply-To: From: Vincent MAILHOL Date: Wed, 27 Apr 2022 11:58:58 +0900 Message-ID: Subject: Re: [PATCH] linux/find: ignore -Wtype-limits to reduce W=2 warnings by 34% tree-wide To: Yury Norov Cc: Andy Shevchenko , Rasmus Villemoes , Nathan Chancellor , Nick Desaulniers , Tom Rix , linux-kernel@vger.kernel.org, Arnd Bergmann , gcc@gcc.gnu.org, Rikard Falkeborn , Alexander Lobakin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2022 02:59:11 -0000 + Alexander Lobakin On Wed. 27 Apr 2022 at 05:42, Yury Norov wrote: > + gcc@gcc.gnu.org > + Rikard Falkeborn > > On Wed, Apr 27, 2022 at 01:16:58AM +0900, Vincent Mailhol wrote: > > find_first_bit(), find_first_and_bit(), find_first_and_bit() and > > find_first_and_bit() all invokes GENMASK(size - 1, 0). > > > > This triggers below warning when compiled with W=3D2. > > > > | ./include/linux/find.h: In function 'find_first_bit': > > | ./include/linux/bits.h:25:36: warning: comparison of unsigned > > | expression in '< 0' is always false [-Wtype-limits] > > | 25 | __is_constexpr((l) > (h)), (l) > (h), 0))) > > | | ^ > > | ./include/linux/build_bug.h:16:62: note: in definition of macro > > | 'BUILD_BUG_ON_ZERO' > > | 16 | #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(= e)); }))) > > | | = ^ > > | ./include/linux/bits.h:25:17: note: in expansion of macro '__is_const= expr' > > | 25 | __is_constexpr((l) > (h)), (l) > (h), 0))) > > | | ^~~~~~~~~~~~~~ > > | ./include/linux/bits.h:38:10: note: in expansion of macro 'GENMASK_IN= PUT_CHECK' > > | 38 | (GENMASK_INPUT_CHECK(h, l) + __GENMASK(h, l)) > > | | ^~~~~~~~~~~~~~~~~~~ > > | ./include/linux/find.h:119:45: note: in expansion of macro 'GENMASK' > > | 119 | unsigned long val =3D *addr & GENMASK(size - = 1, 0); > > | | ^~~~~~~ > > > > linux/find.h being a widely used header file, above warning show up in > > thousand of files which include this header (either directly on > > indirectly). > > > > Because it is a false positive, we just silence -Wtype-limits flag > > locally to remove the spam. clang does not warn about it, so we just > > apply the diag_ignore() directive to gcc. > > > > By doing so, the warnings for a W=3D2 build are reduced by > > 34%. Benchmark was done with gcc 11.2.1 on Linux v5.17 x86_64 > > allyesconfig (except CONFIG_WERROR). Beforethe patch: 515496 warnings > > and after: 340097. > > > > For reference, past proposal to modify GENMASK_INPUT_CHECK() was > > rejected in: > > https://lore.kernel.org/all/20220304124416.1181029-1-mailhol.vincent@wa= nadoo.fr/ > > So, here is nothing wrong with the kernel code and we have an alternative > compiler (clang) that doesn't throw Wtype-limits. It sounds to me like an > internal GCC problem, and I don't understand how hiding broken Wtype-limi= ts > on kernel side would help people to improve GCC. > > On the thread you mentioned above: > > > > > > Have you fixed W=3D1 warnings? > > > > > Without fixing W=3D1 (which makes much more sense, when used with > > > > > WERROR=3Dy && COMPILE_TEST=3Dy) this has no value. > > > > > > > > How is this connected? > > > > > > By priorities. > > > I don't see much value in fixing W=3D2 per se if the code doesn't com= pile for W=3D1. > > > > *My code* compiles for W=3D1. For me, fixing this W=3D2 in the next in = line > > if speaking of priorities. > > > > I do not understand why I should be forbidden to fix a W=3D2 in the > > file which I am maintaining on the grounds that some code to which > > I do not care still has some W=3D1. > > If you are concerned about a particular driver - why don't you silence > the warning in there? Or alternatively build it with clang? Sorry if my previous comments looked selfish. I used the first person to illustrate my point but because this W=3D2 appears in thousands of files my real intent is to fix it for everybody, not only for myself. > With all that, I think that the right way to go is to fix the root > cause of this churn - broken Wtype-limits in GCC, and after that move > Wtype-limits to W=3D1. Anything else looks hacky to me. Why is this use of __diag_ignore() hacky compared when compared to the other use of __diag_ignore() or the use of -Wno-something in local Makefiles? I did my due diligence and researched GCC=E2=80=99s buzilla before sending this patch. There is an opened ticket here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D86647 In a perfect word, yes, all false positives should be fixed in the compiler, but the reality is that this bug was reported in July 2018, nearly four years ago. GCC developers have their own priorities and fixing this bug does not appear to be part of those. And I do not have the knowledge of GCC's internals to fix this myself. So what do we do next, blame GCC and do nothing or silence it on our side in order to have a mininfull W=3D2 output? Yours sincerely, Vincent Mailhol