Re: More C type errors by default for GCC 14

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Jason Merrill <[email protected]> writes:

> On Tue, May 9, 2023 at 12:45=E2=80=AFPM Florian Weimer via Gcc <[email protected]=
nu.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 G=
cc <[email protected]> wrote:
>> > >
>> > > On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wro=
te:
>> > > >
>> > > >
>> > > > > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc <[email protected]=
nu.org>:
>> > > > >
>> > > > > =EF=BB=BFTL;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=3D or -Wno-?
>> > >
>> > > Can't people just compile C89/K&R code with -std=3Dc89/-std=3Dgnu89 =
and not get
>> > > these errors that way?
>> > >
>> > > As Florian mentioned:
>> > >
>> > > "Presently, we
>> > > cannot use -std=3Dgnu89 etc. to opt out because there are packages w=
hich
>> > > require both C89-only language features and C99-style inlining, whic=
h 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 GNU=
99 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 addition to this, this made me realise something similar to what
Florian was saying wrt whitespace. Passing -Wno-error=3D... doesn't
always work with some poorly-written build scripts because they split
on '=3D' (this happens with some CMake when poorly written).

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZFqAGF8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB
NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv
by5vcmcACgkQc4QJ9SDfkZB9QwEA3ZNJ0En2a98ugUHNK89mZqBPakEXlQDzQgWB
Sk2IcP4BALnMM3LY7TKUBuUiwrJikovzcN7i6YVJrXy/CCEFQCEE
=aHBA
-----END PGP SIGNATURE-----
--=-=-=--