From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 86F9F3858C66 for ; Tue, 26 Sep 2023 18:46:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 86F9F3858C66 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> User-agent: mu4e 1.10.6; emacs 30.0.50 From: Sam James To: Florian Weimer Cc: gcc@gcc.gnu.org Subject: Re: Report from the additional type errors for GCC 14 BoF at Cauldron Date: Tue, 26 Sep 2023 19:40:29 +0100 Organization: Gentoo In-reply-to: <87edilpcct.fsf@oldenburg.str.redhat.com> Message-ID: <87il7wkc0x.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,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: Florian Weimer via Gcc writes: > 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, but this reflects my understanding & what I would've said if I could've attended. > 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.) Ideally, I'd like both int-conversion + incompatible-pointer-types in this cycle, but if we have to defer one, I'd say to keep int-conversion. A lot of the low hanging fruit is already fixed there, with the only big remaining blocker being Vala (which is a compiler/transpiler). They've indicated they're not that fussed unless/until GCC changes. Putting it another way: I don't think waiting a year or two would actually help the situation much. > * How do we divide up the test suite cleanup work? Once there's some patches to work with, I'm happy to do a good chunk (obviously). IIRC Jakub and others indicated that the priority is to preserve the test cases (and hence pass appropriate flags) rather than fix them up, to avoid inadvertently testing the wrong thing. > > Thanks, > Florian