c-std-porting.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* Re: More C type errors by default for GCC 14
       [not found] ` <BBE9950C-28AA-4A1C-A4C5-7F486538004E@gmail.com>
@ 2023-05-09 16:44   ` Florian Weimer
  2023-05-09 16:58     ` Ian Lance Taylor
  2023-05-09 17:08     ` Jason Merrill
  0 siblings, 2 replies; 24+ messages in thread
From: Florian Weimer @ 2023-05-09 16:44 UTC (permalink / raw)
  To: Richard Biener; +Cc: David Edelsohn, Jakub Jelinek, gcc, c-std-porting

* 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


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-09 16:44   ` More C type errors by default for GCC 14 Florian Weimer
@ 2023-05-09 16:58     ` Ian Lance Taylor
  2023-05-09 17:08     ` Jason Merrill
  1 sibling, 0 replies; 24+ messages in thread
From: Ian Lance Taylor @ 2023-05-09 16:58 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Richard Biener, David Edelsohn, Jakub Jelinek, gcc, c-std-porting

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-09 16:44   ` More C type errors by default for GCC 14 Florian Weimer
  2023-05-09 16:58     ` Ian Lance Taylor
@ 2023-05-09 17:08     ` Jason Merrill
  2023-05-09 17:16       ` Sam James
  1 sibling, 1 reply; 24+ messages in thread
From: Jason Merrill @ 2023-05-09 17:08 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Richard Biener, David Edelsohn, Jakub Jelinek, gcc, c-std-porting

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

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


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-09 17:08     ` Jason Merrill
@ 2023-05-09 17:16       ` Sam James
  0 siblings, 0 replies; 24+ messages in thread
From: Sam James @ 2023-05-09 17:16 UTC (permalink / raw)
  To: Jason Merrill
  Cc: Florian Weimer, Richard Biener, David Edelsohn, Jakub Jelinek,
	gcc, c-std-porting

[-- Attachment #1: Type: text/plain, Size: 3546 bytes --]


Jason Merrill <jason@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.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.
>
> 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).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-12 12:30   ` Jakub Jelinek
  2023-05-15 12:46     ` Michael Matz
@ 2023-05-15 13:14     ` Richard Earnshaw (lists)
  1 sibling, 0 replies; 24+ messages in thread
From: Richard Earnshaw (lists) @ 2023-05-15 13:14 UTC (permalink / raw)
  To: Jakub Jelinek, Martin Jambor; +Cc: Florian Weimer, gcc, c-std-porting

On 12/05/2023 13:30, Jakub Jelinek via Gcc wrote:
> On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote:
>>> One fairly big GCC-internal task is to clear up the C test suite so that
>>> it passes with the new compiler defaults.  I already have an offer of
>>> help for that, so I think we can complete this work in a reasonable time
>>> frame.
> 
> I'd prefer to keep at least significant portion of those tests as is with
> -fpermissive added (plus of course we need new tests that verify the errors
> are emitted), so that we have some testsuite coverage for those.

Whilst there is historical precedent for -fpermissive, I have to say 
that I don't like it.  The problem is that it is too imprecise as to 
what it means (and changes over time).  It also becomes the lazy way to 
paper over the problems being exposed and, in future, may mean that 
other (perhaps more important) issues that are detectable will be 
silently ignored if it becomes widely used.

R.


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-12 12:30   ` Jakub Jelinek
@ 2023-05-15 12:46     ` Michael Matz
  2023-05-15 13:14     ` Richard Earnshaw (lists)
  1 sibling, 0 replies; 24+ messages in thread
From: Michael Matz @ 2023-05-15 12:46 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Martin Jambor, Florian Weimer, gcc, c-std-porting

Hello,

On Fri, 12 May 2023, Jakub Jelinek via Gcc wrote:

> On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote:
> > > One fairly big GCC-internal task is to clear up the C test suite so that
> > > it passes with the new compiler defaults.  I already have an offer of
> > > help for that, so I think we can complete this work in a reasonable time
> > > frame.
> 
> I'd prefer to keep at least significant portion of those tests as is with
> -fpermissive added (plus of course we need new tests that verify the errors
> are emitted), so that we have some testsuite coverage for those.

Yes, this!  Try to (!) never change committed testcase souces, however 
invalid they may be (changing how they are compiled, including by 
introducing new dg-directives and using them in comments, is of course 
okay).

(And FWIW: I'm fine with Florians proposal.  I personally think the 
arguments for upgrading the warnings to errors are _not_ strong enough, 
but I don't think so very strongly :) )


Ciao,
Michael.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-12  9:33 ` Martin Jambor
@ 2023-05-12 12:30   ` Jakub Jelinek
  2023-05-15 12:46     ` Michael Matz
  2023-05-15 13:14     ` Richard Earnshaw (lists)
  0 siblings, 2 replies; 24+ messages in thread
From: Jakub Jelinek @ 2023-05-12 12:30 UTC (permalink / raw)
  To: Martin Jambor; +Cc: Florian Weimer, gcc, c-std-porting

On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote:
> > One fairly big GCC-internal task is to clear up the C test suite so that
> > it passes with the new compiler defaults.  I already have an offer of
> > help for that, so I think we can complete this work in a reasonable time
> > frame.

I'd prefer to keep at least significant portion of those tests as is with
-fpermissive added (plus of course we need new tests that verify the errors
are emitted), so that we have some testsuite coverage for those.

> So, a note to all users of cvise, creduce, delta etc.: Add appropriate
> -Werror flags to your checking scripts so that we don't add more of this :-)

While it is true that for C cvise/creduce/delta often end up with the
implicit ints/implicit function declarations/int-conversions because it
happens to still compile without errors, I and others routinely fix up those
testcases back to valid C provided they still reproduce the reported
problem, so I think it isn't that bad in our testsuite.
But for cvise/creduce/delta reduced testcases with GCC 14 the nice things is
that most of the time these constructs will be gone ;)

Note, using -Werror for all warnings for testsuite reduction often results
in much slower reduction process and larger end result compared to allowing
some warnings but then fixing them up by hand where possible if it still
reproduces.

	Jakub


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-09 12:15 Florian Weimer
  2023-05-09 15:16 ` Richard Biener
       [not found] ` <CAGWvnykoEtT0BQtuN70DN6tWohtf=Mm7SW55psZvVmj3OvKUEg@mail.gmail.com>
@ 2023-05-12  9:33 ` Martin Jambor
  2023-05-12 12:30   ` Jakub Jelinek
  2 siblings, 1 reply; 24+ messages in thread
From: Martin Jambor @ 2023-05-12  9:33 UTC (permalink / raw)
  To: Florian Weimer, gcc; +Cc: c-std-porting

Hi,

On Tue, May 09 2023, Florian Weimer via Gcc wrote:
> TL;DR: This message is about turning implicit-int,
> implicit-function-declaration, and possibly int-conversion into errors
> for GCC 14.
>

FWIW, I personally support the proposal.

Regarding the huge discussion that ensued, I would just like to point
out that the proposal is put forward by people from organizations which
are huge users of GCC and know perfectly well the transition will be
painful and yet are prepared face it, for reasons that were nicely
explained by Florian.  AFAIK, we at SUSE share the sentiment.

[...]

> Regarding mechanics of the necessary opt out facility, Clang used
> -Werror=… by default, but that seems a bit hackish to me.  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).  Some build systems do not treat CFLAGS and CXXFLAGS as fully
> separate, and a flag approach that works for C and C++ without
> introducing any new warnings would be most convenient.  So maybe we
> could use -fpermissive for C as well.

I like -fpermissive, but the -Wno-error-... options are actually quite
intuitive, perhaps we could do both?  But I do not have a strong
preference.

> One fairly big GCC-internal task is to clear up the C test suite so that
> it passes with the new compiler defaults.  I already have an offer of
> help for that, so I think we can complete this work in a reasonable time
> frame.
>

So, a note to all users of cvise, creduce, delta etc.: Add appropriate
-Werror flags to your checking scripts so that we don't add more of this :-)

Thanks for putting effort into this.

Martin

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-09 18:22   ` Florian Weimer
@ 2023-05-11 21:32     ` Segher Boessenkool
  0 siblings, 0 replies; 24+ messages in thread
From: Segher Boessenkool @ 2023-05-11 21:32 UTC (permalink / raw)
  To: Florian Weimer; +Cc: David Edelsohn, gcc, c-std-porting

Hi Florian,

On Tue, May 09, 2023 at 08:22:44PM +0200, Florian Weimer via Gcc wrote:
> * alleged code generation bugs because the upper 32 bits of a pointer
>   are set to zero or 0xffffffff, resulting in crashes.  This can happen
>   if GCC synthesizes an implicit int declaration for a pointer-returning
>   function.
> 
> * Alleged code generation bugs because a function returning bool does
>   not set the entire register, as expected the caller.  This can happen
>   if GCC makes up a function declaration returning int for a function
>   that actually returns bool on x86-64.

Both of these cannot happen with better ABIs, by design.  Of course
every ABI has its own idiosyncrasies :-)

> I hope this makes things clearer.  I do think the current GCC defaults
> are needlessly frustrating, which is why I spent so much time on proving
> (from my perspective) that it should be feasible to change them.

Yes, I agree with this sentiment, and I think we can do a lot better
than we do now.

> We can get fairly close by injecting appropriate -Werror= options during

As you know, IMNSHO the only appropriate subset of -Werror= options is
the empty subset.

-Werror is for the user (the USER, not the build system) to ask "yes
please, I have all my priorities upside down, do fail compiling anything
that may look unexpected".  Most warnings are *heuristic*.  Other
warnings are for code that does not follow (modern) best practices.

But (most of) the diagnostics you propose to upgrade from warnings to
errors are not like this at all: they point out definite flaws, things
that just are not correct C code at all, and never were for that matter.
We always warn for those (without -Wall even) already, so upgrading
these to errors is a no-brainer really, as long as we also get
-fpermissive!


Segher

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-10 12:10                                     ` Neal Gompa
@ 2023-05-10 12:41                                       ` Eli Zaretskii
  0 siblings, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2023-05-10 12:41 UTC (permalink / raw)
  To: Neal Gompa
  Cc: sam, egall, jwakely.gcc, joel, dje.gcc, jakub, arsen, gcc, c-std-porting

> From: Neal Gompa <neal@gompa.dev>
> Date: Wed, 10 May 2023 08:10:48 -0400
> Cc: sam@gentoo.org, egall@gwmail.gwu.edu, jwakely.gcc@gmail.com, 
> 	joel@rtems.org, dje.gcc@gmail.com, jakub@redhat.com, arsen@aarsen.me, 
> 	gcc@gcc.gnu.org, c-std-porting@lists.linux.dev
> 
> On Wed, May 10, 2023 at 8:05 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Neal Gompa <neal@gompa.dev>
> > > Date: Wed, 10 May 2023 06:56:32 -0400
> > > Cc: Eric Gallager <egall@gwmail.gwu.edu>, Jonathan Wakely <jwakely.gcc@gmail.com>, joel@rtems.org,
> > >       David Edelsohn <dje.gcc@gmail.com>, Eli Zaretskii <eliz@gnu.org>, Jakub Jelinek <jakub@redhat.com>,
> > >       Arsen Arsenović <arsen@aarsen.me>, gcc@gcc.gnu.org,
> > >       c-std-porting@lists.linux.dev
> > >
> > > Right, we've been going through a similar effort with C++ over the
> > > past decade. GCC incrementally becoming more strict on C++ has been an
> > > incredibly painful experience, and it eats away a ton of time that I
> > > would have spent dealing with other problems. Having one big event
> > > where the majority of changes to make the C compiler strict happen
> > > will honestly make it less painful, even if it doesn't seem like it at
> > > the moment.
> >
> > But not having such an event, ever, would be even less painful.
> 
> That's not going to happen.

Well, I hope it will.  Otherwise I wouldn't be partaking in this
discussion.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-10 12:06                                   ` Eli Zaretskii
@ 2023-05-10 12:10                                     ` Neal Gompa
  2023-05-10 12:41                                       ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Neal Gompa @ 2023-05-10 12:10 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: sam, egall, jwakely.gcc, joel, dje.gcc, jakub, arsen, gcc, c-std-porting

On Wed, May 10, 2023 at 8:05 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Neal Gompa <neal@gompa.dev>
> > Date: Wed, 10 May 2023 06:56:32 -0400
> > Cc: Eric Gallager <egall@gwmail.gwu.edu>, Jonathan Wakely <jwakely.gcc@gmail.com>, joel@rtems.org,
> >       David Edelsohn <dje.gcc@gmail.com>, Eli Zaretskii <eliz@gnu.org>, Jakub Jelinek <jakub@redhat.com>,
> >       Arsen Arsenović <arsen@aarsen.me>, gcc@gcc.gnu.org,
> >       c-std-porting@lists.linux.dev
> >
> > On Wed, May 10, 2023 at 6:48 AM Sam James <sam@gentoo.org> wrote:
> > >
> > > Neal Gompa wasn't keen on the idea at
> > > https://lore.kernel.org/c-std-porting/CAEg-Je8=dQo-jAdu=Od5DH+h9AQzGE_4ghzgx_ow4RyJVPwFTg@mail.gmail.com/
> > > because it'd feel like essentially "repeated punches".
> > >
> > > Maybe it'd work with some tweaks: I would, however, be more open to GCC 14 having
> > > implicit-function-declaration,implicit-int (these are so closely related
> > > that it's not worth dividing the two up) and then say, GCC 15 having int-conversion and maybe
> > > incompatible-pointer-types. But spreading it out too much is likely counterproductive.
> >
> > Right, we've been going through a similar effort with C++ over the
> > past decade. GCC incrementally becoming more strict on C++ has been an
> > incredibly painful experience, and it eats away a ton of time that I
> > would have spent dealing with other problems. Having one big event
> > where the majority of changes to make the C compiler strict happen
> > will honestly make it less painful, even if it doesn't seem like it at
> > the moment.
>
> But not having such an event, ever, would be even less painful.

That's not going to happen. An event will eventually happen when GCC
and Clang switch their default C standard version. And making the
compilers stricter is something that has enough benefit to outweigh
the pain. The question is "how often" rather than "should we do it".



--
真実はいつも一つ!/ Always, there's only one truth!

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-10 10:56                                 ` Neal Gompa
@ 2023-05-10 12:06                                   ` Eli Zaretskii
  2023-05-10 12:10                                     ` Neal Gompa
  0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2023-05-10 12:06 UTC (permalink / raw)
  To: Neal Gompa
  Cc: sam, egall, jwakely.gcc, joel, dje.gcc, jakub, arsen, gcc, c-std-porting

> From: Neal Gompa <neal@gompa.dev>
> Date: Wed, 10 May 2023 06:56:32 -0400
> Cc: Eric Gallager <egall@gwmail.gwu.edu>, Jonathan Wakely <jwakely.gcc@gmail.com>, joel@rtems.org, 
> 	David Edelsohn <dje.gcc@gmail.com>, Eli Zaretskii <eliz@gnu.org>, Jakub Jelinek <jakub@redhat.com>, 
> 	Arsen Arsenović <arsen@aarsen.me>, gcc@gcc.gnu.org, 
> 	c-std-porting@lists.linux.dev
> 
> On Wed, May 10, 2023 at 6:48 AM Sam James <sam@gentoo.org> wrote:
> >
> > Neal Gompa wasn't keen on the idea at
> > https://lore.kernel.org/c-std-porting/CAEg-Je8=dQo-jAdu=Od5DH+h9AQzGE_4ghzgx_ow4RyJVPwFTg@mail.gmail.com/
> > because it'd feel like essentially "repeated punches".
> >
> > Maybe it'd work with some tweaks: I would, however, be more open to GCC 14 having
> > implicit-function-declaration,implicit-int (these are so closely related
> > that it's not worth dividing the two up) and then say, GCC 15 having int-conversion and maybe
> > incompatible-pointer-types. But spreading it out too much is likely counterproductive.
> 
> Right, we've been going through a similar effort with C++ over the
> past decade. GCC incrementally becoming more strict on C++ has been an
> incredibly painful experience, and it eats away a ton of time that I
> would have spent dealing with other problems. Having one big event
> where the majority of changes to make the C compiler strict happen
> will honestly make it less painful, even if it doesn't seem like it at
> the moment.

But not having such an event, ever, would be even less painful.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-10 10:45                               ` Sam James
@ 2023-05-10 10:56                                 ` Neal Gompa
  2023-05-10 12:06                                   ` Eli Zaretskii
  0 siblings, 1 reply; 24+ messages in thread
From: Neal Gompa @ 2023-05-10 10:56 UTC (permalink / raw)
  To: Sam James
  Cc: Eric Gallager, Jonathan Wakely, joel, David Edelsohn,
	Eli Zaretskii, Jakub Jelinek, Arsen Arsenović,
	gcc, c-std-porting

On Wed, May 10, 2023 at 6:48 AM Sam James <sam@gentoo.org> wrote:
>
>
> Eric Gallager via Gcc <gcc@gcc.gnu.org> writes:
>
> > On 5/9/23, Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:
> >> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
> >>> We are currently using gcc 12 and specifying C11.  To experiment with
> >>> these stricter warnings and slowly address them, would we need to build
> >>> with a newer C version?
> >>
> >> No, the proposed changes are to give errors (instead of warnings) for
> >> rules introduced in C99. GCC is just two decades late in enforcing the
> >> C99 rules properly!
> >>
> >>
> >>> What practices might the GCC community recommend to a project
> >>> wanting to discover the issues uncovered and slowly address them? I
> >>
> >> -Werror=implicit-int
> >> -Werror=implicit-function-declaration
> >> -Werror=int-conversion
> >>
> >
> > Idea for a compromise: What if, instead of flipping the switch on all
> > 3 of these at once, we staggered them so that each one becomes a
> > default in a separate release? i.e., something like:
> >
> > - GCC 14: -Werror=implicit-function-declaration gets added to the defaults
> > - GCC 15: -Werror=implicit-int gets added to the defaults
> > - GCC 16: -Werror=int-conversion gets added to the defaults
> >
> > That would give people more time to catch up on a particular warning,
> > rather than overwhelming them with a whole bunch all at once. Just an
> > idea.
>
> I think this might be more frustrating than not, althuogh I appreciate
> the intent.
>
> Neal Gompa wasn't keen on the idea at
> https://lore.kernel.org/c-std-porting/CAEg-Je8=dQo-jAdu=Od5DH+h9AQzGE_4ghzgx_ow4RyJVPwFTg@mail.gmail.com/
> because it'd feel like essentially "repeated punches".
>
> Maybe it'd work with some tweaks: I would, however, be more open to GCC 14 having
> implicit-function-declaration,implicit-int (these are so closely related
> that it's not worth dividing the two up) and then say, GCC 15 having int-conversion and maybe
> incompatible-pointer-types. But spreading it out too much is likely counterproductive.

Right, we've been going through a similar effort with C++ over the
past decade. GCC incrementally becoming more strict on C++ has been an
incredibly painful experience, and it eats away a ton of time that I
would have spent dealing with other problems. Having one big event
where the majority of changes to make the C compiler strict happen
will honestly make it less painful, even if it doesn't seem like it at
the moment.

This is because with as much C++ stuff we have in Linux distributions,
we have so much more C stuff.



--
真実はいつも一つ!/ Always, there's only one truth!

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
       [not found]                             ` <CAMfHzOsR=gY6QTss2R029Q-uMOTpC-RDV09bEF2FO7x5jpy5gg@mail.gmail.com>
@ 2023-05-10 10:45                               ` Sam James
  2023-05-10 10:56                                 ` Neal Gompa
  0 siblings, 1 reply; 24+ messages in thread
From: Sam James @ 2023-05-10 10:45 UTC (permalink / raw)
  To: Eric Gallager
  Cc: Jonathan Wakely, joel, David Edelsohn, Eli Zaretskii,
	Jakub Jelinek, Arsen Arsenović,
	gcc, c-std-porting, Neal Gompa

[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]


Eric Gallager via Gcc <gcc@gcc.gnu.org> writes:

> On 5/9/23, Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:
>> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
>>> We are currently using gcc 12 and specifying C11.  To experiment with
>>> these stricter warnings and slowly address them, would we need to build
>>> with a newer C version?
>>
>> No, the proposed changes are to give errors (instead of warnings) for
>> rules introduced in C99. GCC is just two decades late in enforcing the
>> C99 rules properly!
>>
>>
>>> What practices might the GCC community recommend to a project
>>> wanting to discover the issues uncovered and slowly address them? I
>>
>> -Werror=implicit-int
>> -Werror=implicit-function-declaration
>> -Werror=int-conversion
>>
>
> Idea for a compromise: What if, instead of flipping the switch on all
> 3 of these at once, we staggered them so that each one becomes a
> default in a separate release? i.e., something like:
>
> - GCC 14: -Werror=implicit-function-declaration gets added to the defaults
> - GCC 15: -Werror=implicit-int gets added to the defaults
> - GCC 16: -Werror=int-conversion gets added to the defaults
>
> That would give people more time to catch up on a particular warning,
> rather than overwhelming them with a whole bunch all at once. Just an
> idea.

I think this might be more frustrating than not, althuogh I appreciate
the intent.

Neal Gompa wasn't keen on the idea at
https://lore.kernel.org/c-std-porting/CAEg-Je8=dQo-jAdu=Od5DH+h9AQzGE_4ghzgx_ow4RyJVPwFTg@mail.gmail.com/
because it'd feel like essentially "repeated punches".

Maybe it'd work with some tweaks: I would, however, be more open to GCC 14 having
implicit-function-declaration,implicit-int (these are so closely related
that it's not worth dividing the two up) and then say, GCC 15 having int-conversion and maybe
incompatible-pointer-types. But spreading it out too much is likely counterproductive.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
       [not found] ` <CAGWvnykoEtT0BQtuN70DN6tWohtf=Mm7SW55psZvVmj3OvKUEg@mail.gmail.com>
  2023-05-09 15:07   ` Sam James
  2023-05-09 15:14   ` Jonathan Wakely
@ 2023-05-09 18:22   ` Florian Weimer
  2023-05-11 21:32     ` Segher Boessenkool
  2 siblings, 1 reply; 24+ messages in thread
From: Florian Weimer @ 2023-05-09 18:22 UTC (permalink / raw)
  To: David Edelsohn; +Cc: gcc, c-std-porting

* David Edelsohn:

> Yes, GCC has two, distinct user groups / use cases, but GCC also has a
> very unique and crucial role, as the foundation for a large portion of
> the GNU/Linux and FOSS software ecosystem.  This proposal is missing a
> motivation for this change, especially making new errors the default.

I tried to explain that in my introductory comments, but perhaps that
was a bit too abstract.

Here are some examples of the stuff I personally deal with in this space
on a semi-regular basis.

* alleged code generation bugs because the upper 32 bits of a pointer
  are set to zero or 0xffffffff, resulting in crashes.  This can happen
  if GCC synthesizes an implicit int declaration for a pointer-returning
  function.

* Alleged code generation bugs because a function returning bool does
  not set the entire register, as expected the caller.  This can happen
  if GCC makes up a function declaration returning int for a function
  that actually returns bool on x86-64.

* Making source-only API transitions away from a particular function is
  surprisingly hard if you still want to provide binary compatibility,
  and not put ugliness like

    #define function_api_v1(arg0, arg1, arg2) \
      DO NOT CALL THIS, USE function_api_v2 instead

  into installed header files (or rely on GCC extensions such as the
  poison pragma).

* Incomplete ports of C extensions to newer Python and Ruby versions
  which still compile and link, but fail at some point during run time
  because they try to call functions that do not exist.  (BIND_NOW
  mitigates that to some extend, but that's mostly a downstream thing.)

These are just a subset of the issues that are escalated to me, and I
don't even work on the compiler for real.  I don't know how much of that
ends up with the real compiler developers, or in how many cases
programmers eventually debug the issue on their own, finally spot the
warning in the build log, and make the connection.

Nowadays I ask for full build logs before I look at anything else, and
given the way we build our applications, we usually have that, so that
is a convenient shortcut.  (For others, it will be buried in some IDE,
and all you can get from them are screenshots.)  But if application
developers poked at the problem with GDB to the point that they can
share disassembly they think that shows a compiler bug, they must have
spent quite some time on it.  If GCC had different defaults, they
wouldn't have to do that, increasing their productivity.

I hope this makes things clearer.  I do think the current GCC defaults
are needlessly frustrating, which is why I spent so much time on proving
(from my perspective) that it should be feasible to change them.

> GCC needs to be proactive, not reactive, without annoying and
> frustrating its user base.  Clang has been making some aggressive
> changes in warnings, but its constituency expects that.  Developers
> who want that experience already will use Clang, so why annoy
> developers who prefer the GCC experience and behavior?

I really would like to keep GCC as the system compiler, but avoid the
hidden costs of the current GCC defaults.

We can get fairly close by injecting appropriate -Werror= options during
the distribution build.  On the other hand, we are already up to about
fifteen recommended compiler flags.  We are looking at adding between
two and four additional -Werror= flags for this.  The optics aren't
great.  In our case, ISVs who do not do RPM builds would have to
replicate and maintain this flag list in their own build environments
because they wouldn't benefit from the distribution default flags.  I'm
worried all this looks rather unprofessional.

> The new warnings and errors help some developers and improve software
> security, but also drive some developers away, or at least cause them
> to reass their choice of toolchain.

That goes in the other direction as well, I think.  Developers are
pressured to use languages which are generally perceived to offer more
type safety.  Here we have a few cases where we could increase the type
safety of C, without having to switch to a completely different
language.

I don't think C is as static as used to be, by the way.  C2X (and glibc
before that, especially with _GNU_SOURCE) is adding lots of widely-used
identifiers to existing headers, so that will cause some breakage, too.
The C2X changes seem to conflict with keeping GCC as the 90s C compiler
(at least by default).

And g++ regularly fixes language and header conformance issues as bugs,
not treating them as perpetually supported extensions.  The resulting
churn does not seem to have hurt adoption of C++ or g++.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-09 17:07     ` Sam James
@ 2023-05-09 17:35       ` Florian Weimer
  0 siblings, 0 replies; 24+ messages in thread
From: Florian Weimer @ 2023-05-09 17:35 UTC (permalink / raw)
  To: Sam James; +Cc: Richard Biener, gcc, c-std-porting

* Sam James:

> Florian Weimer <fweimer@redhat.com> writes:
>
>> * Richard Biener:
>>
>>>> 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-?
>>
>> That's what Clang does (and the defaults chang along with -std=
>> settings). To me, -Werror by default for some warnings seems rather
>> hackish.  But that's just my personal preference, I do not have a strong
>> objection to doing it that way.
>
> Not that we have to follow Clang, but deviating by adding -fpermissive
> (which is a GCC-only flag) for C may not be desirable, and following
> Clang would let people use the same method for silencing known-bad
> codebases for now.

I think Clang already accepts -fpermissive, so it's not *too* bad?
(Presumably it just ignores it.)

>> One downside with -Wno- is that some developers jump on this rather
>> quickly instead of fixing the real problem.  So far, I've seen this in
>> both Chromium and the kernel, in fringe areas admittedly, but still.
>> The advantage is that there is a familiar workaround to get things
>> compiling quickly again, of course.
>
> I've not seen very much of this so far, FWIW. Only for the more annoying
> C23 warnings which have well-documented problems (and unrelated to this,
> so I won't go on about it anymore).

I think this could be a side effect of our different testing strategies.
The kernel -Wno-implicit-function-declaration change looks like it was
specifically added to build with Clang 15/16.

> But -fpermissive does have a nice property in that it's immediately
> obvious you're doing something *terrible* if you use it.

Right.

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

Hmm, maybe I've seen this as well but attributed it to whitespace.
The -std=gnu89 approach would run into problems with this, too.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-09 16:59   ` Florian Weimer
@ 2023-05-09 17:07     ` Sam James
  2023-05-09 17:35       ` Florian Weimer
  0 siblings, 1 reply; 24+ messages in thread
From: Sam James @ 2023-05-09 17:07 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Richard Biener, gcc, c-std-porting

[-- Attachment #1: Type: text/plain, Size: 2541 bytes --]


Florian Weimer <fweimer@redhat.com> writes:

> * Richard Biener:
>
>>> 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-?
>
> That's what Clang does (and the defaults chang along with -std=
> settings). To me, -Werror by default for some warnings seems rather
> hackish.  But that's just my personal preference, I do not have a strong
> objection to doing it that way.

Not that we have to follow Clang, but deviating by adding -fpermissive
(which is a GCC-only flag) for C may not be desirable, and following
Clang would let people use the same method for silencing known-bad
codebases for now.

>
> One downside with -Wno- is that some developers jump on this rather
> quickly instead of fixing the real problem.  So far, I've seen this in
> both Chromium and the kernel, in fringe areas admittedly, but still.
> The advantage is that there is a familiar workaround to get things
> compiling quickly again, of course.
>

I've not seen very much of this so far, FWIW. Only for the more annoying
C23 warnings which have well-documented problems (and unrelated to this,
so I won't go on about it anymore).

But -fpermissive does have a nice property in that it's immediately
obvious you're doing something *terrible* if you use it.

>> I think instead of hard-coding a set of changes would it be possible
>> to alter the default setting of diagnostic options during GCC
>> configuration?  And maybe even note that when diagnosing?
>
> I'd be worried about our package maintainers if we do something like
> that.  We'd like them to report build failures upstream, and if it's
> just one or two distributions doing that and not GCC upstream, well, I
> guess we just got a preview of how some upstreams are going to react.
> Package maintainers tend to be volunteer or junior engineering roles, I
> think, so this doesn't seem fair to me.

Yeah, this is one of those things where we need it happening in CI for
people and at the point of development.

(Such an option might be nice in general, but not for this if its
default didn't include these warnings or if distributions were likely
to override it to something weaker.)

thanks,
sam


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-09 15:16 ` Richard Biener
  2023-05-09 16:05   ` Jakub Jelinek
@ 2023-05-09 16:59   ` Florian Weimer
  2023-05-09 17:07     ` Sam James
  1 sibling, 1 reply; 24+ messages in thread
From: Florian Weimer @ 2023-05-09 16:59 UTC (permalink / raw)
  To: Richard Biener; +Cc: gcc, c-std-porting

* Richard Biener:

>> 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-?

That's what Clang does (and the defaults chang along with -std=
settings). To me, -Werror by default for some warnings seems rather
hackish.  But that's just my personal preference, I do not have a strong
objection to doing it that way.

One downside with -Wno- is that some developers jump on this rather
quickly instead of fixing the real problem.  So far, I've seen this in
both Chromium and the kernel, in fringe areas admittedly, but still.
The advantage is that there is a familiar workaround to get things
compiling quickly again, of course.

> I think instead of hard-coding a set of changes would it be possible
> to alter the default setting of diagnostic options during GCC
> configuration?  And maybe even note that when diagnosing?

I'd be worried about our package maintainers if we do something like
that.  We'd like them to report build failures upstream, and if it's
just one or two distributions doing that and not GCC upstream, well, I
guess we just got a preview of how some upstreams are going to react.
Package maintainers tend to be volunteer or junior engineering roles, I
think, so this doesn't seem fair to me.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-09 16:05   ` Jakub Jelinek
@ 2023-05-09 16:11     ` Sam James
  0 siblings, 0 replies; 24+ messages in thread
From: Sam James @ 2023-05-09 16:11 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Richard Biener, Florian Weimer, gcc, c-std-porting

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]


Jakub Jelinek <jakub@redhat.com> writes:

> 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?

This is what we've been doing for hopeless projects and it's probably my
preference, but I'm fine with Florian's -fpermissive suggestion too.

(The point about inline semantics is important but you can handle that
with other flags anyway.)

best,
sam


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-09 15:16 ` Richard Biener
@ 2023-05-09 16:05   ` Jakub Jelinek
  2023-05-09 16:11     ` Sam James
  2023-05-09 16:59   ` Florian Weimer
  1 sibling, 1 reply; 24+ messages in thread
From: Jakub Jelinek @ 2023-05-09 16:05 UTC (permalink / raw)
  To: Richard Biener; +Cc: Florian Weimer, gcc, c-std-porting

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?

	Jakub


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
  2023-05-09 12:15 Florian Weimer
@ 2023-05-09 15:16 ` Richard Biener
  2023-05-09 16:05   ` Jakub Jelinek
  2023-05-09 16:59   ` Florian Weimer
       [not found] ` <CAGWvnykoEtT0BQtuN70DN6tWohtf=Mm7SW55psZvVmj3OvKUEg@mail.gmail.com>
  2023-05-12  9:33 ` Martin Jambor
  2 siblings, 2 replies; 24+ messages in thread
From: Richard Biener @ 2023-05-09 15:16 UTC (permalink / raw)
  To: Florian Weimer; +Cc: gcc, c-std-porting



> 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-?

I think instead of hard-coding a set of changes would it be possible to alter the default setting of diagnostic options during GCC configuration?  And maybe even note that when diagnosing?

Thanks,
Richard 

> A few of you might remember that I've been looking into turning some
> type errors from warnings into errors by default.  Mainly I've been
> looking at implicit function declarations because in too many cases, the
> synthesized declaration does not match the prototype used at function
> definition and can cause subtle ABI issues.
> 
> To recap, the main challenge is that GCC has to serve disparate groups
> of users: some use GCC for writing programs themselves, but others just
> need GCC to build sources that they have obtained from somewhere.  The
> first group benefits from more type errors because they catch errors
> earlier during development (experience shows that compiler warnings are
> easy to miss in a long build log).  The second group might find these
> errors challenging because the sources they have no longer build.
> 
> To see how large the impact is on that second group, we've mostly
> removed implicit function declarations and implicit ints from Fedora:
> 
>  <https://fedoraproject.org/wiki/Changes/PortingToModernC>
>  <https://fedoraproject.org/wiki/Toolchain/PortingToModernC>
> 
> Roughly 870 packages out of ~14,500 that have GCC present during the
> build needed fixing (or flagging that they can't be built with the
> additional errors), so 6%.  Most of the changes are mechanical in
> nature, like adding additional headers to configure checks.  For about
> ~150 packages, automated patching could be used to rewrite problematic
> built-in checks generated by long-obsolete autoconf versions.
> 
> Some of these changes prevent the compiler behavior for altering the
> build results silently because the new errors changed the outcome of
> autoconf checks.  (We had one of those in libstdc++, changing the ABI on
> GNU/Linux because futex support oculd no longer be detected.)
> Unfortunately, I did not record numbers about them, but think those were
> quite rare; most autoconf problems were also accompanied with other
> problems, or the incorrect results from autoconf led to build failures
> later.  So it seems to me that the risk that the second group mentioned
> above would silently get unexpected build results is fairly low.
> 
> Where possible, we tried to upstream patches, to simplify sharing across
> distributions and to help those who compile upstream sources directly.
> We also benefited from other distributions upstreaming changes along
> similar lines (notably Gentoo for their Clang 16 project, but also from
> Homebrew to a lesser extent).
> 
> An area we started exploring only recently for Fedora is implicit
> conversions between integers and pointers (covered by -Wint-conversion).
> These add another ~170 packages, but some of those are false positives
> (due to our instrumented compiler approach) that do not change the build
> outcome at all.  I'm still negotiating whether we have the capacity to
> develop fixes for these packages proactively.
> 
> I brought up the matter with distributions, and the feedback was neutral
> (not overly negative, as in “this would be the end of the world for
> us”).
> 
>  <https://discourse.nixos.org/t/rfc-more-c-errors-by-default-in-gcc-14/27390>
>  <https://lists.debian.org/debian-gcc/2023/04/msg00015.html>
>  <https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/5OL76NH5AX75WOTZ43O3ZF2JOS3ABBXL/#QZLCA5YPN5CWSS7BCC6TNBC6N7RFTW7J>
> 
> (I tried to contact Arch, but my message didn't make it past the
> moderators, it seems.)
> 
> All in all, the whole situation is not great, but it still seems
> manageable to me.
> 
> Anyway, thanks for reading this far.
> 
> I would like to suggest to turn implicit-int,
> implicit-function-declaration, and possibly int-conversion from warnings
> into errors for GCC 14.  This would give upstream projects roughly
> another year to make new releases with compatibility fixes that have
> been contributed so far.  I do not think waiting longer, until GCC 15,
> would make a meaningful difference because any upstream project that
> does not release within the next 12 months is not likely to release in
> the next 24 months, either.
> 
> Regarding mechanics of the necessary opt out facility, Clang used
> -Werror=… by default, but that seems a bit hackish to me.  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).  Some build systems do not treat CFLAGS and CXXFLAGS as fully
> separate, and a flag approach that works for C and C++ without
> introducing any new warnings would be most convenient.  So maybe we
> could use -fpermissive for C as well.
> 
> One fairly big GCC-internal task is to clear up the C test suite so that
> it passes with the new compiler defaults.  I already have an offer of
> help for that, so I think we can complete this work in a reasonable time
> frame.
> 
> I have no data how big the compatibility impact of turning
> incompatible-pointer-types into errors will be.  For now, int-conversion
> has higher priority.  However, it looks like another change that could
> benefit developers (the first group).
> 
> I do not plan to work specifically on C2X compatibility fixes for now
> (to support bool-as-keyword, for example), but I could imagine a similar
> project a few years from now, fewer than 25 hopefully, that would enable
> GCC to make the switch to C2X by default.
> 
> Thanks,
> Florian
> 

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
       [not found] ` <CAGWvnykoEtT0BQtuN70DN6tWohtf=Mm7SW55psZvVmj3OvKUEg@mail.gmail.com>
  2023-05-09 15:07   ` Sam James
@ 2023-05-09 15:14   ` Jonathan Wakely
       [not found]     ` <20230509102201.6aa2a7d14fdb2f1e7abff449@killthe.net>
  2023-05-09 18:22   ` Florian Weimer
  2 siblings, 1 reply; 24+ messages in thread
From: Jonathan Wakely @ 2023-05-09 15:14 UTC (permalink / raw)
  To: David Edelsohn; +Cc: Florian Weimer, gcc, c-std-porting

On Tue, 9 May 2023 at 16:04, David Edelsohn via Gcc <gcc@gcc.gnu.org> wrote:
> Yes, GCC has two, distinct user groups / use cases, but GCC also has a very
> unique and crucial role, as the foundation for a large portion of the
> GNU/Linux and FOSS software ecosystem.  This proposal is missing a
> motivation for this change, especially making new errors the default.
>
> GCC needs to be proactive, not reactive, without annoying and frustrating
> its user base.  Clang has been making some aggressive changes in warnings,
> but its constituency expects that.  Developers who want that experience
> already will use Clang, so why annoy developers who prefer the GCC
> experience and behavior?  The new warnings and errors help some developers
> and improve software security, but also drive some developers away, or at
> least cause them to reass their choice of toolchain.
>
> Maybe we need additional front-end aliases "gcclang" and "gcclang++" for
> GCC to provide an experience more like Clang for those who desire that.
> GCC isn't Clang and I fear that GCC is going down a path that annoys and
> frustrates both user groups -- it's not sufficiently aggressive for those
> who prefer Clang and it's too aggressive for those who wish backward
> compatibility.

This isn't "be like Clang", this is "diagnose things that have been
invalid C since 1999".

Accepting invalid code by default is a disservice to users. Those who
need to compile invalid C code can use an extra option to allow it,
the default should be to tell users their code is doing something bad.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: More C type errors by default for GCC 14
       [not found] ` <CAGWvnykoEtT0BQtuN70DN6tWohtf=Mm7SW55psZvVmj3OvKUEg@mail.gmail.com>
@ 2023-05-09 15:07   ` Sam James
  2023-05-09 15:14   ` Jonathan Wakely
  2023-05-09 18:22   ` Florian Weimer
  2 siblings, 0 replies; 24+ messages in thread
From: Sam James @ 2023-05-09 15:07 UTC (permalink / raw)
  To: David Edelsohn; +Cc: Florian Weimer, c-std-porting, gcc

[-- Attachment #1: Type: text/plain, Size: 3745 bytes --]


David Edelsohn via Gcc <gcc@gcc.gnu.org> writes:

> On Tue, May 9, 2023 at 8:16 AM Florian Weimer via Gcc <gcc@gcc.gnu.org>
> wrote:
>
>> TL;DR: This message is about turning implicit-int,
>> implicit-function-declaration, and possibly int-conversion into errors
>> for GCC 14.
>>
>> A few of you might remember that I've been looking into turning some
>> type errors from warnings into errors by default.  Mainly I've been
>> looking at implicit function declarations because in too many cases, the
>> synthesized declaration does not match the prototype used at function
>> definition and can cause subtle ABI issues.
>>
>> To recap, the main challenge is that GCC has to serve disparate groups
>> of users: some use GCC for writing programs themselves, but others just
>> need GCC to build sources that they have obtained from somewhere.  The
>> first group benefits from more type errors because they catch errors
>> earlier during development (experience shows that compiler warnings are
>> easy to miss in a long build log).  The second group might find these
>> errors challenging because the sources they have no longer build.
>>
>
> Hi, Florian
>
> Thanks for working on this and proposing this.
>
> Yes, GCC has two, distinct user groups / use cases, but GCC also has a very
> unique and crucial role, as the foundation for a large portion of the
> GNU/Linux and FOSS software ecosystem.  This proposal is missing a
> motivation for this change, especially making new errors the default.

Florian did note this already - ABI. Implicit function declarations are
pretty horrible in a number of cases:
- they prevent fortification (_FORTIFY_SOURCE)
- they prevent time64 and LFS migrations from working correctly
- they break with different ABIs (see e.g. Apple's arm64 ABI)
- they can cause runtime crashes when combined wtih bfd's default of
not warning on underlinking

int-conversion generally indicates severe runtime problems as well. Many
of the cases I've seen on musl absolutely do not work at runtime and
weren't caught by any other warnings (often because of padding mismatches).

>
> GCC needs to be proactive, not reactive, without annoying and frustrating
> its user base.

That's why Fedora and Gentoo have been aggressively working on this
before even proposing it. We are being proactive in making sure that
common things are fixed.

> Clang has been making some aggressive changes in warnings,
> but its constituency expects that.  Developers who want that experience
> already will use Clang, so why annoy developers who prefer the GCC
> experience and behavior?  The new warnings and errors help some developers
> and improve software security, but also drive some developers away, or at
> least cause them to reass their choice of toolchain.

I don't know if it's that aggressive to drop something which was
removed in C99 because of how dangerous it is.

Also, keep in mind, Florian went around and asked many of the first
group (the foundational folks) who didn't object.

Not that this is a strong argument, and I don't like making it, but
if Clang is doing it and GCC does too, it's not like they can reassess
their choices anyway.

>
> Maybe we need additional front-end aliases "gcclang" and "gcclang++" for
> GCC to provide an experience more like Clang for those who desire that.
> GCC isn't Clang and I fear that GCC is going down a path that annoys and
> frustrates both user groups -- it's not sufficiently aggressive for those
> who prefer Clang and it's too aggressive for those who wish backward
> compatibility.

Sounds similar (although a bit different) to the
https://gcc.gnu.org/wiki/boringcc idea.

thanks,
sam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* More C type errors by default for GCC 14
@ 2023-05-09 12:15 Florian Weimer
  2023-05-09 15:16 ` Richard Biener
                   ` (2 more replies)
  0 siblings, 3 replies; 24+ messages in thread
From: Florian Weimer @ 2023-05-09 12:15 UTC (permalink / raw)
  To: gcc; +Cc: c-std-porting

TL;DR: This message is about turning implicit-int,
implicit-function-declaration, and possibly int-conversion into errors
for GCC 14.

A few of you might remember that I've been looking into turning some
type errors from warnings into errors by default.  Mainly I've been
looking at implicit function declarations because in too many cases, the
synthesized declaration does not match the prototype used at function
definition and can cause subtle ABI issues.

To recap, the main challenge is that GCC has to serve disparate groups
of users: some use GCC for writing programs themselves, but others just
need GCC to build sources that they have obtained from somewhere.  The
first group benefits from more type errors because they catch errors
earlier during development (experience shows that compiler warnings are
easy to miss in a long build log).  The second group might find these
errors challenging because the sources they have no longer build.

To see how large the impact is on that second group, we've mostly
removed implicit function declarations and implicit ints from Fedora:

  <https://fedoraproject.org/wiki/Changes/PortingToModernC>
  <https://fedoraproject.org/wiki/Toolchain/PortingToModernC>

Roughly 870 packages out of ~14,500 that have GCC present during the
build needed fixing (or flagging that they can't be built with the
additional errors), so 6%.  Most of the changes are mechanical in
nature, like adding additional headers to configure checks.  For about
~150 packages, automated patching could be used to rewrite problematic
built-in checks generated by long-obsolete autoconf versions.

Some of these changes prevent the compiler behavior for altering the
build results silently because the new errors changed the outcome of
autoconf checks.  (We had one of those in libstdc++, changing the ABI on
GNU/Linux because futex support oculd no longer be detected.)
Unfortunately, I did not record numbers about them, but think those were
quite rare; most autoconf problems were also accompanied with other
problems, or the incorrect results from autoconf led to build failures
later.  So it seems to me that the risk that the second group mentioned
above would silently get unexpected build results is fairly low.

Where possible, we tried to upstream patches, to simplify sharing across
distributions and to help those who compile upstream sources directly.
We also benefited from other distributions upstreaming changes along
similar lines (notably Gentoo for their Clang 16 project, but also from
Homebrew to a lesser extent).

An area we started exploring only recently for Fedora is implicit
conversions between integers and pointers (covered by -Wint-conversion).
These add another ~170 packages, but some of those are false positives
(due to our instrumented compiler approach) that do not change the build
outcome at all.  I'm still negotiating whether we have the capacity to
develop fixes for these packages proactively.

I brought up the matter with distributions, and the feedback was neutral
(not overly negative, as in “this would be the end of the world for
us”).

  <https://discourse.nixos.org/t/rfc-more-c-errors-by-default-in-gcc-14/27390>
  <https://lists.debian.org/debian-gcc/2023/04/msg00015.html>
  <https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/5OL76NH5AX75WOTZ43O3ZF2JOS3ABBXL/#QZLCA5YPN5CWSS7BCC6TNBC6N7RFTW7J>

(I tried to contact Arch, but my message didn't make it past the
moderators, it seems.)

All in all, the whole situation is not great, but it still seems
manageable to me.

Anyway, thanks for reading this far.

I would like to suggest to turn implicit-int,
implicit-function-declaration, and possibly int-conversion from warnings
into errors for GCC 14.  This would give upstream projects roughly
another year to make new releases with compatibility fixes that have
been contributed so far.  I do not think waiting longer, until GCC 15,
would make a meaningful difference because any upstream project that
does not release within the next 12 months is not likely to release in
the next 24 months, either.

Regarding mechanics of the necessary opt out facility, Clang used
-Werror=… by default, but that seems a bit hackish to me.  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).  Some build systems do not treat CFLAGS and CXXFLAGS as fully
separate, and a flag approach that works for C and C++ without
introducing any new warnings would be most convenient.  So maybe we
could use -fpermissive for C as well.

One fairly big GCC-internal task is to clear up the C test suite so that
it passes with the new compiler defaults.  I already have an offer of
help for that, so I think we can complete this work in a reasonable time
frame.

I have no data how big the compatibility impact of turning
incompatible-pointer-types into errors will be.  For now, int-conversion
has higher priority.  However, it looks like another change that could
benefit developers (the first group).

I do not plan to work specifically on C2X compatibility fixes for now
(to support bool-as-keyword, for example), but I could imagine a similar
project a few years from now, fewer than 25 hopefully, that would enable
GCC to make the switch to C2X by default.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2023-05-15 13:14 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CAGWvnynMpa83AduLhRhf1PxkVujngDmmwE7Z4vk1z6+UqqAuKA@mail.gmail.com>
     [not found] ` <BBE9950C-28AA-4A1C-A4C5-7F486538004E@gmail.com>
2023-05-09 16:44   ` More C type errors by default for GCC 14 Florian Weimer
2023-05-09 16:58     ` Ian Lance Taylor
2023-05-09 17:08     ` Jason Merrill
2023-05-09 17:16       ` Sam James
2023-05-09 12:15 Florian Weimer
2023-05-09 15:16 ` Richard Biener
2023-05-09 16:05   ` Jakub Jelinek
2023-05-09 16:11     ` Sam James
2023-05-09 16:59   ` Florian Weimer
2023-05-09 17:07     ` Sam James
2023-05-09 17:35       ` Florian Weimer
     [not found] ` <CAGWvnykoEtT0BQtuN70DN6tWohtf=Mm7SW55psZvVmj3OvKUEg@mail.gmail.com>
2023-05-09 15:07   ` Sam James
2023-05-09 15:14   ` Jonathan Wakely
     [not found]     ` <20230509102201.6aa2a7d14fdb2f1e7abff449@killthe.net>
     [not found]       ` <87r0rp5uf8.fsf@aarsen.me>
     [not found]         ` <83ttwla1ep.fsf@gnu.org>
     [not found]           ` <CAH6eHdS-7USHzX3rPJaR66sEdjG+-nHp7mDb0gD7ceBnp+Fmpg@mail.gmail.com>
     [not found]             ` <83lehx9vix.fsf@gnu.org>
     [not found]               ` <ZFqZ25xKm4w4IkqF@tucnak>
     [not found]                 ` <83fs859unu.fsf@gnu.org>
     [not found]                   ` <CAGWvny=xi++Ghyo2Ez5MJdYy5h3yH16gVpviKC99Ufu_bUmdYQ@mail.gmail.com>
     [not found]                     ` <CAH6eHdRAVwBcCmBgiuPyQNWGx3x33diAgQU8UG3s_NrJxK3ucQ@mail.gmail.com>
     [not found]                       ` <CAGWvnyk_MkQOrNNh1C=ubPj8qzg5x-p8CBfgWNqqtDVJ1mbhMg@mail.gmail.com>
     [not found]                         ` <CAF9ehCWsq-N9+U1+mTQahKT7cXEqLTptLb=b3Yq58gsWFEnxgA@mail.gmail.com>
     [not found]                           ` <CAH6eHdS_sQ37VTpJHL7cqtgSdCSL3i4=tqMoY65wep9G56cf5g@mail.gmail.com>
     [not found]                             ` <CAMfHzOsR=gY6QTss2R029Q-uMOTpC-RDV09bEF2FO7x5jpy5gg@mail.gmail.com>
2023-05-10 10:45                               ` Sam James
2023-05-10 10:56                                 ` Neal Gompa
2023-05-10 12:06                                   ` Eli Zaretskii
2023-05-10 12:10                                     ` Neal Gompa
2023-05-10 12:41                                       ` Eli Zaretskii
2023-05-09 18:22   ` Florian Weimer
2023-05-11 21:32     ` Segher Boessenkool
2023-05-12  9:33 ` Martin Jambor
2023-05-12 12:30   ` Jakub Jelinek
2023-05-15 12:46     ` Michael Matz
2023-05-15 13:14     ` Richard Earnshaw (lists)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).