From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) by sourceware.org (Postfix) with ESMTPS id E11323857713 for ; Mon, 15 May 2023 20:17:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E11323857713 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gwmail.gwu.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gwmail.gwu.edu Received: by mail-vk1-xa36.google.com with SMTP id 71dfb90a1353d-4501ca552a3so6991108e0c.2 for ; Mon, 15 May 2023 13:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gwmail.gwu.edu; s=google; t=1684181843; x=1686773843; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=d2sfi6zImbgvnvVaUEugSuclF+cfVWYRQcalS3YjKMk=; b=NySVdb2r4ovfoJfTlFtlMUsC+pFHWbJSrdNY8HsegT1wRwQCyvb30h8vNfKWN3yz9S /Lvl+JhDLxzk9v5LBPaK4FS99Y8VJJD/aXBKoJIeGxD55uR1eXTub5q8P7fqgY9KgqKO 07e9dCct190vTRIJB252OIT38gp4gko8vd7yilPEmmfEqC8Lp3eGNypB1eNmXFBXYmju DkSyVw0YdbYgXomN49VRGBpiI86vamQQVOWq2YUse71/um36+WxAP5uao3NzFKl5iv3s IjlRpv9SGNEbVpp18QQL80N/p3+Xi0WCuGFwvDD03Qfl+s3rOJnhiOv6frN1bucyCFgZ VScw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684181843; x=1686773843; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=d2sfi6zImbgvnvVaUEugSuclF+cfVWYRQcalS3YjKMk=; b=DW6ixSVoVo30hBXvs3EdJZXFFu/Ap024YDFVN9vQMorsrIgBqKgUS0QVotoTdM+1hT fcHnZfitE4S6j7AVIxJkQ2sXhjR9gmZ/RXqRC0MIyRcDhmLjbIP+fcXA3Qz1JsQVHAMJ wyVZnptiMmmw7ppObQ1Oh2ejC1Mu/hD7L0MlRMkdPPMIAQOHpBKGiitne7W/HuyFUlX1 Mms4xna+911S2MtNr39JTUfwuuHyVK1CFMXEoB++0ZbygtkDseFeUQ33iY7ikHg27I+V c0krtDX6I0nEbORe7kZ1JrPkauHyRRLWXrwmQKpRftYLCDSfPFz1pVkWbRymsnF4ew/u EbGQ== X-Gm-Message-State: AC+VfDwcunoRyv49d82yTeyUg3kzS9twKLe0cF1jbaJb5gBkM7XpslvF vrz5EIm+A9gTKYWebutvSB/d/zRCj8jDjPlgxjShDQ== X-Google-Smtp-Source: ACHHUZ5v13FNwRhO1JOWbtbV2oTj4gBTNxCxFBoV/1rU8Gnjp4scFlSSRBrQDVZzRT2MdLnKvf0sE5dVwKlbOWDs8dQ= X-Received: by 2002:a1f:cc07:0:b0:453:b080:632d with SMTP id c7-20020a1fcc07000000b00453b080632dmr4757573vkg.0.1684181843157; Mon, 15 May 2023 13:17:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a59:c046:0:b0:3ca:d638:7c49 with HTTP; Mon, 15 May 2023 13:17:22 -0700 (PDT) In-Reply-To: <6537c979-1c1a-9266-b372-7d2ebbf50438@arm.com> References: <877cth66qb.fsf@oldenburg.str.redhat.com> <20230509102201.6aa2a7d14fdb2f1e7abff449@killthe.net> <87r0rp5uf8.fsf@aarsen.me> <83ttwla1ep.fsf@gnu.org> <83lehx9vix.fsf@gnu.org> <83fs859unu.fsf@gnu.org> <864jolw8id.fsf@aarsen.me> <83cz38ap1a.fsf@gnu.org> <6537c979-1c1a-9266-b372-7d2ebbf50438@arm.com> From: Eric Gallager Date: Mon, 15 May 2023 16:17:22 -0400 Message-ID: Subject: Re: More C type errors by default for GCC 14 To: "Richard Earnshaw (lists)" Cc: Eli Zaretskii , =?UTF-8?Q?Arsen_Arsenovi=C4=87?= , dje.gcc@gmail.com, jakub@redhat.com, jwakely.gcc@gmail.com, gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,JMQ_SPF_NEUTRAL,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: On 5/15/23, Richard Earnshaw (lists) via Gcc wrote: > On 10/05/2023 03:38, Eli Zaretskii via Gcc wrote: >>> From: Arsen Arsenovi=C4=87 >>> Cc: Eli Zaretskii , Jakub Jelinek , >>> jwakely.gcc@gmail.com, gcc@gcc.gnu.org >>> Date: Tue, 09 May 2023 22:21:03 +0200 >>> >>>> The concern is using the good will of the GNU Toolchain brand as the t= ip >>>> of >>>> the spear or battering ram to motivate software packages to fix their >>>> problems. It's using GCC as leverage in a manner that is difficult for >>>> package maintainers to avoid. Maybe that's a necessary approach, but >>>> we >>>> should be clear about the reasoning. Again, I'm not objecting, but >>>> let's >>>> clarify why we are choosing this approach. >>> >>> Both the GNU Toolchain and the GNU Toolchain users will benefit from a >>> stricter toolchain. >>> >>> People can and have stopped using the GNU Toolchain due to lackluster >>> and non-strict defaults. This is certainly not positive for the brand, >>> and I doubt it buys it much good will. >> >> It is not GCC's business to force developers of packages to get their >> act together. It is the business of those package developers >> themselves. GCC should give those developers effective and convenient >> means of detecting any unsafe and dubious code and of correcting it as >> they see fit. Which GCC already does by emitting warnings. GCC >> should only error out if it is completely unable to produce valid >> code, which is not the case here, since it has been producing valid >> code for ages. >> >> It is a disservice to GCC users if a program that compiled yesterday >> and worked perfectly well suddenly cannot be built because GCC was >> upgraded, perhaps due to completely unrelated reasons. It would be a >> grave mistake on the part of GCC to decide that part of its mission is >> to teach package developers how to write their code and when and how >> to modify it. > > That argument doesn't really wash. We already upgrade the 'default' > language version (-std=3D...) from time to time and that can impact > existing programs (eg we changed from gnu-inline to std-inline model). > > If this really isn't legal C, then my suggestion would be to tie this to > a setting of -std, so -std=3Dc2 would default to being more > aggressive in enforcing this (via changing the warning to -werror=3D) and > then -std=3Dgnu2 might follow a bit behind that. > Furthermore, we can trail this aggressively in release notes so that > nobody can really claim to be surprised. > I support this plan for using -Werror=3D and having it be split based on whether -std=3D is set to a strict ANSI option or a GNU option; is there a way to do that in the optfiles, or would it have to be handled at the specs level instead? > At some point that std setting will become the default and the overall > goal is achieved. > > R. >