Re: More C type errors by default for GCC 14

[Florian Weimer <fweimer@redhat.com>]

* 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.

Thanks,
Florian