Re: More C type errors by default for GCC 14

[Sam James <sam@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3546 bytes --]


Jason Merrill <jason@redhat.com> writes:

> On Tue, May 9, 2023 at 12:45 PM Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote:
>>
>> * Richard Biener:
>>
>> > > Am 09.05.2023 um 18:13 schrieb David Edelsohn <dje.gcc@gmail.com>:
>> > >
>> > > On Tue, May 9, 2023 at 12:07 PM Jakub Jelinek via Gcc <gcc@gcc.gnu.org> wrote:
>> > >
>> > > On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote:
>> > > >
>> > > >
>> > > > > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc <gcc@gcc.gnu.org>:
>> > > > >
>> > > > > TL;DR: This message is about turning implicit-int,
>> > > > > implicit-function-declaration, and possibly int-conversion into errors
>> > > > > for GCC 14.
>> > > >
>> > > > I suppose the goal is to not need to rely on altering CFLAGS but
>> > > > change the default behavior with still being able to undo this
>> > > > using -Wno-error= or -Wno-?
>> > >
>> > > Can't people just compile C89/K&R code with -std=c89/-std=gnu89 and not get
>> > > these errors that way?
>> > >
>> > > As Florian mentioned:
>> > >
>> > > "Presently, we
>> > > cannot use -std=gnu89 etc. to opt out because there are packages which
>> > > require both C89-only language features and C99-style inlining, which is
>> > > currently not a combination supported by GCC (but maybe that could be
>> > > changed). "
>> >
>> > But surely it would reduce the number of packages to fix?  So I
>> > support both having only C99 and up reject no longer valid code _and_
>> > having -fpermissive be forgiving (demoting errors to warnings).
>>
>> It makes sense to disable the new erros in C89 mode.  It's what I did in
>> the instrumented compiler.  It also gives you yet another way to disable
>> the errors, using CC=c89, which works for some packages that do not
>> honor CFLAGS and do not support whitespace in CC.
>>
>> The part David quoted above is about this:
>>
>> $ gcc -fno-gnu89-inline -std=gnu89 t.c
>> cc1: error: ‘-fno-gnu89-inline’ is only supported in GNU99 or C99 mode
>>
>> And some packages need -fno-gnu89-inline, but also rely on implicit ints
>> and implicit function declarations heavily.  With a purely C89-based
>> opt-out and the -fno-gnu89-inline limitation, we wouldn't have a way to
>> compile these self-contradictory programs.  Hence the idea of
>> -fpermissive, in addition to the -std=gnu89 escape hatch.
>>
>> But perhaps the -fno-gnu89-inline limitation is easy to eliminate.  The
>> remaining reason for -fpermissive would be a flag that is accepted by
>> both gcc and g++, in case a package build system passes CFLAGS to g++ as
>> well, which sometimes happens.  And -fno-gnu89-inline is currently not
>> accepted by g++.  But in the Fedora package set, this (some C++ and a
>> C89 requirement) must be exceedingly rare because it's a subset of the
>> already tiny set of -fno-gnu89-inline -std=gnu89 packages.
>
> Another reason for -fpermissive is ease of use.  So if someone just
> wants to get an older package to build, they can add -fpermissive
> without having to figure out more detailed flags.
>
> Alternatively, if we go the default -Werror=various route, adding
> -Wno-error without any =foo to override everything might also be
> fairly convenient.

In addition to this, this made me realise something similar to what
Florian was saying wrt whitespace. Passing -Wno-error=... doesn't
always work with some poorly-written build scripts because they split
on '=' (this happens with some CMake when poorly written).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]