More C type errors by default for GCC 14
Ian Lance Taylor
iant@golang.org
Tue May 9 16:58:44 GMT 2023
On Tue, May 9, 2023 at 9:45 AM Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote:
>
> 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.
I think I wrote that error, back in 2007, because I thought it was odd
to rely on the C99 semantics for inline functions when not using C99.
And to encourage people to move to C99. But I wouldn't be surprised
if the compiler just works without the error. It would just require
adding a few test cases similar to gcc.dg/inline-18.c through
inline-21.c (well, inline-21.c would have to be removed or rewritten).
Ian
More information about the Gcc
mailing list