From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 78DBA3858C66 for ; Tue, 26 Sep 2023 18:52:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 78DBA3858C66 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org References: <87edilpcct.fsf@oldenburg.str.redhat.com> <52f4d828-92f3-4930-9992-e5899fc56d84@gmail.com> User-agent: mu4e 1.10.6; emacs 30.0.50 From: Sam James To: Jeff Law Cc: Florian Weimer , gcc@gcc.gnu.org Subject: Re: Report from the additional type errors for GCC 14 BoF at Cauldron Date: Tue, 26 Sep 2023 19:49:00 +0100 Organization: Gentoo In-reply-to: <52f4d828-92f3-4930-9992-e5899fc56d84@gmail.com> Message-ID: <87bkdokbrh.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Jeff Law via Gcc writes: > On 9/26/23 02:28, Florian Weimer via Gcc wrote: >> My understanding of the consensus goes as follows: >> * We want to make some changes in this area for GCC 14. >> * We should do the same thing that Clang does: default to the relevant >> -Werror= options. >> * Unlike regular warnings, these warnings-as-errors should also apply >> to system headers. >> * At least implict-int and implicit-function-declaration should be >> upgraded to errors in this way. >> * It's too early to make the () changes and bool-as-keyword from C2X >> for GCC 14. >> * We should fix the missing scope of the int-conversion warnings >> (PR109827). Likweise for incompatible-pointer-types (PR109826). >> Is this summary accurate? > I wasn't there, so I can't attest to accuracy. It does look like a > reasonable plan for gcc-14 though. > >> I think the open issues are: >> * Do we want to implement something else beside implicit-int and >> implicit-function-declaration? (Candidates are int-conversion and >> incompatible-pointer-types, and the void vs non-void part of >> return-type, maybe others as previously discussed on the list.) >> * How do we divide up the test suite cleanup work? > Not to open a can of worms, but shouldn't these be evaluated along the > same basic criteria? ie, what's Clang doing here, are these > warnings-as-errors and thus apply to system headers, etc. ANd the > biggie, do any of these issues tend to mask correctness errors in the > wild at a level roughly similar to implicit > int/implicit-function-declaration? My experience from doing the big rebuilds in Gentoo and working on patches is that int-conversion often comes up with completely broken code like wrong strerror_r variant (glibc vs musl) or with structs being initialised with the wrong members (not using C99 desig. initialisers and then differences with padding or similar). I don't think I can recall a harmless hit. Incompatible pointer types are a mix - sometimes it's harmless, but a lot of the infringers aren't great (again often indicating wrong prototypes being used or missing feature test macros). It's helped to find a lot of typos as well. The only real snag (which isn't a big deal IMO) is that it'll flag up attribute mismatches for function pointer types, at least with Clang, but that's not a big deal. Clang has done both of these (technically Clang has only done incompatible *function* pointer types rather than all incompatible pointer types, at least for now though). > > Jeff