Re: More C type errors by default for GCC 14

[Jakub Jelinek <jakub@redhat.com>]

On Wed, May 10, 2023 at 05:14:43PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 10 May 2023 14:41:27 +0200
> > Cc: jwakely.gcc@gmail.com, fweimer@redhat.com, gcc@gcc.gnu.org,
> >  arsen@aarsen.me
> > From: Gabriel Ravier <gabravier@gmail.com>
> > 
> > >>> Because GCC is capable of compiling it.
> > >> That is not a good argument.  GCC is capable of compiling any code in all
> > >> the reported accepts-invalid bugs on which it doesn't ICE.  That doesn't
> > >> mean those bugs shouldn't be fixed.
> > > Fixing those bugs, if they are bugs, is not the job of the compiler.
> > > It's the job of the programmer, who is the one that knows what the
> > > code was supposed to do.  If there's a significant risk that the code
> > > is a mistake or might behave in problematic ways, a warning to that
> > > effect is more than enough.
> > 
> > Are you seriously saying that no accepts-invalid bug should ever be 
> > fixed under any circumstances on the basis that some programmers might 
> > rely on code exploiting that bug ??
> 
> Sorry, I'm afraid I don't understand the question.  What are
> "accepts-invalid bugs"?

They are bugs where compiler accepts something that isn't valid in
the selected language nor considered valid extension.
So, after the fix we reject something that has been accepted before.

In the last few years (checked what was fixed in 10/11/12/13 releases so
far), we've fixed 12 such bugs explicitly marked that way:
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&component=c&keywords=accepts-invalid&keywords_type=allwords&list_id=382024&query_format=advanced&resolution=FIXED&target_milestone=10.0&target_milestone=10.2&target_milestone=10.3&target_milestone=10.4&target_milestone=10.5&target_milestone=11.0&target_milestone=11.2&target_milestone=11.3&target_milestone=11.4&target_milestone=11.5&target_milestone=12.0&target_milestone=12.2&target_milestone=12.3&target_milestone=12.4&target_milestone=12.5&target_milestone=13.0
82 such bugs in C++:
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&component=c%2B%2B&keywords=accepts-invalid&keywords_type=allwords&list_id=382025&query_format=advanced&resolution=FIXED&target_milestone=10.0&target_milestone=10.2&target_milestone=10.3&target_milestone=10.4&target_milestone=10.5&target_milestone=11.0&target_milestone=11.2&target_milestone=11.3&target_milestone=11.4&target_milestone=11.5&target_milestone=12.0&target_milestone=12.2&target_milestone=12.3&target_milestone=12.4&target_milestone=12.5&target_milestone=13.0
and a couple in other languages.

E.g. today I've committed a C++ FE fix, where we erroneously accepted
e.g.
template <int ...args>
[[noreturn...]]
int foo ();
and handled it as if the ... after the attribute wasn't present.
In this case also you were able to compile such code in the past GCC
versions and it will not compile in G++ 14.1 anymore.

What we are talking in this thread is also something not valid in C99 or
later, for the int-conversion stuff not even valid in C89, in the past
accepted just for K&R legacy reasons.

	Jakub