On 5/15/23, Richard Earnshaw (lists) via Gcc <gcc@gcc.gnu.org> wrote: > On 10/05/2023 03:38, Eli Zaretskii via Gcc wrote: >>> From: Arsen Arsenović <ar...@aarsen.me> >>> Cc: Eli Zaretskii <e...@gnu.org>, Jakub Jelinek <ja...@redhat.com>, >>> jwakely....@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 tip >>>> 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=...) 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=c2<something> would default to being more > aggressive in enforcing this (via changing the warning to -werror=) and > then -std=gnu2<something-later> 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= and having it be split based on whether -std= 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. >
