More C type errors by default for GCC 14

[Eric Gallager]

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ć <arsen@aarsen.me>
>>> Cc: Eli Zaretskii <eliz@gnu.org>, Jakub Jelinek <jakub@redhat.com>,
>>>   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 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.
>