Jason Merrill <ja...@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....@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).
signature.asc
Description: PGP signature
