More C type errors by default for GCC 14

Eric Gallager
Mon May 15 20:17:22 GMT 2023

On 5/15/23, Richard Earnshaw (lists) via Gcc <> wrote:
> On 10/05/2023 03:38, Eli Zaretskii via Gcc wrote:
>>> From: Arsen Arsenović <>
>>> Cc: Eli Zaretskii <>, Jakub Jelinek <>,
>>> 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.

More information about the Gcc mailing list