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....@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 any case, I think we want an easy answer for the second group. Jason
