From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id D8CF738555B5 for ; Mon, 15 May 2023 13:14:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D8CF738555B5 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2DDE12F4; Mon, 15 May 2023 06:14:56 -0700 (PDT) Received: from [10.2.78.54] (e120077-lin.cambridge.arm.com [10.2.78.54]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7ADD03F67D; Mon, 15 May 2023 06:14:10 -0700 (PDT) Message-ID: <4f246913-1495-2882-9c23-74924e9e2672@arm.com> Date: Mon, 15 May 2023 14:14:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: More C type errors by default for GCC 14 Content-Language: en-GB To: Jakub Jelinek , Martin Jambor Cc: Florian Weimer , gcc@gcc.gnu.org, c-std-porting@lists.linux.dev References: <877cth66qb.fsf@oldenburg.str.redhat.com> From: "Richard Earnshaw (lists)" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3494.7 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_NUMSUBJECT,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 12/05/2023 13:30, Jakub Jelinek via Gcc wrote: > On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote: >>> One fairly big GCC-internal task is to clear up the C test suite so that >>> it passes with the new compiler defaults. I already have an offer of >>> help for that, so I think we can complete this work in a reasonable time >>> frame. > > I'd prefer to keep at least significant portion of those tests as is with > -fpermissive added (plus of course we need new tests that verify the errors > are emitted), so that we have some testsuite coverage for those. Whilst there is historical precedent for -fpermissive, I have to say that I don't like it. The problem is that it is too imprecise as to what it means (and changes over time). It also becomes the lazy way to paper over the problems being exposed and, in future, may mean that other (perhaps more important) issues that are detectable will be silently ignored if it becomes widely used. R.