Re: More C type errors by default for GCC 14

On Tue, May 9, 2023 at 12:45=E2=80=AFPM Florian Weimer via Gcc <[email protected]=
.org> wrote:
>
> * Richard Biener:
>
> > > Am 09.05.2023 um 18:13 schrieb David Edelsohn <[email protected]>:
> > >
> > > =EF=BB=BFOn Tue, May 9, 2023 at 12:07=E2=80=AFPM Jakub Jelinek via Gc=
c <[email protected]> wrote:
> > >
> > > On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrot=
e:
> > > >
> > > >
> > > > > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc <[email protected]=
u.org>:
> > > > >
> > > > > =EF=BB=BFTL;DR: This message is about turning implicit-int,
> > > > > implicit-function-declaration, and possibly int-conversion into e=
rrors
> > > > > 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=3D or -Wno-?
> > >
> > > Can't people just compile C89/K&R code with -std=3Dc89/-std=3Dgnu89 a=
nd not get
> > > these errors that way?
> > >
> > > As Florian mentioned:
> > >
> > > "Presently, we
> > > cannot use -std=3Dgnu89 etc. to opt out because there are packages wh=
ich
> > > 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=3Dc89, 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=3Dgnu89 t.c
> cc1: error: =E2=80=98-fno-gnu89-inline=E2=80=99 is only supported in GNU9=
9 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=3Dgnu89 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=3Dgnu89 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=3Dvarious route, adding
-Wno-error without any =3Dfoo to override everything might also be
fairly convenient.

In any case, I think we want an easy answer for the second group.


Jason