Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Wed, 10 May 2023, 03:32 Eli Zaretskii,  wrote:

>
> And then people will start complaining about GCC unnecessarily
> erroring out, which is a compiler bug, since there's no problem
> producing correct code in these cases.
>


What is the correct code for this?

void foo(int);
void bar() { foo("42"); }

Why should this compile?

You keep demanding better rationale for the change, but your argument
amounts to nothing more than "it compiles today, it should compile
tomorrow".

>

Tags not allowed in user repository - Mildly urgent

[Ondřej Kubánek via Gcc]

Hello,

I have tried to push a tag to my user space /tags/ ref in the GCC repo. The
tag is annotated but the push was rejected. Here is the command

git push origin master:refs/users/kubaneko/tags/Thesis Thesis

and here is the response

Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote: *** Lightweight tags ('kubaneko/tags/Thesis' in namespace
'refs/users') are not allowed in this repository.
remote: *** Use 'git tag [ -a | -s ]' for tags you want to propagate.
remote: error: hook declined to update refs/users/kubaneko/tags/Thesis
To git+ssh://gcc.gnu.org/git/gcc.git
 ! [remote rejected] master -> refs/users/kubaneko/tags/Thesis
(hook declined)
error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git'

Is this expected behaviour? Do I need a gpg key to sign the tag?

Thank you for the help

Ondřej Kubánek

Re: More C type errors by default for GCC 14

[Richard Biener via Gcc]

On Wed, May 10, 2023 at 10:05 AM Jonathan Wakely via Gcc
 wrote:
>
> On Wed, 10 May 2023, 03:32 Eli Zaretskii,  wrote:
>
> >
> > And then people will start complaining about GCC unnecessarily
> > erroring out, which is a compiler bug, since there's no problem
> > producing correct code in these cases.
> >
>
>
> What is the correct code for this?
>
> void foo(int);
> void bar() { foo("42"); }
>
> Why should this compile?
>
> You keep demanding better rationale for the change, but your argument
> amounts to nothing more than "it compiles today, it should compile
> tomorrow".

void foo(__UINTPTR_TYPE__);
void bar() { foo("42"); }

might be something we'd still like to diagnose but eventually not turn
into an error?  Yes, it then depends on the target whether the code is
accepted or not, but at least it would continue working where there's
a "good" answer to your question.

Probably splitting hairs here ..

Richard.
>
> >

Re: More C type errors by default for GCC 14

[David Brown via Gcc]

On 09/05/2023 21:04, Eli Zaretskii via Gcc wrote:

From: Jonathan Wakely 
Date: Tue, 9 May 2023 18:15:59 +0100
Cc: Arsen Arsenović , gcc@gcc.gnu.org

On Tue, 9 May 2023 at 17:56, Eli Zaretskii wrote:


No one has yet explained why a warning about this is not enough, and
why it must be made an error.  Florian's initial post doesn't explain
that, and none of the followups did, although questions about whether
a warning is not already sufficient were asked.

That's a simple question, and unless answered with valid arguments,
the proposal cannot make sense to me, at least.


People ignore warnings. That's why the problems have gone unfixed for
so many years, and will continue to go unfixed if invalid code keeps
compiling.


People who ignore warnings will use options that disable these new
errors, exactly as they disable warnings.  So we will end up not
reaching the goal, but instead harming those who are well aware of the
warnings.



My experience is that many of the people who ignore warnings are not 
particularly good developers, and not particularly good at 
self-improvement.  They know how to ignore warnings - the attitude is 
"if it really was a problem, the compiler would have given an error 
message, not a mere warning".  They don't know how to disable error 
messages, and won't bother to find out.  So they will, in fact, be a lot 
more likely to fix their code.




IOW, if we are targeting people for whom warnings are not enough, then
we have already lost the battle.  Discipline cannot be forced by
technological means, because people will always work around.



Agreed.  But if we can make it harder for them to release bad code, 
that's good overall.


Ideally, I'd like the compiler to email such people's managers with a 
request that they be sent on programming courses!

Re: Tags not allowed in user repository - Mildly urgent

[Andreas Schwab via Gcc]

On Mai 10 2023, Ondřej Kubánek via Gcc wrote:

>  ! [remote rejected] master -> refs/users/kubaneko/tags/Thesis
> (hook declined)

As you can see here, you are not pushing the tag Thesis, but the local
branch master.

If you want to push the local tag Thesis to a particular place on the
remote, use Thesis:refs/users/kubaneko/tags/Thesis as the refspec.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Eli Zaretskii  writes:

> It is not GCC's business to force developers of packages to get their
> act together.

Why not?  Compilers are diagnostic tools besides just machines that
guess what machine code you mean.

> It is the business of those package developers themselves.  GCC should
> give those developers effective and convenient means of detecting any
> unsafe and dubious code and of correcting it as they see fit.  Which
> GCC already does by emitting warnings.

There's a difference between dubious and unsafe code and code that is
unambiguously wrong, but was chosen to be accepted many years ago.

> GCC should only error out if it is completely unable to produce valid
> code, which is not the case here, since it has been producing valid
> code for ages.

Producing call code with wrong prototypes is not within my definition of
producing valid code.

> It is a disservice to GCC users if a program that compiled yesterday
> and worked perfectly well suddenly cannot be built because GCC was
> upgraded, perhaps due to completely unrelated reasons.

Please see the various porting-to pages.  Compilers stop being able to
produce code with older versions of programs because of them being a
lil' too lax and the programs accidentally relying on that every year.
There's nothing wrong there.

If compilers stopped being lax, such things wouldn't happen simply
because programs couldn't accidentally rely on it, so we'd get the ideal
world without breakages.  We don't get that by pretending code is fine
when it is not, and letting developers write that code.

Now, of course, this instance is different to porting-to pages, because
we aren't talking about code accidentally relying on a transitive
include or an edge case or somesuch, we're talking about the compiler
going out of its way to produce wrong code and whispering into the wind
about doing it.

> It would be a grave mistake on the part of GCC to decide that part of
> its mission is to teach package developers how to write their code and
> when and how to modify it.

It would be a grave mistake on the part of GCC to decide that part of
its mission is to pretend code is fine when it is unambiguously broken,
and then not tell people about it very loudly.

I don't think we should send out the message of "GCC: the compiler for
your untouchable legacy code, not for writing new code, or upgrading
existing code".

Providing compatibility here is a trivial job, we don't need to make
each developer suffer with tweaking compiler flags to get the compiler
to diagnose blatantly wrong code as errors, or more likely, not do it at
all because they don't know about this problem.

We could, of course, alter documentation to tell people that running GCC
in strict mode requires some concoction of flags, or we could alter it
so that it says that running GCC in a lax mode requires *one* flag, for
the exceptional case where code can't be easily fixed, and it's more
useful to pretend it's fine and emit broken calls.

We could even provide a 'laxgcc' or such driver that covers this
exceptional case OOTB (though I'm unconvinced that does anything that
setting CC='gcc -fpermissive' doesn't cover).

Have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Eric Gallager via Gcc]

On 5/9/23, Jonathan Wakely via Gcc  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 am a bit gun shy because I remember the move from GCC 3.3 to 3.4
>> where the improved strict alias checking gave us a LOT of warnings to
>> deal with and it felt overwhelming. I don't want to do that again.
>>
>> But I believe in letting the compiler get stricter and find things.
>> Defaulting
>> to stricter checking is a good thing.
>
> The checks are already done, they're just warnings by default, and so
> easily missed/ignored when compiling large code bases.
>

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Eric Gallager via Gcc  writes:

> On 5/9/23, Jonathan Wakely via Gcc  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_ow4ryjvpw...@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.


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Wed, 10 May 2023 at 11:40, Eric Gallager  wrote:
>
> On 5/9/23, Jonathan Wakely via Gcc  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.

On the Suse list there was a strong objection to doing that, because
it just prolongs the pain. It means maintainers spend the next three
years dealing with it, fixing the same packages again and again,
instead of just getting it done.

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Wed, 10 May 2023 at 11:48, Jonathan Wakely  wrote:
>
> On Wed, 10 May 2023 at 11:40, Eric Gallager  wrote:
> >
> > On 5/9/23, Jonathan Wakely via Gcc  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.
>
> On the Suse list there was a strong objection to doing that, because
> it just prolongs the pain. It means maintainers spend the next three
> years dealing with it, fixing the same packages again and again,
> instead of just getting it done.

And if you don't want to deal with them all, just use the -fpermissive
flag (or however it will be named) to get the old behaviour.

I really don't see how dragging this out over **another** three years
will help anybody. Florian's already been working on this for years.

Re: More C type errors by default for GCC 14

[Neal Gompa]

On Wed, May 10, 2023 at 6:48 AM Sam James  wrote:
>
>
> Eric Gallager via Gcc  writes:
>
> > On 5/9/23, Jonathan Wakely via Gcc  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_ow4ryjvpw...@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!

Re: More C type errors by default for GCC 14

[David Brown via Gcc]

On 09/05/2023 22:13, David Edelsohn via Gcc wrote:

On Tue, May 9, 2023 at 3:22 PM Eli Zaretskii via Gcc 
wrote:


Date: Tue, 9 May 2023 21:07:07 +0200
From: Jakub Jelinek 
Cc: Jonathan Wakely , ar...@aarsen.me,

gcc@gcc.gnu.org


On Tue, May 09, 2023 at 10:04:06PM +0300, Eli Zaretskii via Gcc wrote:

From: Jonathan Wakely 
Date: Tue, 9 May 2023 18:15:59 +0100
Cc: Arsen Arsenović , gcc@gcc.gnu.org

On Tue, 9 May 2023 at 17:56, Eli Zaretskii wrote:


No one has yet explained why a warning about this is not enough,

and

why it must be made an error.  Florian's initial post doesn't

explain

that, and none of the followups did, although questions about

whether

a warning is not already sufficient were asked.

That's a simple question, and unless answered with valid arguments,
the proposal cannot make sense to me, at least.


People ignore warnings. That's why the problems have gone unfixed for
so many years, and will continue to go unfixed if invalid code keeps
compiling.


People who ignore warnings will use options that disable these new
errors, exactly as they disable warnings.  So we will end up not


Some subset of them will surely do that.  But I think most people will

just

fix the code when they see hard errors, rather than trying to work around
them.


The same logic should work for warnings.  That's why we have warnings,
no?



This seems to be the core tension.  If developers cared about these issues,
they would enable appropriate warnings and -Werror.



-Werror is a /big/ stick.  An unused parameter message might just be an 
indication that the programmer isn't finished with that bit of code, and 
a warning is fine.  An implicit function declaration message shows a 
clear problem in the code - a typo in the function call, a missing 
#include, or a major flaw in the design and organisation of the code.


The C language takes backwards compatibility more seriously than any 
other programming language.  When the C standards mark previously 
acceptable features as deprecated, obsolescent, or constrain errors, it 
is done for very good reasons.  People should not be writing code with 
implicit int, or non-prototype function declarations.  Such mis-features 
of the language were outdated 30 years ago.



The code using these idioms is not safe and does create security
vulnerabilities.  And software security is increasingly important.

The concern is using the good will of the GNU Toolchain brand as the tip of
the spear or battering ram to motivate software packages to fix their
problems. It's using GCC as leverage in a manner that is difficult for
package maintainers to avoid.  Maybe that's a necessary approach, but we
should be clear about the reasoning.  Again, I'm not objecting, but let's
clarify why we are choosing this approach.



There are two problems I see with the current state of affairs, where 
deeply flawed code can be accepted (possibly with warnings) by gcc by 
default.


1. Modern developers who are not particularly well versed in the 
language write code with these same risky features.  It is depressing 
how many people think "The C Programming Language" (often a battered 
first edition) is all you need for learning C programming.  Turning more 
outdated syntax and more obvious mistakes into hard errors will help 
such developers - and help everyone who has to use the code they make.



2. Old code gets compiled with with modern tools that do not fulfil the 
assumptions made by the developer decades ago.  Compiling such code with 
modern gcc risks all sorts of problems due to the simpler compilation 
models of older tools.  For example, the code might assume two's 
complement wrapping arithmetic, or that function calls always act as a 
memory barrier.



My suggestion would be to have a flag "-fold-code" that would do the 
following (at a minimum) :


* Disallow higher optimisation flags.
* Force -fwrapv, -fno-strict-aliasing, -fno-inline.
* Require an explicit "-std=" selection.
* Allow old-style syntax, such as implicit int, with just a warning

If the "-fold-code" is /not/ included, then old, deprecated or 
obsolescent syntax would be a hard error that cannot be turned off or 
downgraded to a warning by flags.  A substantial subset of -Wall 
warnings would be enabled automatically.  (I think the "unused" warnings 
should not be included, for example.)



Distributions and upstream code maintainers should be pushed towards 
either fixing and updating their code, or marking it as "-fold-code" if 
it is too outdated to modernise without a major re-write.  This might be 
painful during the transition, but waiting longer just makes the 
situation work.


(I'm a long-term gcc user, but not a gcc developer.  I'm fully aware 
that I am asking others to do a lot of work here, but I think something 
of this sort is important going forward.)



David

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> From: Jonathan Wakely 
> Date: Wed, 10 May 2023 09:04:12 +0100
> Cc: Florian Weimer , "gcc@gcc.gnu.org" , 
>   Jakub Jelinek , Arsen Arsenović 
> 
> void foo(int);
> void bar() { foo("42"); }
> 
> Why should this compile?

Because GCC is capable of compiling it.

> You keep demanding better rationale for the change, but your argument amounts 
> to nothing more than
> "it compiles today, it should compile tomorrow".

It compiles today with a warning, so that whoever is interested to fix
the code, can do that already.  The issue at hand is not whether to
flag the code as highly suspicious, the issue at hand is whether
upgrade the warning to errors.  So let's talk about the issue at hand,
not about something else, okay?

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Wed, 10 May 2023 10:49:32 +0200
> From: David Brown via Gcc 
> 
> > People who ignore warnings will use options that disable these new
> > errors, exactly as they disable warnings.  So we will end up not
> > reaching the goal, but instead harming those who are well aware of the
> > warnings.
> 
> My experience is that many of the people who ignore warnings are not 
> particularly good developers, and not particularly good at 
> self-improvement.  They know how to ignore warnings - the attitude is 
> "if it really was a problem, the compiler would have given an error 
> message, not a mere warning".  They don't know how to disable error 
> messages, and won't bother to find out.  So they will, in fact, be a lot 
> more likely to fix their code.

If some developers want to ignore warnings, it is not the business of
GCC to improve them, even if you are right in assuming that they will
not work around errors like they work around warnings (and I'm not at
all sure you are right in that assumption).  But by _forcing_ these
errors on _everyone_, GCC will in effect punish those developers who
have good reasons for not changing the code.

> > IOW, if we are targeting people for whom warnings are not enough, then
> > we have already lost the battle.  Discipline cannot be forced by
> > technological means, because people will always work around.
> > 
> 
> Agreed.  But if we can make it harder for them to release bad code, 
> that's good overall.

I'm okay with making it harder, but without making it too hard for
those whose reasons for not changing the code are perfectly valid.
This proposal crosses that line, IMNSHO.

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Wed, 10 May 2023 at 12:36, Eli Zaretskii via Gcc  wrote:
>
> > Date: Wed, 10 May 2023 10:49:32 +0200
> > From: David Brown via Gcc 
> >
> > > People who ignore warnings will use options that disable these new
> > > errors, exactly as they disable warnings.  So we will end up not
> > > reaching the goal, but instead harming those who are well aware of the
> > > warnings.
> >
> > My experience is that many of the people who ignore warnings are not
> > particularly good developers, and not particularly good at
> > self-improvement.  They know how to ignore warnings - the attitude is
> > "if it really was a problem, the compiler would have given an error
> > message, not a mere warning".  They don't know how to disable error
> > messages, and won't bother to find out.  So they will, in fact, be a lot
> > more likely to fix their code.
>
> If some developers want to ignore warnings, it is not the business of
> GCC to improve them, even if you are right in assuming that they will
> not work around errors like they work around warnings (and I'm not at
> all sure you are right in that assumption).  But by _forcing_ these
> errors on _everyone_, GCC will in effect punish those developers who
> have good reasons for not changing the code.

There will be options you can use to continue compiling the code
without changing it. You haven't given a good reason why it's OK for
one group of developers to have to use options to get their desired
behaviour from GCC, but completely unacceptable for a different group
to have to use options to get their desired behaviour.

This is just a change in defaults. Accepting broken code by default is
not a priori a good thing, as you seem to insist. Rejecting it by
default is not a priori a good thing. There is a pragmatic choice to
be made, and your argument is still no more than "it compiles today,
so it should compile tomorrow".


> > > IOW, if we are targeting people for whom warnings are not enough, then
> > > we have already lost the battle.  Discipline cannot be forced by
> > > technological means, because people will always work around.
> > >
> >
> > Agreed.  But if we can make it harder for them to release bad code,
> > that's good overall.
>
> I'm okay with making it harder, but without making it too hard for
> those whose reasons for not changing the code are perfectly valid.
> This proposal crosses that line, IMNSHO.

Where "too hard" means using a compiler option. Seriously? This seems farcical.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> From: Arsen Arsenović 
> Cc: dje@gmail.com, ja...@redhat.com, jwakely@gmail.com, 
> gcc@gcc.gnu.org
> Date: Wed, 10 May 2023 10:36:23 +0200
> 
> Eli Zaretskii  writes:
> 
> > It is not GCC's business to force developers of packages to get their
> > act together.
> 
> Why not?  Compilers are diagnostic tools besides just machines that
> guess what machine code you mean.

Diagnostics does not mean error.  A warning is also diagnostics.

> > It is the business of those package developers themselves.  GCC should
> > give those developers effective and convenient means of detecting any
> > unsafe and dubious code and of correcting it as they see fit.  Which
> > GCC already does by emitting warnings.
> 
> There's a difference between dubious and unsafe code and code that is
> unambiguously wrong, but was chosen to be accepted many years ago.

Is GCC indeed capable of reliably distinguishing between these two?

And that code is not unambiguously wrong, since it is valid under old
standards, and thus can be compiled, and did compile, into a working
program.

> > GCC should only error out if it is completely unable to produce valid
> > code, which is not the case here, since it has been producing valid
> > code for ages.
> 
> Producing call code with wrong prototypes is not within my definition of
> producing valid code.

I don't think I follow.  If the produced machine code is valid and
does what the programmer meant, why should we care about the
prototypes?

> > It is a disservice to GCC users if a program that compiled yesterday
> > and worked perfectly well suddenly cannot be built because GCC was
> > upgraded, perhaps due to completely unrelated reasons.
> 
> Please see the various porting-to pages.  Compilers stop being able to
> produce code with older versions of programs because of them being a
> lil' too lax and the programs accidentally relying on that every year.
> There's nothing wrong there.
> 
> If compilers stopped being lax, such things wouldn't happen simply
> because programs couldn't accidentally rely on it, so we'd get the ideal
> world without breakages.  We don't get that by pretending code is fine
> when it is not, and letting developers write that code.

Once again, it is not GCC's business to clean up the packages which
use GCC as the compiler.  GCC is a tool, and should allow any
legitimate use of it that could be useful to someone.  Warning about
dubious usage is perfectly fine, as it helps those who do that
unintentionally or due to ignorance.  But completely failing an
operation that could have produce valid code is too radical.

We all want that the code of the packages be clean and according to
standards.  But using draconian measures towards that goal is dead
wrong, and is basically against the libertarian spirit that gave birth
to Free Software.  It is not an accident that GPL doesn't disallow
writing badly written or even crashing programs.

> > It would be a grave mistake on the part of GCC to decide that part of
> > its mission is to teach package developers how to write their code and
> > when and how to modify it.
> 
> It would be a grave mistake on the part of GCC to decide that part of
> its mission is to pretend code is fine when it is unambiguously broken,
> and then not tell people about it very loudly.

It is not broken, certainly not "unambiguously".  It did compile and
work in the very recent past.

> I don't think we should send out the message of "GCC: the compiler for
> your untouchable legacy code, not for writing new code, or upgrading
> existing code".

GCC sends the messages "don't write bad or dubious code" by emitting
warnings about such code.  There's no need to have a virtual gun
pointed to the heads of package developers to make that message so
much stronger, because doing that shifts the balance from merely being
a good and friendly tool towards second-guessing all of the GCC users
and knowing better then they do what they want.

Re: Tags not allowed in user repository - Mildly urgent

[Sam James via Gcc]

Ondřej Kubánek via Gcc  writes:

> Hello,
>
> I have tried to push a tag to my user space /tags/ ref in the GCC repo. The
> tag is annotated but the push was rejected. Here is the command
>
> git push origin master:refs/users/kubaneko/tags/Thesis Thesis
>
> and here is the response
>
> Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
> remote: *** Lightweight tags ('kubaneko/tags/Thesis' in namespace
> 'refs/users') are not allowed in this repository.
> remote: *** Use 'git tag [ -a | -s ]' for tags you want to propagate.
> remote: error: hook declined to update refs/users/kubaneko/tags/Thesis
> To git+ssh://gcc.gnu.org/git/gcc.git
>  ! [remote rejected] master -> refs/users/kubaneko/tags/Thesis
> (hook declined)
> error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git'
>
> Is this expected behaviour? Do I need a gpg key to sign the tag?

Note that you probably want to use a 'namespaced' tag (i.e. something
with a prefix). The version you pushed is simply called 'Thesis' which
is likely to be confusing to people.



signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Wed, 10 May 2023 at 12:51, Eli Zaretskii wrote:
> Once again, it is not GCC's business to clean up the packages which
> use GCC as the compiler.  GCC is a tool, and should allow any
> legitimate use of it that could be useful to someone.  Warning about
> dubious usage is perfectly fine, as it helps those who do that
> unintentionally or due to ignorance.  But completely failing an
> operation that could have produce valid code is too radical.

Again (are you even reading the replies?), there will be an option to
continue to accept the invalid code. This is just a change in
defaults.

GCC will not force anybody to change code, at most it this change
would force them to consciously and intentionally say "I know this is
not valid C code but I want to compile it anyway". By using a compiler
option. This is not draconian, and you sound quite silly.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> From: Eric Gallager 
> Date: Wed, 10 May 2023 06:40:54 -0400
> Cc: j...@rtems.org, David Edelsohn , Eli Zaretskii 
> , 
>   Jakub Jelinek , Arsen Arsenović , 
>   "gcc@gcc.gnu.org" 
> 
> 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.

What do we tell those who cannot possibly "catch up", for whatever
valid reasons?  E.g., consider a program written many years ago, which
is safety-critical, and where making any changes requires so many
validations and verifications that it is simply impractical, and will
never be done.  Why would we want to break such programs?

And that is just one example of perfectly valid reasons for not
wanting or not being able to make changes to pacify GCC.

Once again, my bother is not about "villains" who don't want to get
their act together, my bother is about cases such as the one above,
where the developers simply have no practical choice.

And please don't tell me they should use an older GCC, because as
systems go forward and are upgraded, older GCC will not work anymore.

Re: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

On Wed, May 10, 2023 at 02:30:07PM +0300, Eli Zaretskii wrote:
> > From: Jonathan Wakely 
> > Date: Wed, 10 May 2023 09:04:12 +0100
> > Cc: Florian Weimer , "gcc@gcc.gnu.org" 
> > , 
> > Jakub Jelinek , Arsen Arsenović 
> > 
> > void foo(int);
> > void bar() { foo("42"); }
> > 
> > Why should this compile?
> 
> 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.

C99 for the above says:
6.5.2.2/7
"If the expression that denotes the called function has a type that does 
include a prototype,
the arguments are implicitly converted, as if by assignment, to the types of the
corresponding parameters, taking the type of each parameter to be the 
unqualified version
of its declared type."
and
"One of the following shall hold:
— the left operand has qualified or unqualified arithmetic type and the right 
has
arithmetic type;
— the left operand has a qualified or unqualified version of a structure or 
union type
compatible with the type of the right;
— both operands are pointers to qualified or unqualified versions of compatible 
types,
and the type pointed to by the left has all the qualifiers of the type pointed 
to by the
right;
— one operand is a pointer to an object or incomplete type and the other is a 
pointer to a
qualified or unqualified version of void, and the type pointed to by the left 
has all
the qualifiers of the type pointed to by the right;
— the left operand is a pointer and the right is a null pointer constant; or
— the left operand has type _Bool and the right is a pointer."
For the above case, none of that holds and it isn't something desirable to
be supported as GNU extension, because while it could happen to work as the
user wanted after cast back to pointer in foo on ilp32 architectures, it
doesn't make any sense on lp64 or llp64 architectures.

Note, this isn't valid even in C89 and is already rejected with
-pedantic-errors for years.
The proposal is essentially to stop accepting this as a GNU extension
which was added for K&R compatibility I assume and do that only for C99 and
later.

> It compiles today with a warning, so that whoever is interested to fix
> the code, can do that already.  The issue at hand is not whether to
> flag the code as highly suspicious, the issue at hand is whether
> upgrade the warning to errors.  So let's talk about the issue at hand,
> not about something else, okay?

We do such changes several times a year, where we reject something that has
been previously accepted in older standards, admittedly mostly in C++.
Yes, it is done far less in C, but still, as the above is invalid already in
C89, users had over 3 decades to fix their code, and in many cases they
didn't and without this move they will never bother.
A lot of such broken code has been even written in those 3 decades, doesn't
predate it, but because the compiler just warned on it, it still appeared in
the code bases.  If we wait with this change another 2 decades, nothing will
change and we'll have the same problem then.

Jakub

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> From: Neal Gompa 
> Date: Wed, 10 May 2023 06:56:32 -0400
> Cc: Eric Gallager , Jonathan Wakely 
> , j...@rtems.org, 
>   David Edelsohn , Eli Zaretskii , Jakub 
> Jelinek , 
>   Arsen Arsenović , gcc@gcc.gnu.org, 
>   c-std-port...@lists.linux.dev
> 
> On Wed, May 10, 2023 at 6:48 AM Sam James  wrote:
> >
> > Neal Gompa wasn't keen on the idea at
> > https://lore.kernel.org/c-std-porting/CAEg-Je8=dQo-jAdu=od5dh+h9aqzge_4ghzgx_ow4ryjvpw...@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.

Re: More C type errors by default for GCC 14

[Neal Gompa]

On Wed, May 10, 2023 at 8:05 AM Eli Zaretskii  wrote:
>
> > From: Neal Gompa 
> > Date: Wed, 10 May 2023 06:56:32 -0400
> > Cc: Eric Gallager , Jonathan Wakely 
> > , j...@rtems.org,
> >   David Edelsohn , Eli Zaretskii , 
> > Jakub Jelinek ,
> >   Arsen Arsenović , gcc@gcc.gnu.org,
> >   c-std-port...@lists.linux.dev
> >
> > On Wed, May 10, 2023 at 6:48 AM Sam James  wrote:
> > >
> > > Neal Gompa wasn't keen on the idea at
> > > https://lore.kernel.org/c-std-porting/CAEg-Je8=dQo-jAdu=od5dh+h9aqzge_4ghzgx_ow4ryjvpw...@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!

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> From: Jonathan Wakely 
> Date: Wed, 10 May 2023 12:49:52 +0100
> Cc: David Brown , gcc@gcc.gnu.org
> 
> > If some developers want to ignore warnings, it is not the business of
> > GCC to improve them, even if you are right in assuming that they will
> > not work around errors like they work around warnings (and I'm not at
> > all sure you are right in that assumption).  But by _forcing_ these
> > errors on _everyone_, GCC will in effect punish those developers who
> > have good reasons for not changing the code.
> 
> There will be options you can use to continue compiling the code
> without changing it. You haven't given a good reason why it's OK for
> one group of developers to have to use options to get their desired
> behaviour from GCC, but completely unacceptable for a different group
> to have to use options to get their desired behaviour.
> 
> This is just a change in defaults.

A change in defaults that is not backward-compatible should only be
done for very good reasons, because it breaks something that was
working for years.  No such good reasons were provided.  And no,
educating/forcing GCC users to use more modern dialect of C is not a
good reason.

> Accepting broken code by default is not a priori a good thing, as
> you seem to insist. Rejecting it by default is not a priori a good
> thing. There is a pragmatic choice to be made, and your argument is
> still no more than "it compiles today, so it should compile
> tomorrow".

Once again: it isn't "broken code".  It is dangerous code, and in some
cases unintentionally suspicious code.  But it isn't broken, because
GCC can compile it into a valid program, which, if the programmer
indeed meant that, will work and do its job.

> > > Agreed.  But if we can make it harder for them to release bad code,
> > > that's good overall.
> >
> > I'm okay with making it harder, but without making it too hard for
> > those whose reasons for not changing the code are perfectly valid.
> > This proposal crosses that line, IMNSHO.
> 
> Where "too hard" means using a compiler option. Seriously? This seems 
> farcical.

This goes both ways, of course.  GCC had -Werror since about forever.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> From: Jonathan Wakely 
> Date: Wed, 10 May 2023 12:56:48 +0100
> Cc: Arsen Arsenović , dje@gmail.com, 
>   ja...@redhat.com, gcc@gcc.gnu.org
> 
> On Wed, 10 May 2023 at 12:51, Eli Zaretskii wrote:
> > Once again, it is not GCC's business to clean up the packages which
> > use GCC as the compiler.  GCC is a tool, and should allow any
> > legitimate use of it that could be useful to someone.  Warning about
> > dubious usage is perfectly fine, as it helps those who do that
> > unintentionally or due to ignorance.  But completely failing an
> > operation that could have produce valid code is too radical.
> 
> Again (are you even reading the replies?)

Please assume that I read everything, subject to email delivery times.
There's no reason for you to assume anything but good faith from my
side.

> GCC will not force anybody to change code, at most it this change
> would force them to consciously and intentionally say "I know this is
> not valid C code but I want to compile it anyway". By using a compiler
> option. This is not draconian, and you sound quite silly.

If we are not forcing code change, why bother with making it an error
at all?  The only reason for doing so that was provided was that this
_is_ a way of forcing people to change their programs.

Re: More C type errors by default for GCC 14

[Florian Weimer via Gcc]

* Richard Biener:

> On Wed, May 10, 2023 at 10:05 AM Jonathan Wakely via Gcc
>  wrote:
>>
>> On Wed, 10 May 2023, 03:32 Eli Zaretskii,  wrote:
>>
>> >
>> > And then people will start complaining about GCC unnecessarily
>> > erroring out, which is a compiler bug, since there's no problem
>> > producing correct code in these cases.
>> >
>>
>>
>> What is the correct code for this?
>>
>> void foo(int);
>> void bar() { foo("42"); }
>>
>> Why should this compile?
>>
>> You keep demanding better rationale for the change, but your argument
>> amounts to nothing more than "it compiles today, it should compile
>> tomorrow".
>
> void foo(__UINTPTR_TYPE__);
> void bar() { foo("42"); }
>
> might be something we'd still like to diagnose but eventually not turn
> into an error?  Yes, it then depends on the target whether the code is
> accepted or not, but at least it would continue working where there's
> a "good" answer to your question.

The x86-64 defaults for GNU/Linux were originally set in such a way that
there is a good chance that pointers fit into an int, and broken code
like that happens to work (as long as it's in the main program).  Of
course I think we should nevertheless reject it by default.

Anyway, if int-conversion somehow proves more controversial, I believe
disabling implicit-int and implicit-function-declaration by default
would still be a huge step forward.

Thanks,
Florian

Re: Tags not allowed in user repository - Mildly urgent

[Andreas Schwab via Gcc]

On Mai 10 2023, Sam James via Gcc wrote:

> Ondřej Kubánek via Gcc  writes:
>
>> Hello,
>>
>> I have tried to push a tag to my user space /tags/ ref in the GCC repo. The
>> tag is annotated but the push was rejected. Here is the command
>>
>> git push origin master:refs/users/kubaneko/tags/Thesis Thesis
>>
>> and here is the response
>>
>> Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
>> remote: *** Lightweight tags ('kubaneko/tags/Thesis' in namespace
>> 'refs/users') are not allowed in this repository.
>> remote: *** Use 'git tag [ -a | -s ]' for tags you want to propagate.
>> remote: error: hook declined to update refs/users/kubaneko/tags/Thesis
>> To git+ssh://gcc.gnu.org/git/gcc.git
>>  ! [remote rejected] master -> refs/users/kubaneko/tags/Thesis
>> (hook declined)
>> error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git'
>>
>> Is this expected behaviour? Do I need a gpg key to sign the tag?
>
> Note that you probably want to use a 'namespaced' tag (i.e. something
> with a prefix). The version you pushed is simply called 'Thesis' which
> is likely to be confusing to people.

It already uses a prefix (users/kubaneko) which is not fetched by
default.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Wed, 10 May 2023 at 13:23, Eli Zaretskii  wrote:
>
> > From: Jonathan Wakely 
> > Date: Wed, 10 May 2023 12:56:48 +0100
> > Cc: Arsen Arsenović , dje@gmail.com,
> >   ja...@redhat.com, gcc@gcc.gnu.org
> >
> > On Wed, 10 May 2023 at 12:51, Eli Zaretskii wrote:
> > > Once again, it is not GCC's business to clean up the packages which
> > > use GCC as the compiler.  GCC is a tool, and should allow any
> > > legitimate use of it that could be useful to someone.  Warning about
> > > dubious usage is perfectly fine, as it helps those who do that
> > > unintentionally or due to ignorance.  But completely failing an
> > > operation that could have produce valid code is too radical.
> >
> > Again (are you even reading the replies?)
>
> Please assume that I read everything, subject to email delivery times.
> There's no reason for you to assume anything but good faith from my
> side.
>
> > GCC will not force anybody to change code, at most it this change
> > would force them to consciously and intentionally say "I know this is
> > not valid C code but I want to compile it anyway". By using a compiler
> > option. This is not draconian, and you sound quite silly.
>
> If we are not forcing code change, why bother with making it an error
> at all?  The only reason for doing so that was provided was that this
> _is_ a way of forcing people to change their programs.

It stops people writing these errors in the first place. Not all code
compiled with GCC is old, crufty K&R code that must be preserved for
eternity.

People are still using C to write new programs, and they are still
making avoidable mistakes. The default for new code using new -std
modes should be safer and less error prone.

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Eli Zaretskii via Gcc  writes:

>> Date: Wed, 10 May 2023 10:49:32 +0200
>> From: David Brown via Gcc 
>> 
>> > People who ignore warnings will use options that disable these new
>> > errors, exactly as they disable warnings.  So we will end up not
>> > reaching the goal, but instead harming those who are well aware of the
>> > warnings.
>> 
>> My experience is that many of the people who ignore warnings are not 
>> particularly good developers, and not particularly good at 
>> self-improvement.  They know how to ignore warnings - the attitude is 
>> "if it really was a problem, the compiler would have given an error 
>> message, not a mere warning".  They don't know how to disable error 
>> messages, and won't bother to find out.  So they will, in fact, be a lot 
>> more likely to fix their code.
>
> If some developers want to ignore warnings, it is not the business of
> GCC to improve them, even if you are right in assuming that they will
> not work around errors like they work around warnings (and I'm not at
> all sure you are right in that assumption).  But by _forcing_ these
> errors on _everyone_, GCC will in effect punish those developers who
> have good reasons for not changing the code.
>
>> > IOW, if we are targeting people for whom warnings are not enough, then
>> > we have already lost the battle.  Discipline cannot be forced by
>> > technological means, because people will always work around.
>> > 
>> 
>> Agreed.  But if we can make it harder for them to release bad code, 
>> that's good overall.
>
> I'm okay with making it harder, but without making it too hard for
> those whose reasons for not changing the code are perfectly valid.
> This proposal crosses that line, IMNSHO.

Could you give an example of how to make it harder without crossing
the line for you?


signature.asc
Description: PGP signature

Re: Tags not allowed in user repository - Mildly urgent

[Sam James via Gcc]

Andreas Schwab  writes:

> On Mai 10 2023, Sam James via Gcc wrote:
>
>> Ondřej Kubánek via Gcc  writes:
>>
>>> Hello,
>>>
>>> I have tried to push a tag to my user space /tags/ ref in the GCC repo. The
>>> tag is annotated but the push was rejected. Here is the command
>>>
>>> git push origin master:refs/users/kubaneko/tags/Thesis Thesis
>>>
>>> and here is the response
>>>
>>> Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
>>> remote: *** Lightweight tags ('kubaneko/tags/Thesis' in namespace
>>> 'refs/users') are not allowed in this repository.
>>> remote: *** Use 'git tag [ -a | -s ]' for tags you want to propagate.
>>> remote: error: hook declined to update refs/users/kubaneko/tags/Thesis
>>> To git+ssh://gcc.gnu.org/git/gcc.git
>>>  ! [remote rejected] master -> refs/users/kubaneko/tags/Thesis
>>> (hook declined)
>>> error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git'
>>>
>>> Is this expected behaviour? Do I need a gpg key to sign the tag?
>>
>> Note that you probably want to use a 'namespaced' tag (i.e. something
>> with a prefix). The version you pushed is simply called 'Thesis' which
>> is likely to be confusing to people.
>
> It already uses a prefix (users/kubaneko) which is not fetched by
> default.

Ah, thanks, the UI in the tags section at 
https://gcc.gnu.org/git/?p=gcc.git;a=summary
confused me. But it's likely to confuse others as well.


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Wed, 10 May 2023 14:03:01 +0200
> From: Jakub Jelinek 
> Cc: Jonathan Wakely , fwei...@redhat.com,
> gcc@gcc.gnu.org, ar...@aarsen.me
> 
> > > Why should this compile?
> > 
> > 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.

> C99 for the above says:

I know what the standard says, but since when do we in the GNU project
accept standards as a dictate?  We do what we consider to be best for
our users, and follow the standards when that doesn't contradict what
we think is best for the users.  GCC has, for example, -std=gnu99
etc. precisely for that purpose.

> The proposal is essentially to stop accepting this as a GNU extension
> which was added for K&R compatibility I assume and do that only for C99 and
> later.

I understand.  I'm saying that there's no reason to make this an
error, because it will break builds that have good reasons for keeping
such code.

> Note, this isn't valid even in C89 and is already rejected with
> -pedantic-errors for years.

Terrific!  Rejecting such code given a non-default option is _exactly_
what should be done.  But we here are discussing the default behavior.

> > It compiles today with a warning, so that whoever is interested to fix
> > the code, can do that already.  The issue at hand is not whether to
> > flag the code as highly suspicious, the issue at hand is whether
> > upgrade the warning to errors.  So let's talk about the issue at hand,
> > not about something else, okay?
> 
> We do such changes several times a year, where we reject something that has
> been previously accepted in older standards, admittedly mostly in C++.

And that is a Good Thing?  I don't think so.  Maybe for C++ it's
inevitable, I'm not an expert on that.  But making breaking changes is
inherently BAD and should be avoided.

> Yes, it is done far less in C, but still, as the above is invalid already in
> C89, users had over 3 decades to fix their code, and in many cases they
> didn't and without this move they will never bother.

Please consider those cases where the code cannot be "fixed", in
practice.  I described one such situation in a previous message.

> A lot of such broken code has been even written in those 3 decades, doesn't
> predate it, but because the compiler just warned on it, it still appeared in
> the code bases.  If we wait with this change another 2 decades, nothing will
> change and we'll have the same problem then.

GCC is not responsible for the existence of that code.  So GCC
shouldn't change its decades-long behavior just because that code is
there.  there must be a much more serious reason for such changes,
something that affects GCC itself.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> From: Neal Gompa 
> Date: Wed, 10 May 2023 08:10:48 -0400
> Cc: s...@gentoo.org, eg...@gwmail.gwu.edu, jwakely@gmail.com, 
>   j...@rtems.org, dje@gmail.com, ja...@redhat.com, ar...@aarsen.me, 
>   gcc@gcc.gnu.org, c-std-port...@lists.linux.dev
> 
> On Wed, May 10, 2023 at 8:05 AM Eli Zaretskii  wrote:
> >
> > > From: Neal Gompa 
> > > Date: Wed, 10 May 2023 06:56:32 -0400
> > > Cc: Eric Gallager , Jonathan Wakely 
> > > , j...@rtems.org,
> > >   David Edelsohn , Eli Zaretskii , 
> > > Jakub Jelinek ,
> > >   Arsen Arsenović , gcc@gcc.gnu.org,
> > >   c-std-port...@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.

Re: More C type errors by default for GCC 14

[Gabriel Ravier via Gcc]

On 5/10/23 14:36, Eli Zaretskii via Gcc wrote:

Date: Wed, 10 May 2023 14:03:01 +0200
From: Jakub Jelinek 
Cc: Jonathan Wakely , fwei...@redhat.com,
 gcc@gcc.gnu.org, ar...@aarsen.me


Why should this compile?

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




C99 for the above says:

I know what the standard says, but since when do we in the GNU project
accept standards as a dictate?  We do what we consider to be best for
our users, and follow the standards when that doesn't contradict what
we think is best for the users.  GCC has, for example, -std=gnu99
etc. precisely for that purpose.


The proposal is essentially to stop accepting this as a GNU extension
which was added for K&R compatibility I assume and do that only for C99 and
later.

I understand.  I'm saying that there's no reason to make this an
error, because it will break builds that have good reasons for keeping
such code.


Note, this isn't valid even in C89 and is already rejected with
-pedantic-errors for years.

Terrific!  Rejecting such code given a non-default option is _exactly_
what should be done.  But we here are discussing the default behavior.


It compiles today with a warning, so that whoever is interested to fix
the code, can do that already.  The issue at hand is not whether to
flag the code as highly suspicious, the issue at hand is whether
upgrade the warning to errors.  So let's talk about the issue at hand,
not about something else, okay?

We do such changes several times a year, where we reject something that has
been previously accepted in older standards, admittedly mostly in C++.

And that is a Good Thing?  I don't think so.  Maybe for C++ it's
inevitable, I'm not an expert on that.  But making breaking changes is
inherently BAD and should be avoided.


Yes, it is done far less in C, but still, as the above is invalid already in
C89, users had over 3 decades to fix their code, and in many cases they
didn't and without this move they will never bother.

Please consider those cases where the code cannot be "fixed", in
practice.  I described one such situation in a previous message.


A lot of such broken code has been even written in those 3 decades, doesn't
predate it, but because the compiler just warned on it, it still appeared in
the code bases.  If we wait with this change another 2 decades, nothing will
change and we'll have the same problem then.

GCC is not responsible for the existence of that code.  So GCC
shouldn't change its decades-long behavior just because that code is
there.  there must be a much more serious reason for such changes,
something that affects GCC itself.

More C type errors by default for GCC 14

[Marcin Jaczewski via Gcc]

I think the biggest problem you have is that you try to upgrade the compiler
to compile code that nobody has touched in 30years.

Adding `-fpermissive` is the least concern you should have.

Did you even check if the compiler outpost is still correct?
As you are really on some obsolete functionality it could easily rot
and the new compiler can not handle it correctly.

You mention "validations and verifications", do you do the same
with the new compiler?

If you can't touch code then you SHOULD not upgrade the compiler.
If you upgrade the compiler you SHOULD upgrade code.

Any big project (like Linux) shows these two rules are critical,
there were multiple cases of security bugs caused by subtle change
in behavior of the compiler.
Compiling very old code is lability if nobody knows how it should work and
nobody maintains it. Who can give you guarantee that the result is correct?
Very old programs should even by default reject new compilers by default until
someone does not check if it correctly compiles on new compilers.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> From: Jonathan Wakely 
> Date: Wed, 10 May 2023 13:30:10 +0100
> Cc: ar...@aarsen.me, dje@gmail.com, ja...@redhat.com, gcc@gcc.gnu.org
> 
> People are still using C to write new programs, and they are still
> making avoidable mistakes. The default for new code using new -std
> modes should be safer and less error prone.

I agree.  I just think that a warning strikes the right balance
between the two extremes.  And it is a balance, because once upon a
time, GCC didn't even warn about such code.

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Eli Zaretskii via Gcc  writes:

>> From: Eric Gallager 
>> Date: Wed, 10 May 2023 06:40:54 -0400
>> Cc: j...@rtems.org, David Edelsohn , Eli Zaretskii 
>> , 
>>  Jakub Jelinek , Arsen Arsenović , 
>>  "gcc@gcc.gnu.org" 
>> 
>> 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.
>
> What do we tell those who cannot possibly "catch up", for whatever
> valid reasons?  E.g., consider a program written many years ago, which
> is safety-critical, and where making any changes requires so many
> validations and verifications that it is simply impractical, and will
> never be done.  Why would we want to break such programs?

Upgrading the toolchain is a change which requires validation, surely.

They can then test it at the same time as porting to modern C. Or simply
set the required options (as we're discussing) to allow older,
to-be-rejected constructs.

(It's also not clear to me that they're entitled to a GCC which always
works for them forever. People who like the behaviour of older GCCs
and refuse to change anything about their environment (not necessarily
their code) are able to stick with old versions if they wish.)


signature.asc
Description: PGP signature

Re: Tags not allowed in user repository - Mildly urgent

[Andreas Schwab via Gcc]

On Mai 10 2023, Sam James wrote:

> Andreas Schwab  writes:
>
>> On Mai 10 2023, Sam James via Gcc wrote:
>>
>>> Ondřej Kubánek via Gcc  writes:
>>>
 Hello,

 I have tried to push a tag to my user space /tags/ ref in the GCC repo. The
 tag is annotated but the push was rejected. Here is the command

 git push origin master:refs/users/kubaneko/tags/Thesis Thesis

 and here is the response

 Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
 remote: *** Lightweight tags ('kubaneko/tags/Thesis' in namespace
 'refs/users') are not allowed in this repository.
 remote: *** Use 'git tag [ -a | -s ]' for tags you want to propagate.
 remote: error: hook declined to update refs/users/kubaneko/tags/Thesis
 To git+ssh://gcc.gnu.org/git/gcc.git
  ! [remote rejected] master -> refs/users/kubaneko/tags/Thesis
 (hook declined)
 error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git'

 Is this expected behaviour? Do I need a gpg key to sign the tag?
>>>
>>> Note that you probably want to use a 'namespaced' tag (i.e. something
>>> with a prefix). The version you pushed is simply called 'Thesis' which
>>> is likely to be confusing to people.
>>
>> It already uses a prefix (users/kubaneko) which is not fetched by
>> default.
>
> Ah, thanks, the UI in the tags section at 
> https://gcc.gnu.org/git/?p=gcc.git;a=summary
> confused me. But it's likely to confuse others as well.

This is due to the second refspec, which just pushes to the global tags
namespace.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> From: Sam James 
> Cc: David Brown , gcc@gcc.gnu.org
> Date: Wed, 10 May 2023 13:32:08 +0100
> 
> > I'm okay with making it harder, but without making it too hard for
> > those whose reasons for not changing the code are perfectly valid.
> > This proposal crosses that line, IMNSHO.
> 
> Could you give an example of how to make it harder without crossing
> the line for you?

Not really: I'm not involved enough in GCC development to be able to
provide such concrete examples off the top of my head.  I could think
about something like making it harder to disable the warnings about
such code, for example?

Re: More C type errors by default for GCC 14

[Basile Starynkevitch]

Hello all,

After a suggestion by Eric Gallager

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.


Eli Zaretskii  wrote on 10 may 2023, at 14:00


And that is just one example of perfectly valid reasons for not
wanting or not being able to make changes to pacify GCC.

Once again, my bother is not about "villains" who don't want to get
their act together, my bother is about cases such as the one above,
where the developers simply have no practical choice.

And please don't tell me they should use an older GCC, because as
systems go forward and are upgraded, older GCC will not work anymore.



My experience is that for safety critical software (per DOI 178C, 
embedded in aircrafts, or for the French covid breathing machine on 
https://github.com/Recovid/Controller ) the regulations, funders, and 
authorities requires a very specific version of GCC with very specific 
compilation flags.



Changing either the compiler (even from gcc-12.1 to gcc-12.2) or the 
compilation flags (even changing -O1 by -O2) requires written (on paper) 
approval by a large number of human persons, and formal certifications 
(eg ISO9001, ISO27001 procedures) and lots of checks and headaches.



I do know several persons making their living of these constraints.

I do know several corporations making a living from them (and keeping 
decade older GCC compiler binaries on many disks).


So I really think that for safety critical software (whose failure may 
impact lives) people are using an older (and well specified) GCC.



Of course, to compile an ordinary business web service (e-shop for 
clothes) with e.g. libonion (from https://github.com/davidmoreno/onion 
...) or to compile a zsh.org from source code (for or on a developer's 
laptop) the constraints are a lot lighter.


Regards!


PS : my pet open source project is the RefPerSys open source inference 
engine on http://refpersys.org/ and 
https://github.com/RefPerSys/RefPerSys ; it is explicitly thought for 
non-critical use (desktop, teaching, ...).


--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: More C type errors by default for GCC 14

[David Brown via Gcc]

On 10/05/2023 14:22, Eli Zaretskii via Gcc wrote:

From: Jonathan Wakely 
Date: Wed, 10 May 2023 12:49:52 +0100
Cc: David Brown , gcc@gcc.gnu.org


If some developers want to ignore warnings, it is not the business of
GCC to improve them, even if you are right in assuming that they will
not work around errors like they work around warnings (and I'm not at
all sure you are right in that assumption).  But by _forcing_ these
errors on _everyone_, GCC will in effect punish those developers who
have good reasons for not changing the code.


What would those "good reasons" be, in your opinion?  (I realise I am 
asking you to be speculative and generalise.  This discussion is an 
exchange of opinions, thoughts, experiences and impressions.)


Frankly, the most common "good" reason for a developer not changing 
their code from pre-C99 is that they retired long ago.  And people 
should definitely question whether the code should be kept.


As I noted in another post, it is entirely reasonable to suspect that 
such old code has errors - unwarranted assumptions that were considered 
appropriate back in the days when such code techniques were considered 
appropriate.  It has always been the unfortunate case with C programming 
that getting optimal results for some compilers has sometimes involved 
"cheating" a bit, such as assuming wrapping signed arithmetic or 
converting pointer types and breaking the "strict aliasing" rules.


Changing the gcc defaults and requiring old code to use flags that allow 
old constructs but limiting optimisations is not /punishing/ the old 
code or its developers or maintainers.  It is /supporting/ it - allowing 
it to be used more safely with modern tools.



On the other hand, continuing to accept old, outdated code by lax 
defaults is punishing /current/ developers and users.  Why should 99.99% 
of current developers have to enable extra errors to catch mistakes (and 
we all make occasional mistakes in our coding - so they /should/ be 
enabling these error flags)?  Why should they have to deal with other 
people's code that was badly written 30 years ago?  Is it really worth 
it, just so that a half-dozen maintainers at Linux distributions can 
recompile the 40-year old source for "ed" without adding a flag to the 
makefile?



Ultimately, /someone/ is going to suffer - a compiler can't have good 
defaults for current developers and simultaneously good defaults for 
ancient relics.  The question to consider is not whether we "punish" 
someone, but /whom/ do we punish, and what is the best balance overall 
going forward.





There will be options you can use to continue compiling the code
without changing it. You haven't given a good reason why it's OK for
one group of developers to have to use options to get their desired
behaviour from GCC, but completely unacceptable for a different group
to have to use options to get their desired behaviour.

This is just a change in defaults.


A change in defaults that is not backward-compatible should only be
done for very good reasons, because it breaks something that was
working for years.  No such good reasons were provided.  


I'm sorry, but I believe I /did/ provide good reasons.  Granted, they 
were in more than one post.  And many others here have also given many 
good reasons.  At the very least, making a safer and more useful 
compiler that helps developers make better code is a good reason, as is 
making a C compiler that is closer to standards compatibility by default.


I do agree that backwards compatibility breaks should only be done for 
good reasons.  But I think the reasons are good.




And no,
educating/forcing GCC users to use more modern dialect of C is not a
good reason.



Yes, it /is/ a good reason.  But I suppose that one is a matter of opinion.

I encourage you to look at CERT/CC, or other lists of code errors 
leading to security issues or functional failures.  When someone writes 
poor code, lots of people suffer.  Any initiative that reduces the 
likelihood of such errors getting into the wild is not just good for gcc 
and its users, it's good for the whole society.


Consider why Rust has become the modern fad in programming.  People 
claim it is because it is inherently safer than C and C++.  It is not. 
There are really two reasons for it appearing to be safer.  One is that 
the /defaults/ for the tools, and the language idioms, are safer than 
the /defaults/ for C and C++ tools.  That makes it harder to make 
mistakes.  The other is that it has no legacy of decades of old code and 
old habits, and no newbie programmers copying those old styles.  Rust 
code is written in modern development styles, with a care for 
correctness rather than getting maximum efficiency from limited 
old-fashioned tools or macho programming.  The only reason there is any 
sense in re-writing old programs in Rust is because re-writing them in 
good, clear, modern C (or C++) is never going to happen - even though 
the results would be 

Re: More C type errors by default for GCC 14

[Florian Weimer via Gcc]

* Thomas Koenig via Gcc:

> So... using an error message as a crowbar to change people's behavior
> failed, at least partially.  And you only hear from the people who
> complain, not from those who are glad that they found errors that they
> would otherwise have missed.

Thank you for sharing the Fortran perspective.  I think the C changes
are a bit different.  Most of these fixes are of a localized nature, and
there is always an ugly escape hatch for missing function declarations
(write a prototype declaration right next to the call site).  Most
packages we fixed required a small number of changes, and where
maintainers reacted, they weren't opposed to making the changes (maybe
with one exception).  These changes do not create an ongoing maintenance
burden.

Admittedly, there are some packages where the sheer number of issues
makes patchings things up difficult, or the state (and presumed lack of
use) of a program may make creating patches look like a waste of time.
But in the Fedora corpus, these cases are quite rare.  Popular packages
for which we do not have a migration story yet are ksh, procmail, unzip,
zip.  For the latter three, part of the problem is that it's not clear
to what extent legacy systems (pre-C89, maybe even pre-K&R, without
 or ) still need to be supported.  These cases are
the exception, though.  In those cases, there could be a strong
incentive to make as few changes as possible (so telling the compiler to
keep accepting these obsolete constructs).

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Wed, 10 May 2023 14:41:27 +0200
> Cc: jwakely@gmail.com, fwei...@redhat.com, gcc@gcc.gnu.org,
>  ar...@aarsen.me
> From: Gabriel Ravier 
> 
> >>> 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"?

In any case, I was not not talking about bug-compatibility, I was
talking about being able to compile code which GCC was able to compile
in past versions.  Being able to compile that code is not a bug, it's
a feature.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> From: Marcin Jaczewski 
> Date: Wed, 10 May 2023 14:41:40 +0200
> 
> Did you even check if the compiler outpost is still correct?

Yes.

> You mention "validations and verifications", do you do the same
> with the new compiler?

Yes.  But that is a fraction of the effort needed when the source
changes.

> If you can't touch code then you SHOULD not upgrade the compiler.

As I tried to explain, this is not really possible, unless the entire
system is also kept without any changes, which is also impossible,
because hardware gets old and needs to be replaced, and newer hardware
doesn't support old systems.

> Any big project (like Linux) shows these two rules are critical,
> there were multiple cases of security bugs caused by subtle change
> in behavior of the compiler.
> Compiling very old code is lability if nobody knows how it should work and
> nobody maintains it. Who can give you guarantee that the result is correct?
> Very old programs should even by default reject new compilers by default until
> someone does not check if it correctly compiles on new compilers.

This is all true, but the same problems exist even if the programs
don't use outdated C dialect.  So these issues are independent, almost
orthogonal to the issue at hand.

Re: More C type errors by default for GCC 14

[David Brown via Gcc]

On 10/05/2023 15:10, Basile Starynkevitch wrote:

Hello all,

After a suggestion by Eric Gallager

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.


Eli Zaretskii  wrote on 10 may 2023, at 14:00


And that is just one example of perfectly valid reasons for not
wanting or not being able to make changes to pacify GCC.

Once again, my bother is not about "villains" who don't want to get
their act together, my bother is about cases such as the one above,
where the developers simply have no practical choice.

And please don't tell me they should use an older GCC, because as
systems go forward and are upgraded, older GCC will not work anymore.



My experience is that for safety critical software (per DOI 178C, 
embedded in aircrafts, or for the French covid breathing machine on 
https://github.com/Recovid/Controller ) the regulations, funders, and 
authorities requires a very specific version of GCC with very specific 
compilation flags.



Changing either the compiler (even from gcc-12.1 to gcc-12.2) or the 
compilation flags (even changing -O1 by -O2) requires written (on paper) 
approval by a large number of human persons, and formal certifications 
(eg ISO9001, ISO27001 procedures) and lots of checks and headaches.



I do know several persons making their living of these constraints.

I do know several corporations making a living from them (and keeping 
decade older GCC compiler binaries on many disks).


So I really think that for safety critical software (whose failure may 
impact lives) people are using an older (and well specified) GCC.



Of course, to compile an ordinary business web service (e-shop for 
clothes) with e.g. libonion (from https://github.com/davidmoreno/onion 
...) or to compile a zsh.org from source code (for or on a developer's 
laptop) the constraints are a lot lighter.


Regards!



In my line of work (small-systems embedded programming), the source for 
a program does not just include the C source code.  It includes the 
build system, compiler version, the flags used, and the library used - 
everything that can affect the resulting binary.  I realise I am far 
more paranoid about that kind of thing than the majority of developers, 
but it is also noteworthy that there is a trend towards reproducible 
builds in more mainstream development.


The oldest gcc I have on my machine is 2.95.3 for the 68k, from 1998.  I 
have some older compilers, but they are not gcc.


I wouldn't say I made a living out of this, but I have had a customer 
who was very happy that I could make a fix in a program I wrote 20 years 
previously, and could compile it with exactly the same tools as I used then.


One of the reasons I use gcc (in a world where companies are willing to 
pay $5000 for tools from the likes of Green Hills) is that I can keep 
the old versions around, and copy and use them at will.


And for those that are more demanding than me, they can of course 
archive the sources for gcc (and other parts of the toolchain).


Those that /really/ need old versions of the toolchain, can use old 
versions of the toolchain.  And if gcc 14 changes in such a way that 
distro maintainers can't use it to build ancient packages, then they 
should make gcc-13 a part of their base packages as well as current gcc, 
and ship gcc version 13 for as long as they ship "ed", "rn" and other 
software from the middle ages.

Re: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

On Wed, May 10, 2023 at 05:14:43PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 10 May 2023 14:41:27 +0200
> > Cc: jwakely@gmail.com, fwei...@redhat.com, gcc@gcc.gnu.org,
> >  ar...@aarsen.me
> > From: Gabriel Ravier 
> > 
> > >>> 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 
[[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

Re: More C type errors by default for GCC 14

[Thomas Koenig via Gcc]

On 10.05.23 14:03, Jakub Jelinek via Gcc wrote:

We do such changes several times a year, where we reject something that has
been previously accepted in older standards, admittedly mostly in C++.


... and in Fortran.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Wed, 10 May 2023 15:30:02 +0200
> From: David Brown via Gcc 
> 
> >>> If some developers want to ignore warnings, it is not the business of
> >>> GCC to improve them, even if you are right in assuming that they will
> >>> not work around errors like they work around warnings (and I'm not at
> >>> all sure you are right in that assumption).  But by _forcing_ these
> >>> errors on _everyone_, GCC will in effect punish those developers who
> >>> have good reasons for not changing the code.
> 
> What would those "good reasons" be, in your opinion?

For example, something that adversely affects GCC itself and its
ability to compile valid programs.

> On the other hand, continuing to accept old, outdated code by lax 
> defaults is punishing /current/ developers and users.  Why should 99.99% 
> of current developers have to enable extra errors to catch mistakes (and 
> we all make occasional mistakes in our coding - so they /should/ be 
> enabling these error flags)?

Adding a flag to a Makefile is infinitely easier than fixing old
sources in a way that they produce the same machine code.

> I do agree that backwards compatibility breaks should only be done for 
> good reasons.  But I think the reasons are good.

Not good enough, not for such a radical shift in the balance between
the two groups.

> > And no,
> > educating/forcing GCC users to use more modern dialect of C is not a
> > good reason.
> > 
> 
> Yes, it /is/ a good reason.

Not for a compiler.  A compiler is a tool, it is none of its business
to teach me what is and what isn't a good dialect in each particular
case.  Hinting on that, via warnings, is sufficient and perfectly
okay, but _forcing_ me is not.

> Consider why Rust has become the modern fad in programming.  People 
> claim it is because it is inherently safer than C and C++.  It is not. 
> There are really two reasons for it appearing to be safer.  One is that 
> the /defaults/ for the tools, and the language idioms, are safer than 
> the /defaults/ for C and C++ tools.  That makes it harder to make 
> mistakes.  The other is that it has no legacy of decades of old code and 
> old habits, and no newbie programmers copying those old styles.

Exactly.  We cannot reasonably expect that a compiler which needs to
support 50 years of legacy code to be as safe as a compiler for a
language invented yesterday afternoon.  People who want a safe
programming environment should not choose C as their first choice.

> So yes, anything that pushes C programmers into being better C 
> programmers is worth considering, IMHO.  We will never stamp out bad 
> programming, but we can try to help them - giving them better tools that 
> help them spot problems early is a step forward.

I agree, I'm just saying that warnings are helpful enough -- for those
who want to be helped.

> > Once again: it isn't "broken code".  It is dangerous code, and in some
> > cases unintentionally suspicious code.  But it isn't broken, because
> > GCC can compile it into a valid program, which, if the programmer
> > indeed meant that, will work and do its job.
> 
> Sweeping problems under the carpet and hoping no one trips over the 
> bumps is, at best, pushing problems down the road for future developers.

I'm not sweeping anything.  This is not GCC's problem to solve, that's
all.  If the developer avoids dealing with this problem, then he or
she might be sweeping the problem under the carpet.  But this is not
GCC's problem.

Re: More C type errors by default for GCC 14

[Joel Sherrill]

On Tue, May 9, 2023 at 5:46 PM Jonathan Wakely 
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
>

Thanks. We already  use -Wall which is documented to turn on the top two
as warnings at least.

Is int-conversion turned on as part of any of the more general -W arguments
(e.g. -Wall, -Wextra, -pedantic)? It's not listed in the manual and I was
wondering
if that was right or an oversight. Given this discussion, I would have
expected it
to be in -Wall.

--joel


> > i am a bit gun shy because I remember the move from GCC 3.3 to 3.4
> > where the improved strict alias checking gave us a LOT of warnings to
> > deal with and it felt overwhelming. I don't want to do that again.
> >
> > But I believe in letting the compiler get stricter and find things.
> Defaulting
> > to stricter checking is a good thing.
>
> The checks are already done, they're just warnings by default, and so
> easily missed/ignored when compiling large code bases.
>

Re: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

On Wed, May 10, 2023 at 10:10:37AM -0500, Joel Sherrill wrote:
> > > 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
> >
> 
> Thanks. We already  use -Wall which is documented to turn on the top two
> as warnings at least.
> 
> Is int-conversion turned on as part of any of the more general -W arguments
> (e.g. -Wall, -Wextra, -pedantic)? It's not listed in the manual and I was
> wondering
> if that was right or an oversight. Given this discussion, I would have
> expected it
> to be in -Wall.

-Wint-conversion is enabled by default.  You get the warning whenever not
using -w or -Wno-int-conversion, and error with -pedantic-errors.

Jakub

DDD-3.4.0 Debbugger GUI released

[Michael Eager]

DDD, the DATA DISPLAY DEBUGGER, version 3.4.0 has been released.

DDD is a graphical front end for GDB (and other debuggers) with an
intuitive interface and an interactive graphical display for data.
This release, the first since 2009, has been updated to support
current OS and library versions, improve the build process, fix a
number of bugs as well as make a number of enhancements.

DDD's maintainers are Stefan Eickler and Michael Eager.  Please
send questions or comments to mailto:d...@gnu.org.

Information about DDD can be found on the DDD project page:
https://www.gnu.org/software/ddd/

--
Michael Eager

Re: More C type errors by default for GCC 14

[Paul Koning via Gcc]

> On May 10, 2023, at 10:39 AM, Eli Zaretskii via Gcc  wrote:
> 
>> ...
>> Sweeping problems under the carpet and hoping no one trips over the 
>> bumps is, at best, pushing problems down the road for future developers.
> 
> I'm not sweeping anything.  This is not GCC's problem to solve, that's
> all.  If the developer avoids dealing with this problem, then he or
> she might be sweeping the problem under the carpet.  But this is not
> GCC's problem.

Agreed.  -Wall -Werror exists for a reason, and choosing to use that it helpful 
but not necessarily feasible for everyone if confronted with old mouldy code.

I remember a wonderful article (out of MIT?) explaining a whole bunch of 
somewhat-surprising C standard rules and why they allowed the compiler to do 
things that many people don't expect.  As I recall, a lot of those were things 
that Linux didn't want and therefore would suppress with suitable -f 
flags.  "Strict aliasing" may have been one of those -- I still remember my 
somewhat-surprised reaction when I first learned what that is and why my 
"obvious" C code was not valid.

I also agree with Eli that using C to write highly reliable code is, shall we 
say, quite a challenge.  The language just isn't well suited for that.  But GCC 
also supports Ada :-)  and now Modula-2.

paul

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Wed, 10 May 2023 16:22:26 +0200
> From: Jakub Jelinek 
> Cc: Gabriel Ravier , jwakely@gmail.com,
> fwei...@redhat.com, gcc@gcc.gnu.org, ar...@aarsen.me
> 
> > > 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.

If some program is plainly invalid, not just because the criteria of
validity have shifted, then yes, such a program should be rejected.

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

Yes, and that's the crucial (for me) difference: what is currently
considered invalid was valid in the past, and so there's a set of
rules under which that kind of program can produce valid machine code.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Wed, 10 May 2023 16:31:23 +0200
> From: Thomas Koenig via Gcc 
> 
> On 10.05.23 14:03, Jakub Jelinek via Gcc wrote:
> > We do such changes several times a year, where we reject something that has
> > been previously accepted in older standards, admittedly mostly in C++.
> 
> ... and in Fortran.

Tell me about it.  Just a couple of months ago I needed to compile the
venerable Adventure game from 1977 sources (for my grandson).  That
was no fun, although there was, of course, nothing wrong with the
source code, and once I tweaked gfortran into accepting that flavor of
Fortran, it compiled and ran just fine.

Re: More C type errors by default for GCC 14

[David Brown via Gcc]

On 10/05/2023 16:14, Eli Zaretskii via Gcc wrote:

Date: Wed, 10 May 2023 14:41:27 +0200
Cc: jwakely@gmail.com, fwei...@redhat.com, gcc@gcc.gnu.org,
  ar...@aarsen.me
From: Gabriel Ravier 


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 cases where the C standards (plus documented gcc extensions) 
have syntax or constraint requirements, but code which breaks these 
requirements is accepted by the compiler.  For example, if the compiler 
accepted "long long long int" as a type, that would be an 
"accepts-invalid" bug.  They are important for two reasons.  One is that 
they mean the compiler fails to help the developer catch the mistake in 
their code.  The other is that the code might have an inconsistent 
interpretation, and that might change in the future.  In the 
hypothetical example of a three-long int, a current compiler might treat 
it as a "long long", while a future standard might add support for it as 
a new type with minimum 128-bit size.



In any case, I was not not talking about bug-compatibility, I was
talking about being able to compile code which GCC was able to compile
in past versions.  Being able to compile that code is not a bug, it's
a feature.



No, being able to compile /incorrect/ code by default is a bug.  It is 
not helpful.


(The compiler cannot, of course, spot /all/ mistakes - the gcc 
developers are a smart group, but I think asking them to solve the 
Halting Problem is a bit much!)


I've seen this kind of argument many times - "The compiler used to 
accept my code and give the results I wanted, and now newer compiler 
versions make a mess of it".  The cause is almost invariably undefined 
behaviour, but it can occasionally be through changes to the standards 
such as removal of old behaviour or other differences in the 
interpretation of code (there were a number of incompatibilities between 
K&R and C90, and between C90 and C99).


The compiler is under /no/ obligation to compile undefined behaviour in 
the same way as it might have done for a particular piece of code.  It 
is under /no/ obligation to continue to accept incorrect or invalid 
code, just because it used to accept it.  It /is/ - IMHO - under an 
obligation to do what it can to help spot problems in code and help 
developers get good quality correct code in the end.  If it fails to do 
that, people will, and should, move to using different tools.


New compiler versions are not required to do two's complement wrapping 
of signed integer overflow, even though old broken code might have been 
written under the assumption that it did and even though older, less 
powerful versions of the compiler might have compiled that code into 
something the developer wanted.  In the same way, new compiler versions 
are not required to support syntax that has been dead for decades - at 
least not by default.  (Unlike most other compilers, gcc developers go 
far out of their way to support such outdated and incorrect code - all 
they ask is that people use non-default flags to get such non-standard 
syntax and semantics.)


If the gcc developers really were required to continue to compile /all/ 
programs that compiled before, with the same results, then the whole gcc 
project can be stopped.  The only way to ensure perfect backwards 
compatibility would be to stop development, and no longer release any 
new versions of the compiler.  That is the logical consequence of "it 
used to compile (with defaults or a given set of flags), so it should 
continue to compile (with these same flags)" - assuming "compile" here 
means "giving the same resulting behaviour in the executable" rather 
than just "giving an executable that may or may not work".


Clearly, you don't mean gcc development should stop.  That means a line 
must be drawn, and some code that compiled with older gcc will not 
compile with newer gcc.  The only question is where the line should be.

Re: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

On Wed, May 10, 2023 at 06:30:40PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 10 May 2023 16:22:26 +0200
> > From: Jakub Jelinek 
> > Cc: Gabriel Ravier , jwakely@gmail.com,
> > fwei...@redhat.com, gcc@gcc.gnu.org, ar...@aarsen.me
> > 
> > > > 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.
> 
> If some program is plainly invalid, not just because the criteria of
> validity have shifted, then yes, such a program should be rejected.

Many of the accepts-invalid cases are when something used to be valid in some
older standard and is not valid in a newer standard, often even changes
meaning completely in even newer standard.
Examples include e.g. the auto keyword, which means something completely
different in C++11 and later than what it meant in C++98, or say comma in
array reference in C++17 vs. C++20 vs. C++23 (a[1, 2] is the same as a[(1, 2)]
in C++17, got deprecated in C++20 and is ill-formed or changed meaning
in C++23 (multi-dimensional array operator).
Or any time something that wasn't a keyword in older standard version
and is a keyword in a newer standard.
alignas/alignof/nullptr/static_assert/thread_local in C++11 and C23,
char16_t/char32_t/constexpr/decltype/noexcept in C++11,
constinit/consteval in C++20,
bool/false/true/typeof_unqual in C23.

int bool = 1;
is completely valid C17 if one doesn't include  header,
or
int static_assert = 2;
valid C17 if one doesn't include 
etc.  These used to compile and will no any longer wheen using -std=c2x or
in a few years when -std=gnu23 becomes the default will not compile by
default, even when it used to be valid C17.
And here are talking about code that wasn't valid already in C99...

Jakub

Re: More C type errors by default for GCC 14

[David Brown via Gcc]

On 10/05/2023 16:39, Eli Zaretskii via Gcc wrote:

Date: Wed, 10 May 2023 15:30:02 +0200
From: David Brown via Gcc 


If some developers want to ignore warnings, it is not the business of
GCC to improve them, even if you are right in assuming that they will
not work around errors like they work around warnings (and I'm not at
all sure you are right in that assumption).  But by _forcing_ these
errors on _everyone_, GCC will in effect punish those developers who
have good reasons for not changing the code.


What would those "good reasons" be, in your opinion?


For example, something that adversely affects GCC itself and its
ability to compile valid programs.


If gcc itself contains code that relies on outdated features, these 
should be fixed in the gcc source code.  It is one thing to suggest that 
a project that has been "maintenance only" for several decades cannot 
reasonably be updated, but that does not apply to current programs like gcc.





On the other hand, continuing to accept old, outdated code by lax
defaults is punishing /current/ developers and users.  Why should 99.99%
of current developers have to enable extra errors to catch mistakes (and
we all make occasional mistakes in our coding - so they /should/ be
enabling these error flags)?


Adding a flag to a Makefile is infinitely easier than fixing old
sources in a way that they produce the same machine code.



The suggestion has been - always - that support for old syntaxes be 
retained.  But that flag should be added to the makefiles of the 0.01% 
of projects that need it because they have old code - not the 99.99% of 
projects that are written (or updated) this century.



I do agree that backwards compatibility breaks should only be done for
good reasons.  But I think the reasons are good.


Not good enough, not for such a radical shift in the balance between
the two groups.



Do you have any reason to believe that the old code group is of relevant 
size?  I think it is quite obvious that I have been pulling percentages 
out of thin air, but can you justify claiming anything different?


I mean, if gcc simply added a default "-Werror=implicit" flag in the 
release candidate for gcc-14, how many people do you think would 
actually complain?  I'd guess that there would be far fewer complaints 
than there are posts in this thread discussing whether or not it's a 
good idea.




And no,
educating/forcing GCC users to use more modern dialect of C is not a
good reason.



Yes, it /is/ a good reason.


Not for a compiler.  A compiler is a tool, it is none of its business
to teach me what is and what isn't a good dialect in each particular
case.  Hinting on that, via warnings, is sufficient and perfectly
okay, but _forcing_ me is not.


Again - did you miss the point about people who really want to work with 
old code can do so, by picking the right flag(s) ?





Consider why Rust has become the modern fad in programming.  People
claim it is because it is inherently safer than C and C++.  It is not.
There are really two reasons for it appearing to be safer.  One is that
the /defaults/ for the tools, and the language idioms, are safer than
the /defaults/ for C and C++ tools.  That makes it harder to make
mistakes.  The other is that it has no legacy of decades of old code and
old habits, and no newbie programmers copying those old styles.


Exactly.  We cannot reasonably expect that a compiler which needs to
support 50 years of legacy code to be as safe as a compiler for a
language invented yesterday afternoon.  People who want a safe
programming environment should not choose C as their first choice.



We cannot expect a /language/ with a 50 year history to be as safe as a 
modern one.  But we can expect a /compiler/ released /today/ to be as 
safe as it can be made /today/.


I agree that C is not the best choice of language for many people. 
Actually, I'd say that most people who program in C would be better off 
programming in something else.  And most programs that are written in C 
could be better in a different language.  But when C /is/ the right 
choice - or even when it is the choice made despite being the wrong 
choice, I want it to be /good/ C, and I want tools to help out there as 
best they possibly can.  That includes good default flags, because not 
all gcc users are experts on gcc flags.


My ideal, actually, would be that gcc has "-Wall -Wextra" by default, 
trying to help developers from the get-go.  It should also have an flag 
"-sep" that disables all warnings and uses lax modes, for people using 
it to build software provided by others and they want nothing to do with 
the source code.  But of course that is not the ideal situation for 
everyone else!


(See  for an 
explanation behind the "-sep" flag.)




So yes, anything that pushes C programmers into being better C
programmers is worth considering, IMHO.  We will never stamp out bad
programming, but we can tr

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Wed, 10 May 2023 17:58:16 +0200
> From: David Brown via Gcc 
> 
> > In any case, I was not not talking about bug-compatibility, I was
> > talking about being able to compile code which GCC was able to compile
> > in past versions.  Being able to compile that code is not a bug, it's
> > a feature.
> 
> No, being able to compile /incorrect/ code by default is a bug.  It is 
> not helpful.

I actually agree; we just have different definitions of "incorrect".

> I've seen this kind of argument many times - "The compiler used to 
> accept my code and give the results I wanted, and now newer compiler 
> versions make a mess of it".

But we are not talking about some random code that just happened to
slip through cracks as a side effect of the particular implementation.
We are talking about code that was perfectly valid, had well-defined
semantics, and produced a working program.  I don't care about the
former; I do care about the latter.

> If the gcc developers really were required to continue to compile /all/ 
> programs that compiled before, with the same results, then the whole gcc 
> project can be stopped.

You will have to explain this to me.  Just stating this is not enough.
How will accepting K&R stop GCC development?

As for the two's complement wrapping example: I'm okay with having
this broken because some useful feature requires to modify the basic
arithmetics and instructions emitted by GCC in a way that two's
complement wrapping can no longer be supported.  _That_ is exactly an
example of a "good reason" for backward incompatibility: GCC must do
something to compile valid programs, and that something is
incompatible with old programs which depended on some de-facto
standard that is nowadays considered UB.  But the case in point is not
like that, AFAIU: in this case, GCC will deliberately break a program
although it could compile it without adversely affecting its output
for any other valid program.  To me, this would be an arbitrary
decision of the GCC developers to break someone's code that has no
"good reasons" which I could understand and respect, let alone accept.

> The only way to ensure perfect backwards compatibility would be to
> stop development, and no longer release any new versions of the
> compiler.  That is the logical consequence of "it used to compile
> (with defaults or a given set of flags), so it should continue to
> compile (with these same flags)" - assuming "compile" here means
> "giving the same resulting behaviour in the executable" rather than
> just "giving an executable that may or may not work".

This is not the logical consequence, this is reductio ad absurdum, a
kind of strawman.  There's no need to go to such extremes, because
"good reasons" for breaking backward compatibility do exist.  I'm a
co-maintainer of GNU Emacs, a program that attempts not to break
habits of users burned into their muscle memories for the last 30
years; don't you think I know a bit what I'm talking about?

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Wed, 10 May 2023 18:02:53 +0200
> From: Jakub Jelinek 
> Cc: gabrav...@gmail.com, jwakely@gmail.com, fwei...@redhat.com,
> gcc@gcc.gnu.org, ar...@aarsen.me
> 
> > If some program is plainly invalid, not just because the criteria of
> > validity have shifted, then yes, such a program should be rejected.
> 
> Many of the accepts-invalid cases are when something used to be valid in some
> older standard and is not valid in a newer standard, often even changes
> meaning completely in even newer standard.
> Examples include e.g. the auto keyword, which means something completely
> different in C++11 and later than what it meant in C++98, or say comma in
> array reference in C++17 vs. C++20 vs. C++23 (a[1, 2] is the same as a[(1, 2)]
> in C++17, got deprecated in C++20 and is ill-formed or changed meaning
> in C++23 (multi-dimensional array operator).
> Or any time something that wasn't a keyword in older standard version
> and is a keyword in a newer standard.
> alignas/alignof/nullptr/static_assert/thread_local in C++11 and C23,
> char16_t/char32_t/constexpr/decltype/noexcept in C++11,
> constinit/consteval in C++20,
> bool/false/true/typeof_unqual in C23.
> 
> int bool = 1;
> is completely valid C17 if one doesn't include  header,
> or
> int static_assert = 2;
> valid C17 if one doesn't include 
> etc.  These used to compile and will no any longer wheen using -std=c2x or
> in a few years when -std=gnu23 becomes the default will not compile by
> default, even when it used to be valid C17.

The examples you gave are the ones I could accept as "good reasons"
for breaking backward compatibility.  That's because breaking that is
unavoidable if GCC wants to support the newer standard.

That is not the case we are discussing, AFAIU.  Or at least no one has
yet explained why accepting those old K&R programs will adversely
affect the ability of GCC to compile C2x programs.

Re: More C type errors by default for GCC 14

[Richard Biener via Gcc]

> Am 10.05.2023 um 18:31 schrieb Eli Zaretskii via Gcc :
> 
> 
>> 
>> Date: Wed, 10 May 2023 18:02:53 +0200
>> From: Jakub Jelinek 
>> Cc: gabrav...@gmail.com, jwakely@gmail.com, fwei...@redhat.com,
>>gcc@gcc.gnu.org, ar...@aarsen.me
>> 
>>> If some program is plainly invalid, not just because the criteria of
>>> validity have shifted, then yes, such a program should be rejected.
>> 
>> Many of the accepts-invalid cases are when something used to be valid in some
>> older standard and is not valid in a newer standard, often even changes
>> meaning completely in even newer standard.
>> Examples include e.g. the auto keyword, which means something completely
>> different in C++11 and later than what it meant in C++98, or say comma in
>> array reference in C++17 vs. C++20 vs. C++23 (a[1, 2] is the same as a[(1, 
>> 2)]
>> in C++17, got deprecated in C++20 and is ill-formed or changed meaning
>> in C++23 (multi-dimensional array operator).
>> Or any time something that wasn't a keyword in older standard version
>> and is a keyword in a newer standard.
>> alignas/alignof/nullptr/static_assert/thread_local in C++11 and C23,
>> char16_t/char32_t/constexpr/decltype/noexcept in C++11,
>> constinit/consteval in C++20,
>> bool/false/true/typeof_unqual in C23.
>> 
>> int bool = 1;
>> is completely valid C17 if one doesn't include  header,
>> or
>> int static_assert = 2;
>> valid C17 if one doesn't include 
>> etc.  These used to compile and will no any longer wheen using -std=c2x or
>> in a few years when -std=gnu23 becomes the default will not compile by
>> default, even when it used to be valid C17.
> 
> The examples you gave are the ones I could accept as "good reasons"
> for breaking backward compatibility.  That's because breaking that is
> unavoidable if GCC wants to support the newer standard.
> 
> That is not the case we are discussing, AFAIU.  Or at least no one has
> yet explained why accepting those old K&R programs will adversely
> affect the ability of GCC to compile C2x programs.

But we are discussing to reject K&R programs only when C99 or later standards 
are applied (those are applied by default)

Richard 

Re: More C type errors by default for GCC 14

[Joel Sherrill]

On Wed, May 10, 2023 at 10:14 AM Jakub Jelinek  wrote:

> On Wed, May 10, 2023 at 10:10:37AM -0500, Joel Sherrill wrote:
> > > > 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
> > >
> >
> > Thanks. We already  use -Wall which is documented to turn on the top two
> > as warnings at least.
> >
> > Is int-conversion turned on as part of any of the more general -W
> arguments
> > (e.g. -Wall, -Wextra, -pedantic)? It's not listed in the manual and I was
> > wondering
> > if that was right or an oversight. Given this discussion, I would have
> > expected it
> > to be in -Wall.
>
> -Wint-conversion is enabled by default.  You get the warning whenever not
> using -w or -Wno-int-conversion, and error with -pedantic-errors.
>

Thanks. That isn't clear in the manual.

Is there a list of warnings included by default? I'm guessing that it might
be all the ones where the manual lists only -Wno-ABC.

And again, I don't mind getting poked when the code does something
questionable or undefined. Doesn't make it easy to fix or even magically
give us all time to address the issues but better to know.

--joel

>
> Jakub
>
>

std::format not listed on the C++ Standards support page

[C. Heide via Gcc]

Hello, just a note that support for std::format (P0645R10) does
not seem to be listed anywhere on the current C++ Standards
Support page (https://gcc.gnu.org/projects/cxx-status.html).

I was trying to figure out if it was supposed to be in the 12.3
release or not, but based on PR104166 I guess it's 13+ only. But
just in case anyone else is looking for this info... :)

Thanks,
- C.

Re: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

On Wed, May 10, 2023 at 11:36:10AM -0500, Joel Sherrill wrote:
> On Wed, May 10, 2023 at 10:14 AM Jakub Jelinek  wrote:
> 
> > On Wed, May 10, 2023 at 10:10:37AM -0500, Joel Sherrill wrote:
> > > > > 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
> > > >
> > >
> > > Thanks. We already  use -Wall which is documented to turn on the top two
> > > as warnings at least.
> > >
> > > Is int-conversion turned on as part of any of the more general -W
> > arguments
> > > (e.g. -Wall, -Wextra, -pedantic)? It's not listed in the manual and I was
> > > wondering
> > > if that was right or an oversight. Given this discussion, I would have
> > > expected it
> > > to be in -Wall.
> >
> > -Wint-conversion is enabled by default.  You get the warning whenever not
> > using -w or -Wno-int-conversion, and error with -pedantic-errors.
> >
> 
> Thanks. That isn't clear in the manual.
> 
> Is there a list of warnings included by default? I'm guessing that it might
> be all the ones where the manual lists only -Wno-ABC.
> 
> And again, I don't mind getting poked when the code does something
> questionable or undefined. Doesn't make it easy to fix or even magically
> give us all time to address the issues but better to know.

awk '/^W/{w=$1;getline;if ($0 ~ /Init\(1\)/)print w}' gcc/{,*/}*.opt | sort -u
Waddress-of-packed-member
Waggressive-loop-optimizations
Walign-commons
Wanalyzer-allocation-size
Wanalyzer-deref-before-check
Wanalyzer-double-fclose
Wanalyzer-double-free
Wanalyzer-exposure-through-output-file
Wanalyzer-exposure-through-uninit-copy
Wanalyzer-fd-access-mode-mismatch
Wanalyzer-fd-double-close
Wanalyzer-fd-leak
Wanalyzer-fd-phase-mismatch
Wanalyzer-fd-type-mismatch
Wanalyzer-fd-use-after-close
Wanalyzer-fd-use-without-check
Wanalyzer-file-leak
Wanalyzer-free-of-non-heap
Wanalyzer-imprecise-fp-arithmetic
Wanalyzer-infinite-recursion
Wanalyzer-jump-through-null
Wanalyzer-malloc-leak
Wanalyzer-mismatching-deallocation
Wanalyzer-null-argument
Wanalyzer-null-dereference
Wanalyzer-out-of-bounds
Wanalyzer-possible-null-argument
Wanalyzer-possible-null-dereference
Wanalyzer-putenv-of-auto-var
Wanalyzer-shift-count-negative
Wanalyzer-shift-count-overflow
Wanalyzer-stale-setjmp-buffer
Wanalyzer-tainted-allocation-size
Wanalyzer-tainted-array-index
Wanalyzer-tainted-assertion
Wanalyzer-tainted-divisor
Wanalyzer-tainted-offset
Wanalyzer-tainted-size
Wanalyzer-unsafe-call-within-signal-handler
Wanalyzer-use-after-free
Wanalyzer-use-of-pointer-in-stale-stack-frame
Wanalyzer-use-of-uninitialized-value
Wanalyzer-va-arg-type-mismatch
Wanalyzer-va-list-exhausted
Wanalyzer-va-list-leak
Wanalyzer-va-list-use-after-va-end
Wanalyzer-write-to-const
Wanalyzer-write-to-string-literal
Wattribute-alias=
Wattributes
Wattribute-warning
Wbuiltin-declaration-mismatch
Wbuiltin-macro-redefined
Wc++11-extensions
Wc++14-extensions
Wc++17-extensions
Wc++20-extensions
Wc++23-extensions
Wcannot-profile
Wchanges-meaning
Wclass-conversion
Wcomplain-wrong-lang
Wconversion-null
Wcoverage-invalid-line-number
Wcoverage-mismatch
Wcpp
Wdelete-incomplete
Wdeprecated
Wdeprecated-declarations
Wdesignated-init
Wdiscarded-array-qualifiers
Wdiscarded-qualifiers
Wdiv-by-zero
Wendif-labels
Wexceptions
Wfree-nonheap-object
Wif-not-aligned
Wignored-attributes
Winaccessible-base
Wincompatible-pointer-types
Winherited-variadic-ctor
Winit-list-lifetime
Wint-conversion
Winterference-size
Wint-to-pointer-cast
Winvalid-memory-model
Winvalid-offsetof
Wliteral-suffix
Wlto-type-mismatch
Wmissing-profile
Wmissing-requires
Wmissing-template-keyword
Wnonportable-cfstrings
Wnon-template-friend
WNSObject-attribute
Wobjc-root-class
Wodr
Woverflow
Woverride-init-side-effects
Woverwrite-recursive
Wpmf-conversions
Wpointer-compare
Wpointer-to-int-cast
Wpragmas
Wprio-ctor-dtor
Wproperty-assign-default
Wprotocol
Wpsabi
Wreturn-local-addr
Wscalar-storage-order
Wshadow-ivar
Wshift-count-negative
Wshift-count-overflow
Wsizeof-array-argument
Wstringop-overread
Wsubobject-linkage
Wswitch-bool
Wswitch-outside-range
Wswitch-unreachable
Wsync-nand
Wterminate
Wtsan
Wunderflow
Wunicode
Wunused-result
Wvarargs
Wvexing-parse
Wvirtual-move-assign
Wxor-used-as-pow

Of course, e.g. the -Wanalyzer* warnings are doing something only if
-fanalyzer, or say -Wtsan if -fsanitize=thread etc.

Jakub

Re: std::format not listed on the C++ Standards support page

[Jakub Jelinek via Gcc]

On Wed, May 10, 2023 at 10:38:02AM -0600, C. Heide via Gcc wrote:
> Hello, just a note that support for std::format (P0645R10) does
> not seem to be listed anywhere on the current C++ Standards
> Support page (https://gcc.gnu.org/projects/cxx-status.html).
> 
> I was trying to figure out if it was supposed to be in the 12.3
> release or not, but based on PR104166 I guess it's 13+ only. But
> just in case anyone else is looking for this info... :)

It is a library feature, and https://gcc.gnu.org/projects/cxx-status.html
only documents core language features.
Library feature implementation status is documented in the libstdc++
manual, so
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#manual.intro.status.iso

Jakub

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Wed, 10 May 2023 18:20:50 +0200
> From: David Brown via Gcc 
> 
> > Adding a flag to a Makefile is infinitely easier than fixing old
> > sources in a way that they produce the same machine code.
> 
> The suggestion has been - always - that support for old syntaxes be 
> retained.  But that flag should be added to the makefiles of the 0.01% 
> of projects that need it because they have old code - not the 99.99% of 
> projects that are written (or updated) this century.

Percents don't count when you are the one who is in trouble.

> > Exactly.  We cannot reasonably expect that a compiler which needs to
> > support 50 years of legacy code to be as safe as a compiler for a
> > language invented yesterday afternoon.  People who want a safe
> > programming environment should not choose C as their first choice.
> 
> We cannot expect a /language/ with a 50 year history to be as safe as a 
> modern one.  But we can expect a /compiler/ released /today/ to be as 
> safe as it can be made /today/.

Not if the compiler should support legacy code, we can't.

Anyway, we are repeating ourselves.

Re: std::format not listed on the C++ Standards support page

[Jonathan Wakely via Gcc]

On Wed, 10 May 2023 at 17:47, Jakub Jelinek via Gcc  wrote:
>
> On Wed, May 10, 2023 at 10:38:02AM -0600, C. Heide via Gcc wrote:
> > Hello, just a note that support for std::format (P0645R10) does
> > not seem to be listed anywhere on the current C++ Standards
> > Support page (https://gcc.gnu.org/projects/cxx-status.html).
> >
> > I was trying to figure out if it was supposed to be in the 12.3
> > release or not, but based on PR104166 I guess it's 13+ only. But
> > just in case anyone else is looking for this info... :)
>
> It is a library feature, and https://gcc.gnu.org/projects/cxx-status.html
> only documents core language features.
> Library feature implementation status is documented in the libstdc++
> manual, so
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#manual.intro.status.iso


I'm working on a patch to update the library docs. I didn't get it
done in time for 13.1 though.

Re: std::format not listed on the C++ Standards support page

[Jakub Jelinek via Gcc]

On Wed, May 10, 2023 at 06:45:55PM +0200, Jakub Jelinek via Gcc wrote:
> On Wed, May 10, 2023 at 10:38:02AM -0600, C. Heide via Gcc wrote:
> > Hello, just a note that support for std::format (P0645R10) does
> > not seem to be listed anywhere on the current C++ Standards
> > Support page (https://gcc.gnu.org/projects/cxx-status.html).
> > 
> > I was trying to figure out if it was supposed to be in the 12.3
> > release or not, but based on PR104166 I guess it's 13+ only. But
> > just in case anyone else is looking for this info... :)
> 
> It is a library feature, and https://gcc.gnu.org/projects/cxx-status.html
> only documents core language features.
> Library feature implementation status is documented in the libstdc++
> manual, so
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#manual.intro.status.iso

Though, that page hasn't been updated for std::format yet.
https://en.cppreference.com/w/cpp/compiler_support documents that though.

Jakub

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> From: Richard Biener 
> Date: Wed, 10 May 2023 18:33:53 +0200
> Cc: Jakub Jelinek , gabrav...@gmail.com,
>  jwakely@gmail.com, fwei...@redhat.com, gcc@gcc.gnu.org, ar...@aarsen.me
> 
> 
> 
> > Am 10.05.2023 um 18:31 schrieb Eli Zaretskii via Gcc :
> > The examples you gave are the ones I could accept as "good reasons"
> > for breaking backward compatibility.  That's because breaking that is
> > unavoidable if GCC wants to support the newer standard.
> > 
> > That is not the case we are discussing, AFAIU.  Or at least no one has
> > yet explained why accepting those old K&R programs will adversely
> > affect the ability of GCC to compile C2x programs.
> 
> But we are discussing to reject K&R programs only when C99 or later standards 
> are applied (those are applied by default)

I understand, but I don't see the relevance.  Are you saying that
"-std=c99" accepts _only_ C99 valid constructs?  What about gnu99?

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Wed, 10 May 2023 at 17:36, Joel Sherrill  wrote:
>
>
>
> On Wed, May 10, 2023 at 10:14 AM Jakub Jelinek  wrote:
>>
>> On Wed, May 10, 2023 at 10:10:37AM -0500, Joel Sherrill wrote:
>> > > > 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
>> > >
>> >
>> > Thanks. We already  use -Wall which is documented to turn on the top two
>> > as warnings at least.
>> >
>> > Is int-conversion turned on as part of any of the more general -W arguments
>> > (e.g. -Wall, -Wextra, -pedantic)? It's not listed in the manual and I was
>> > wondering
>> > if that was right or an oversight. Given this discussion, I would have
>> > expected it
>> > to be in -Wall.
>>
>> -Wint-conversion is enabled by default.  You get the warning whenever not
>> using -w or -Wno-int-conversion, and error with -pedantic-errors.
>
>
> Thanks. That isn't clear in the manual.

See https://gcc.gnu.org/onlinedocs/gcc/Invoking-GCC.html which says:

"Many options have long names starting with ‘-f’ or with ‘-W’—for
example, -fmove-loop-invariants, -Wformat and so on. Most of these
have both positive and negative forms; the negative form of -ffoo is
-fno-foo. This manual documents only one of these two forms, whichever
one is not the default. "

And the manual documents the -Wno-int-conversion form, because
-Wint-conversion is the default:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wno-int-conversion

Re: More C type errors by default for GCC 14

[Joseph Myers]

On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:

> That is not the case we are discussing, AFAIU.  Or at least no one has
> yet explained why accepting those old K&R programs will adversely
> affect the ability of GCC to compile C2x programs.

At block scope,

  auto x = 1.5;

declares x to have type double in C2x (C++-style auto), but type int in 
C89 (and is invalid for versions in between).  In this case, there is an 
incompatible semantic change between implicit int and C++-style auto.  
Giving an error before we make -std=gnu2x the default seems like a 
particularly good idea, to further alert anyone who has been ignoring the 
warnings about implicit int that semantics will change incompatibly.

In cases where the standard requires a diagnostic, some are errors, some 
are pedwarns-by-default or unconditional pedwarns, some are 
pedwarns-if-pedantic - the choice depending on how suspicious the 
construct in question is and whether it corresponds to a meaningful 
extension (this is not making an automatic choice for every such situation 
in the standard, it's a case-by-case judgement by maintainers).  By now, 
the cases discussed in this thread are sufficiently suspicious - 
sufficiently likely to result in unintended execution at runtime (not, of 
course, reliably detected because programs with such dodgy code are very 
unlikely to have thorough automated tests covering all their code) - that 
is it in the interests of users for them to be errors by default (for C99 
and later modes, in the cases that were valid in C89).

It might also make sense to review other pedwarns-by-default and 
unconditional pedwarns to consider if any of those should be errors by 
default, though I suspect most of those are less significant.

Enabling some of -Wall by default (as warnings, not errors) might well 
also be beneficial to users, though case would be needed to exclude those 
warnings that involve stylistic choices (e.g. -Wparentheses) or have false 
positives that are hard to fix - not all of -Wall is for code that is 
objectively suspicious independent of the chosen coding style.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: std::format not listed on the C++ Standards support page

[Jonathan Wakely via Gcc]

On Wed, 10 May 2023 at 17:38, C. Heide via Gcc  wrote:
>
> Hello, just a note that support for std::format (P0645R10) does
> not seem to be listed anywhere on the current C++ Standards
> Support page (https://gcc.gnu.org/projects/cxx-status.html).
>
> I was trying to figure out if it was supposed to be in the 12.3
> release or not, but based on PR104166 I guess it's 13+ only. But
> just in case anyone else is looking for this info... :)

It's the very first thing listed in the libstdc++ release notes for 13:
https://gcc.gnu.org/gcc-13/changes.html#libstdcxx

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Wed, 10 May 2023 17:08:18 +
> From: Joseph Myers 
> CC: Jakub Jelinek , ,
>   , , ,
>   
> 
> On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
> 
> > That is not the case we are discussing, AFAIU.  Or at least no one has
> > yet explained why accepting those old K&R programs will adversely
> > affect the ability of GCC to compile C2x programs.
> 
> At block scope,
> 
>   auto x = 1.5;
> 
> declares x to have type double in C2x (C++-style auto), but type int in 
> C89 (and is invalid for versions in between).  In this case, there is an 
> incompatible semantic change between implicit int and C++-style auto.  

So in this case, I'm okay with GCC changing the default behavior at
some point, such that the above is interpreted as C2x mandates, which
will then break some old programs.  This is another example of a "good
reason" for changing behavior in backward-incompatible ways.

But please note that emitting an error is not required, at least in my
book.  I assume GCC emits a warning about this already, and that
should be enough, until such time as you decide to adopt the C2x
interpretation of that by default -- without going through the
intermediate stage of erroring out by default.

> Giving an error before we make -std=gnu2x the default seems like a 
> particularly good idea, to further alert anyone who has been ignoring the 
> warnings about implicit int that semantics will change incompatibly.

FWIW, I don't see a reason to give an error.

> Enabling some of -Wall by default (as warnings, not errors) might well 
> also be beneficial to users, though case would be needed to exclude those 
> warnings that involve stylistic choices (e.g. -Wparentheses) or have false 
> positives that are hard to fix - not all of -Wall is for code that is 
> objectively suspicious independent of the chosen coding style.

IMO and IME, anything is better than errors.  I presume everyone on
this list is familiar with the frustrating experience of having a
large program suddenly fail to build with some strange-looking error
message, which launches you down the rabbit hole of trying to
understand what happened and why.  And if that happens as part of
running the configure script (as I understand is one of the potential
victims of that), that is even scarier, because most people don't read
the configure script and don't always understand what is going on
there and why; it is also not very easy to debug.

So I urge the GCC developers to try to avoid errors as much as
possible, as long as GCC is capable to produce code with some widely
adopted semantics, and break backward compatibility only if otherwise
GCC will be unable to implement newer features.  (And to be pedantic,
I don't consider new warnings to be new features in this context.)

gcc-10-20230510 is now available

[GCC Administrator via Gcc]

Snapshot gcc-10-20230510 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/10-20230510/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-10 revision d2ddb2b9ad2b601a0e1929cefcdf21f81f7c99f2

You'll find:

 gcc-10-20230510.tar.xz   Complete GCC

  SHA256=5dff3dfb9833f7c7080f0ded78ef675c3046fcd0456eaf2cc2e34fc6ce75e2b7
  SHA1=556fe66816e3c89bc3caaf7cbef3e0225d4b7ae5

Diffs from 10-20230503 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: More C type errors by default for GCC 14

[James K. Lowden]

On Tue, 9 May 2023 23:45:50 +0100
Jonathan Wakely via Gcc  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!

This, it seems to me, is the crux of the question.  Code that does not
conform to the standard should produce an error.  Code that can be
compiled correctly, per the specification, but might not be what the
user intended, is a candidate for a warning.  

If the proposed changes catch true errors -- not just dubious
constructs -- that were previously allowed, well, that's the price of
progress.  That's the compiler getting better at distinguishing between
code conformant and not.  

Section 2.1 "C Language" of the manual states that, with no option
specified on the command line, the default standard is -std=gnu17.  

Part of the proposal IIUC is to treat undeclared functions as an error.
Function prototypes have been required afaik since c99.  If
that's correct, then letting them pass without error is a mistake for
-std=c99 and above.  

As to the default, is anyone suggesting that gnu17 -- i.e., c17 with
GNU extensions -- includes ignoring missing function prototypes?  That
to me would be an odd definition of "extension".  

The user who has old code that does not meet the c99 standard but Just
Works nonetheless has a direct route to compiling that code without
complaint: -std=c90.  It says so right there in the fine manual.  

It's that simple.  The code is either in spec and compiles without
error, or it is not and does not.  The only debate is over what "the
spec" is, and what warnings the user might want for conforming code.  

--jkl

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Thu, 11 May 2023 at 00:18, James K. Lowden  wrote:
>
> On Tue, 9 May 2023 23:45:50 +0100
> Jonathan Wakely via Gcc  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!
>
> This, it seems to me, is the crux of the question.  Code that does not
> conform to the standard should produce an error.

That's not what the standard says.

>  Code that can be
> compiled correctly, per the specification, but might not be what the
> user intended, is a candidate for a warning.
>
> If the proposed changes catch true errors -- not just dubious
> constructs -- that were previously allowed, well, that's the price of
> progress.  That's the compiler getting better at distinguishing between
> code conformant and not.
>
> Section 2.1 "C Language" of the manual states that, with no option
> specified on the command line, the default standard is -std=gnu17.
>
> Part of the proposal IIUC is to treat undeclared functions as an error.
> Function prototypes have been required afaik since c99.  If
> that's correct, then letting them pass without error is a mistake for
> -std=c99 and above.

Technically, the standard only requires a diagnostic, and a warning is
a diagnostic. So strictly speaking, it's conforming to let them pass
with a warning. The question is whether that's really the best
behaviour for the majority of current users. At some point in the past
it was decided that warning and continuing by default was the best
choice. That might not still be true today.

> As to the default, is anyone suggesting that gnu17 -- i.e., c17 with
> GNU extensions -- includes ignoring missing function prototypes?  That
> to me would be an odd definition of "extension".

I don't think that actually matters here.

> The user who has old code that does not meet the c99 standard but Just
> Works nonetheless has a direct route to compiling that code without
> complaint: -std=c90.  It says so right there in the fine manual.

Indeed.

> It's that simple.  The code is either in spec and compiles without
> error, or it is not and does not.  The only debate is over what "the
> spec" is, and what warnings the user might want for conforming code.

Well, no, because issuing a warning for violations of the spec
conforms to the standard. So it's not that simple, we really do have
to decide whether to actually cause compilation failure for these
constraint violations, or just issue a diagnostic and continue.

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

"James K. Lowden"  writes:

> On Tue, 9 May 2023 23:45:50 +0100
> Jonathan Wakely via Gcc  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!
>
> This, it seems to me, is the crux of the question.  Code that does not
> conform to the standard should produce an error.  Code that can be
> compiled correctly, per the specification, but might not be what the
> user intended, is a candidate for a warning.  
>
> If the proposed changes catch true errors -- not just dubious
> constructs -- that were previously allowed, well, that's the price of
> progress.  That's the compiler getting better at distinguishing between
> code conformant and not.  
>
> Section 2.1 "C Language" of the manual states that, with no option
> specified on the command line, the default standard is -std=gnu17.  
>
> Part of the proposal IIUC is to treat undeclared functions as an error.
> Function prototypes have been required afaik since c99.  If
> that's correct, then letting them pass without error is a mistake for
> -std=c99 and above.  
>
> As to the default, is anyone suggesting that gnu17 -- i.e., c17 with
> GNU extensions -- includes ignoring missing function prototypes?  That
> to me would be an odd definition of "extension".  
>
> The user who has old code that does not meet the c99 standard but Just
> Works nonetheless has a direct route to compiling that code without
> complaint: -std=c90.  It says so right there in the fine manual.  
>
> It's that simple.  The code is either in spec and compiles without
> error, or it is not and does not.  The only debate is over what "the
> spec" is, and what warnings the user might want for conforming code.  

jwakely's already dispatched with these claims, but I'd note that
if this were the case, we'd all be arguing about whether Clang
is currently conformant.

(There is a fair point in all of this about how much we want to
consider some of these constructs extensions. I'm relieved to see
that e.g. implicit func. decls weren't ever considered "real"
GNU extensions, rather something which was added for compat. for
a while, rather than something deliberately and explicitly
supported as a GNU extension forever, even just for certain Cs.)



signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

jwakely@gmail.com (Jonathan Wakely) writes:

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

Only if your definition of valid C is ``strictly conforming to the ISO
Standard''.  I doubt there are many programs which fit such a
definition.

And anyway, GCC accepts many other constructs which can not be used in a
strictly conforming Standard C programs.  For example, the use of dollar
signs in identifiers.  Should we not also reject those, identifier names
with external linkage longer than thirty two characters, hex floats,
arithmetic on void pointers, zero-length arrays, statement expressions,
and so on?

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

The code is conforming, it simply relies on extensions to the Standard.
Implicit int does not break any strictly conforming program, so a C
implementation implemented it continues to be conforming, along with
those programs relying on implicit int.  See this wording in the
Standard:

  A conforming implementation may have extensions (including additional
  library functions), provided they do not alter the behavior of any
  strictly conforming program.

You are not trying to reject non-conforming C code.  You are, for better
or worse, trying to impose your personal preferences on users of GCC.

Let's debate the real problem at hand instead of using the Standard as a
boogeyman: namely, whether or not disabling implicit-int in GCC 14 is a
good idea.

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Po Lu via Gcc  writes:

> jwakely@gmail.com (Jonathan Wakely) writes:
>
>> This isn't "be like Clang", this is "diagnose things that have been
>> invalid C since 1999".
>
> Only if your definition of valid C is ``strictly conforming to the ISO
> Standard''.  I doubt there are many programs which fit such a
> definition.
>
> And anyway, GCC accepts many other constructs which can not be used in a
> strictly conforming Standard C programs.  For example, the use of dollar
> signs in identifiers.  Should we not also reject those, identifier names
> with external linkage longer than thirty two characters, hex floats,
> arithmetic on void pointers, zero-length arrays, statement expressions,
> and so on?
>
>> 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.
>
> The code is conforming, it simply relies on extensions to the Standard.
> Implicit int does not break any strictly conforming program, so a C
> implementation implemented it continues to be conforming, along with
> those programs relying on implicit int.  See this wording in the
> Standard:
>
>   A conforming implementation may have extensions (including additional
>   library functions), provided they do not alter the behavior of any
>   strictly conforming program.
>
> You are not trying to reject non-conforming C code.  You are, for better
> or worse, trying to impose your personal preferences on users of GCC.
>
> Let's debate the real problem at hand instead of using the Standard as a
> boogeyman: namely, whether or not disabling implicit-int in GCC 14 is a
> good idea.

Much of the thread (including the original post) does discuss that and
it's not limited to implicit-int.


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Po Lu via Gcc  writes:

> jwakely@gmail.com (Jonathan Wakely) writes:
>
>> This isn't "be like Clang", this is "diagnose things that have been
>> invalid C since 1999".
>
> Only if your definition of valid C is ``strictly conforming to the ISO
> Standard''.  I doubt there are many programs which fit such a
> definition.

No, we're talking about "things which ISO C made invalid in 1999, but
GCC kept supporting for a while". We're discussing terminating that
support. The "standard" part here is not about deference to the standard
and claiming extensions can never be made, but rather that we're keeping
something which was explicitly removed.

>
> And anyway, GCC accepts many other constructs which can not be used in a
> strictly conforming Standard C programs.  For example, the use of dollar
> signs in identifiers.  Should we not also reject those, identifier names
> with external linkage longer than thirty two characters, hex floats,
> arithmetic on void pointers, zero-length arrays, statement expressions,
> and so on?

These aren't things which were in the standard and then got removed
because of how terrible they are. They're things that are considered
a part of GNU C as proper GNU extensions.

Note that, per the rest of the thread, the constructs we're discussing
here to be banned are not considered "proper GNU extensions".




signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

dje@gmail.com (David Edelsohn) writes:

> This seems to be the core tension.  If developers cared about these issues,
> they would enable appropriate warnings and -Werror.
>
> The code using these idioms is not safe and does create security
> vulnerabilities.  And software security is increasingly important.

Oh please.  By this definition, every bug is a security issue.
What bugs have been caused by implicit int?

> The concern is using the good will of the GNU Toolchain brand as the tip of
> the spear or battering ram to motivate software packages to fix their
> problems. It's using GCC as leverage in a manner that is difficult for
> package maintainers to avoid.  Maybe that's a necessary approach, but we
> should be clear about the reasoning.  Again, I'm not objecting, but let's
> clarify why we are choosing this approach.

You will simply make life annoying for people who already have working
code.  People do not like it when others do that!

If you make it too annoying to turn off the new diagnostics, you will
not convince people who have not stopped writing traditional C code to
stop doing so.

Instead, they will use an older version of GCC, or license a proprietary
compiler which allows them to keep writing use language as they always
did.  My organization eventually chose the latter when GCC removed
`-traditional', and to this day we continue to write code which relies
on float arithmetic being promoted to double, unsigned narrow types
being promoted to unsigned int, and string constants being writable.

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Po Lu via Gcc  writes:

> dje@gmail.com (David Edelsohn) writes:
>
>> This seems to be the core tension.  If developers cared about these issues,
>> they would enable appropriate warnings and -Werror.
>>
>> The code using these idioms is not safe and does create security
>> vulnerabilities.  And software security is increasingly important.
>
> Oh please.  By this definition, every bug is a security issue.
> What bugs have been caused by implicit int?
>
>> The concern is using the good will of the GNU Toolchain brand as the tip of
>> the spear or battering ram to motivate software packages to fix their
>> problems. It's using GCC as leverage in a manner that is difficult for
>> package maintainers to avoid.  Maybe that's a necessary approach, but we
>> should be clear about the reasoning.  Again, I'm not objecting, but let's
>> clarify why we are choosing this approach.
>
> You will simply make life annoying for people who already have working
> code.  People do not like it when others do that!
>
> If you make it too annoying to turn off the new diagnostics, you will
> not convince people who have not stopped writing traditional C code to
> stop doing so.
>
> Instead, they will use an older version of GCC, or license a proprietary
> compiler which allows them to keep writing use language as they always
> did.  My organization eventually chose the latter when GCC removed
> `-traditional', and to this day we continue to write code which relies
> on float arithmetic being promoted to double, unsigned narrow types
> being promoted to unsigned int, and string constants being writable.

Nobody here is suggesting that the ability to compile this code at
all would be removed. Throughout this thread, people discuss methods
like e.g. adding -fpermissive to allow it.


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

jwakely@gmail.com (Jonathan Wakely) writes:

> So let's do it. Let's write a statement saying that the GCC developers
> consider software security to be of increasing importance, and that we
> consider it irresponsible to default to accepting invalid constructs in the
> name of backwards compatibility. State that we will make some changes which
> were a break from GCC's traditional stance, for the good of the ecosystem.

I'm sorry you think that way.

> Given recent pushes to discourage or outright ban the use of memory-safe
> languages in some domains, I think it would be good to make a strong
> statement about taking the topic seriously. And not just make a statement,
> but take action too.
>
> If we don't do this, I believe it will harm GCC in the long run. The vocal
> minority who want to preserve the C they're used to, like some kind of
> historical reenactment society, would get their wish: it would become a
> historical dead end and go nowhere.

Vocal minority? Do you have any evidence to back this claim?

What I see is that some reasonable organizations have already chosen
other C compilers which are capable of supporting their existing large
bodies of C code that have seen significant investment over many years,
while others have chosen to revise their C code with each major change
to the language.

The organizations which did not wish to change their code did not
vocally demand changes to GCC after GCC became unsuitable, but quietly
arranged to license other compilers.

Those that continue write traditional C code know what they are doing,
and the limitations of traditional C do not affect the quality of their
code.  For example, on the Unix systems at my organization, the SGS is
modified so that it will not link functions called through a declaration
with no parameter specification with a different set of parameters than
it was defined with.

Naturally, the modified linker is not used to run configure scripts.

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Po Lu via Gcc  writes:

> jwakely@gmail.com (Jonathan Wakely) writes:
>
>> So let's do it. Let's write a statement saying that the GCC developers
>> consider software security to be of increasing importance, and that we
>> consider it irresponsible to default to accepting invalid constructs in the
>> name of backwards compatibility. State that we will make some changes which
>> were a break from GCC's traditional stance, for the good of the ecosystem.
>
> I'm sorry you think that way.
>
>> Given recent pushes to discourage or outright ban the use of memory-safe
>> languages in some domains, I think it would be good to make a strong
>> statement about taking the topic seriously. And not just make a statement,
>> but take action too.
>>
>> If we don't do this, I believe it will harm GCC in the long run. The vocal
>> minority who want to preserve the C they're used to, like some kind of
>> historical reenactment society, would get their wish: it would become a
>> historical dead end and go nowhere.
>
> Vocal minority? Do you have any evidence to back this claim?
>
> What I see is that some reasonable organizations have already chosen
> other C compilers which are capable of supporting their existing large
> bodies of C code that have seen significant investment over many years,
> while others have chosen to revise their C code with each major change
> to the language.
>
> The organizations which did not wish to change their code did not
> vocally demand changes to GCC after GCC became unsuitable, but quietly
> arranged to license other compilers.
>
> Those that continue write traditional C code know what they are doing,
> and the limitations of traditional C do not affect the quality of their
> code.  For example, on the Unix systems at my organization, the SGS is
> modified so that it will not link functions called through a declaration
> with no parameter specification with a different set of parameters than
> it was defined with.

I think the group of people dedicated enough to patch their linker would
be able to pass a flag to the compiler to allow old constructs.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Sam James  writes:

> No, we're talking about "things which ISO C made invalid in 1999, but
> GCC kept supporting for a while". We're discussing terminating that
> support. The "standard" part here is not about deference to the standard
> and claiming extensions can never be made, but rather that we're keeping
> something which was explicitly removed.

Which is still an extension to the Standard, and a perfectly conforming
one at that.

The same could not be said about the lack of trigraphs, and keywords
such as `asm'.

> These aren't things which were in the standard and then got removed
> because of how terrible they are. They're things that are considered
> a part of GNU C as proper GNU extensions.

Once the Standard removed those features, the implementations in GNU C
became GNU extensions.  No amount of wordplay is going to change that.

In C99 and later dialects of C, GCC even issues a diagnostic upon
encountering implicit function declarations or implicit int, thereby
satisfying that requirement of the Standard.

> Note that, per the rest of the thread, the constructs we're discussing
> here to be banned are not considered "proper GNU extensions".

Really?  It is an implementation extension, the implementation being GNU
C.  It also seems rather arrogant to assume that you have the privilege
to ban others from writing code in a certain way.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Sam James  writes:

> Nobody here is suggesting that the ability to compile this code at
> all would be removed. Throughout this thread, people discuss methods
> like e.g. adding -fpermissive to allow it.

Here, I'm saying that making it annoying to compile such code is not
going to convince people to change the way they write.

Making it impossible to do so will make them look for some other C
compiler.  So you might as well not try.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Sam James  writes:

> I think the group of people dedicated enough to patch their linker would
> be able to pass a flag to the compiler to allow old constructs.

Unfortunately, we do not have the source code for our compiler.  Would
you care to ask people here to restore `gcc -traditional'?

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

jwakely@gmail.com (Jonathan Wakely) writes:

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

The Standard requires that a diagnostic be issued upon encountering
certain kinds of invalid constructs.  Warnings are diagnostics.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Jonathan Wakely via Gcc  writes:

> On Wed, 10 May 2023, 03:32 Eli Zaretskii,  wrote:
>
>>
>> And then people will start complaining about GCC unnecessarily
>> erroring out, which is a compiler bug, since there's no problem
>> producing correct code in these cases.
>>
>
>
> What is the correct code for this?
>
> void foo(int);
> void bar() { foo("42"); }
>
> Why should this compile?

Because keeping that from compiling will also keep this from compiling:

bar ()
{
  extern foo ();

  return foo ("42");
}

> You keep demanding better rationale for the change, but your argument
> amounts to nothing more than "it compiles today, it should compile
> tomorrow".

And so it should.  Because for every invalid piece of code you can think
of, there are hundereds or thousands of combinations that may as well be
valid.  For example, on the 68020, vax, or similarly reasonable 32-bit
machine:

foo (ptr)
{
  register char *str;

  str = ptr;

  /* do stuff with str */

  puts (str);
}

/* In another translation unit.  */

bar ()
{
  foo ("42");
}

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

> Unfortunately, we do not have the source code for our compiler.  Would
> you care to ask people here to restore `gcc -traditional'?


This would appear to be a self-inflicted wound. If I understand the
chain of events properly...

- gcc drops support for -traditional

- you wish to use code that does the badness

- you purchase a proprietary compiler that permits it anyway
  - to avoid making it produce invalid results, you hack your linker

You'd rather hack your compiler, but you cannot do it because you
purchased a proprietary compiler and didn't purchase the rights to its
source code.

(BTW, there's a FOSS compiler that you can hack on if you like.)



That's all fine and well, you do you. What I do not understand is, two
things.

First of all, why are you calling this "traditional C"? It is not
"traditional C". It isn't C. It is not-C.

Second of all, why is this GCC's problem? You are not a user of GCC,
apparently.



Moreover, this discussion is not about -traditional! It's about
implicit-function-declaration. And implicit-function-declaration does
not have the same problem as -traditional, because
implicit-function-declaration ***WILL*** have a flag that permits people
who are users of GCC, and just want implicit-function-declaration back.

So you have exactly what you want out of this conversation. We concede.
C type errors by default will come with a flag to disable them.


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Eli Schwartz  writes:

>> Unfortunately, we do not have the source code for our compiler.  Would
>> you care to ask people here to restore `gcc -traditional'?
>
>
> This would appear to be a self-inflicted wound. If I understand the
> chain of events properly...

The chain of events actually is:

  - The code was originally written for the BSD Unix cc.
  - Eventually, it started to be built with GCC, with -traditional.
  - GCC removes -traditional.
  - We are forced to find another C comppiler.

Note that I wasn't where I am when this started, so everything above is
second hand knowledge.

And finally, this:

>   - to avoid making it produce invalid results, you hack your linker

Which is essentially link-time lint, and not related to the subject at
hand.  I only mentioned it to make a point, which is that people writing
traditional C in this day and age are unlikely to make any mistakes
doing so.

> You'd rather hack your compiler, but you cannot do it because you
> purchased a proprietary compiler and didn't purchase the rights to its
> source code.
>
> (BTW, there's a FOSS compiler that you can hack on if you like.)

Which sadly does not support the code which we need to compile.
Clearly, turning GCC into a K&R compiler is not a very welcome idea
around here, so why would we hack on it?

> That's all fine and well, you do you. What I do not understand is, two
> things.
>
> First of all, why are you calling this "traditional C"? It is not
> "traditional C". It isn't C. It is not-C.

When the file names for the source files end with `.c' and `.h', and the
compiler is named `cc' and `acomp', it is C.  It just isn't Standard C.

> Second of all, why is this GCC's problem? You are not a user of GCC,
> apparently.

Because decisions arbitrarily made on GCC's part will simply result in
even more people deciding to find some other compiler.

The point being that people sufficiently dedicated to their existing
code to not have changed in over 30 years will not respond to such
changes by changing their code.  They are much more likely to look for
some other compiler instead.

> And implicit-function-declaration does not have the same problem as
> -traditional, because implicit-function-declaration ***WILL*** have a
> flag that permits people who are users of GCC, and just want
> implicit-function-declaration back.

And remember that `-traditional' DID exist for a certain amount of time.
Then it was removed.  So in addition to annoying a lot of people, what
guarantees that -Wno-implicit will not be removed in the future, after
the proposed changes are made?

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

On 5/10/23 11:56 PM, Po Lu wrote:
> Eli Schwartz  writes:
> 
>>> Unfortunately, we do not have the source code for our compiler.  Would
>>> you care to ask people here to restore `gcc -traditional'?
>>
>>
>> This would appear to be a self-inflicted wound. If I understand the
>> chain of events properly...
> 
> The chain of events actually is:
> 
>   - The code was originally written for the BSD Unix cc.
>   - Eventually, it started to be built with GCC, with -traditional.
>   - GCC removes -traditional.
>   - We are forced to find another C comppiler.


Right, this is what I said. Although your bullet points 1 and 2 don't
really have much of anything to do with it.

In between points 3 and 4, I noted that you wish to *use* such bad code.
I didn't say you wish to write it, merely that you wish to use it
(without judging when it was written).


> Note that I wasn't where I am when this started, so everything above is
> second hand knowledge.
> 
> And finally, this:
> 
>>   - to avoid making it produce invalid results, you hack your linker
> 
> Which is essentially link-time lint, and not related to the subject at
> hand.  I only mentioned it to make a point, which is that people writing
> traditional C in this day and age are unlikely to make any mistakes
> doing so.


Absolutely! It's a very good point. It's a point that people writing
traditional not-C in this day and age are doing so with highly complex
toolchains they have personally written to do things that no non-bespoke
toolchain does. As such, they are unaffected by any and all decisions
GCC makes. But if they were affected by such decisions, they would have
the technical knowledge to modify GCC to suit themselves.


>> You'd rather hack your compiler, but you cannot do it because you
>> purchased a proprietary compiler and didn't purchase the rights to its
>> source code.
>>
>> (BTW, there's a FOSS compiler that you can hack on if you like.)
> 
> Which sadly does not support the code which we need to compile.
> Clearly, turning GCC into a K&R compiler is not a very welcome idea
> around here, so why would we hack on it?


But your bespoke toolchain did not support the code which you need to
compile either. That's why you began hacking on it at all, to suit your
needs.

So if neither GCC nor your bespoke toolchain support the code you need
to compile, and you must modify *something* to suit yourself, then it is
definitely possible to do it for GCC instead.

I don't see what the welcome for making these modifications into the
default flagship experience for the entire free software ecosystem, has
to do with your being welcome to hack on GCC for your own personal use.

Do you feel welcome by your proprietary vendor, who refuses to let you
touch it at all by withholding source code?


>> That's all fine and well, you do you. What I do not understand is, two
>> things.
>>
>> First of all, why are you calling this "traditional C"? It is not
>> "traditional C". It isn't C. It is not-C.
> 
> When the file names for the source files end with `.c' and `.h', and the
> compiler is named `cc' and `acomp', it is C.  It just isn't Standard C.


BRB, renaming all my python files to *.c and symlinking /usr/bin/cc to
/usr/bin/python.

...

No, the criteria for whether something constitutes a given programming
language are not "the file extension says so" or "the compiler name says
so".

A programming language is defined by the syntax and meaning of that
programming language.

(If we were to replace this conversation with a definition of what
constitutes python, then as a scripted language, all files without file
extensions could be python scripts. And similarly, people play
interesting games with C files by naming them unconventional names and
passing -xc to the compiler. File extension autodetection isn't everything.)


>> Second of all, why is this GCC's problem? You are not a user of GCC,
>> apparently.
> 
> Because decisions arbitrarily made on GCC's part will simply result in
> even more people deciding to find some other compiler.
> 
> The point being that people sufficiently dedicated to their existing
> code to not have changed in over 30 years will not respond to such
> changes by changing their code.  They are much more likely to look for
> some other compiler instead.


Well no, because if they are sufficiently dedicated to their existing
code to not have changed in over 30 years then they are writing c89 code
and passing -std=c89, and this is acceptable as far as GCC is concerned
and their code will still compile.

So they won't feel inclined to find some other compiler, and quite
frankly, if they were doing the right thing in accordance with the
standard way to use the language they prefer to use, then they probably
will not notice that GCC changed anything?


>> And implicit-function-declaration does not have the same problem as
>> -traditional, because implicit-function-declaration ***WILL*** have a
>> flag that permits people who are users of GCC, an

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

On 5/11/23 12:46 AM, Eli Schwartz wrote:
> On 5/10/23 11:56 PM, Po Lu wrote:
>> And remember that `-traditional' DID exist for a certain amount of time.
>> Then it was removed.  So in addition to annoying a lot of people, what
>> guarantees that -Wno-implicit will not be removed in the future, after
>> the proposed changes are made?
> 
> 
> What guarantees of the future do you have for anything?
> 
> What guarantees do you have that a meteor won't hit Earth and wipe out
> all human life in a great catastrophe?
> 
> What guarantees do you have that GCC will still be run by the current
> maintainers?
> 
> What guarantees do you have that GCC will still be maintained at all?
> 
> What guarantees do you have that GCC won't decide next year that they
> are deleting all support for std > c89, making -traditional the default,
> and becoming a historical recreation society?
> 
> What guarantees do you have that GCC won't decide next year that they
> are deleting all support for std < c23, mandating that everyone upgrade
> to the very latest std that isn't even fully implemented today?
> 
> What guarantees do you have that reality exists as you think of it?
> Maybe you are a pink elephant and computers are a figment of your
> imagination.
> 
> ...
> 
> I think that what-ifs aren't the most productive use of our time. The
> current proposal provides for -std=c89 and similar, so the current
> proposal does not cause current GCC users to be unable to use GCC after
> the proposed change.
> 
> If a future proposal causes current GCC users to be unable to use GCC
> after the future proposal is implemented, then, and only then, should we
> worry about whether it will be possible to use GCC. Then, and only then,
> will a threat to prevent doing so have actually materialized.


P.S. No, it is not realistic that GCC will remove support for a language
feature of c89, until and unless GCC removes support for -std=c89. So I
do not know why you are talking about -Wno-implicit. That isn't the
question, that's not what's up for debate here. The question is whether
GCC will drop support for -std=c89, with all the language functionality
that encompasses (including defaulting to not issuing fatal diagnostics
when you use it, or indeed issuing diagnostics at all).

So please restate your question, as such:

> And remember that `-traditional' DID exist for a certain amount of
> time. Then it was removed.  So in addition to annoying a lot of
> people, what guarantees that -std=c89 will not be removed in the
> future, after the proposed changes are made?



-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Wed, 10 May 2023 14:37:50 -0400
> From: "James K. Lowden" 
> Cc: Jonathan Wakely 
> 
> On Tue, 9 May 2023 23:45:50 +0100
> Jonathan Wakely via Gcc  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!
> 
> This, it seems to me, is the crux of the question.  Code that does not
> conform to the standard should produce an error.

That's not what the standard says, and that's not how GCC behaves.
GCC has options to enforce the standard, but other than that, it
doesn't reject extensions and deviations from the standard.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Wed, 10 May 2023 23:14:20 -0400
> From: Eli Schwartz via Gcc 
> 
> Second of all, why is this GCC's problem? You are not a user of GCC,
> apparently.

He is telling you that removing support for these old features, you
draw users away from GCC and towards proprietary compilers.

One of the arguments in this thread _for_ dropping that support was
that by not rejecting those old programs, GCC draws some users away
from GCC.  He is telling you that this change will, perhaps, draw some
people to GCC, but will draw others away from GCC.  The difference is
that the former group will start using Clang, which is still free
software (at least some of its versions), whereas the latter group has
nowhere to go but to proprietary compilers.  So the FOSS community
will have suffered a net loss.  Something to consider, I think.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Eli Schwartz  writes:

> Right, this is what I said. Although your bullet points 1 and 2 don't
> really have much of anything to do with it.
>
> In between points 3 and 4, I noted that you wish to *use* such bad code.
> I didn't say you wish to write it, merely that you wish to use it
> (without judging when it was written).

[...]

> Absolutely! It's a very good point. It's a point that people writing
> traditional not-C in this day and age are doing so with highly complex
> toolchains they have personally written to do things that no non-bespoke
> toolchain does. As such, they are unaffected by any and all decisions
> GCC makes. But if they were affected by such decisions, they would have
> the technical knowledge to modify GCC to suit themselves.

Upper management types performed a cost analysis and decided that it
would be more appropriate to license another C compiler.  Please don't
expect that only technical ability affects decisions made in the real
world.

> But your bespoke toolchain did not support the code which you need to
> compile either. That's why you began hacking on it at all, to suit your
> needs.
>
> So if neither GCC nor your bespoke toolchain support the code you need
> to compile, and you must modify *something* to suit yourself, then it is
> definitely possible to do it for GCC instead.
>
> I don't see what the welcome for making these modifications into the
> default flagship experience for the entire free software ecosystem, has
> to do with your being welcome to hack on GCC for your own personal use.
>
> Do you feel welcome by your proprietary vendor, who refuses to let you
> touch it at all by withholding source code?

No, I do not.  I can not speak for my management.

But I also do not feel any welcome from a group of developers who are
interested in breaking other code, some of which I have written for
myself, and then religiously defend their decisions.

In short, I do not like being told what to do with my own code!

> BRB, renaming all my python files to *.c and symlinking /usr/bin/cc to
> /usr/bin/python.
>
> ...
>
> No, the criteria for whether something constitutes a given programming
> language are not "the file extension says so" or "the compiler name says
> so".
>
> A programming language is defined by the syntax and meaning of that
> programming language.

OK, and the Portable C Compiler from Bell Labs followed one such
definition of its syntax and meaning.

ANSI and ISO simply define several such variants of the C language,
collectively known as Standard C.  1st edition K&R defines another, and
each compiler, in practice, defines its own.  Just like there are
different varieties of English, or perhaps German.

> (If we were to replace this conversation with a definition of what
> constitutes python, then as a scripted language, all files without file
> extensions could be python scripts. And similarly, people play
> interesting games with C files by naming them unconventional names and
> passing -xc to the compiler. File extension autodetection isn't everything.)

This is pure pedantry.  My point is:

  If it looks like a duck, and quacks like a duck, then it is a duck.

or, IOW:

  If it looks like C, compiles in a C compiler, then it is C.

> Well no, because if they are sufficiently dedicated to their existing
> code to not have changed in over 30 years then they are writing c89 code
> and passing -std=c89, and this is acceptable as far as GCC is concerned
> and their code will still compile.

They are not writing ``C89'' code.  They are writing ``GNU99'', or perhaps
``GNU11'' code.

> So they won't feel inclined to find some other compiler, and quite
> frankly, if they were doing the right thing in accordance with the
> standard way to use the language they prefer to use, then they probably
> will not notice that GCC changed anything?

What gives you the right to dictate what the Right Thing is and what is
not?

> What guarantees of the future do you have for anything?
>
> What guarantees do you have that a meteor won't hit Earth and wipe out
> all human life in a great catastrophe?
>
> What guarantees do you have that GCC will still be run by the current
> maintainers?
>
> What guarantees do you have that GCC will still be maintained at all?
>
> What guarantees do you have that GCC won't decide next year that they
> are deleting all support for std > c89, making -traditional the default,
> and becoming a historical recreation society?
>
> What guarantees do you have that GCC won't decide next year that they
> are deleting all support for std < c23, mandating that everyone upgrade
> to the very latest std that isn't even fully implemented today?
>
> What guarantees do you have that reality exists as you think of it?
> Maybe you are a pink elephant and computers are a figment of your
> imagination.

You are arguing to absurdity.

> I think that what-ifs aren't the most productive use of our time. The
> current proposal provides for -std=c89 and similar, so the cu

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Thu, 11 May 2023 00:46:23 -0400
> Cc: gcc@gcc.gnu.org
> From: Eli Schwartz via Gcc 
> 
> > And remember that `-traditional' DID exist for a certain amount of time.
> > Then it was removed.  So in addition to annoying a lot of people, what
> > guarantees that -Wno-implicit will not be removed in the future, after
> > the proposed changes are made?
> 
> 
> What guarantees of the future do you have for anything?
> 
> What guarantees do you have that a meteor won't hit Earth and wipe out
> all human life in a great catastrophe?
> 
> What guarantees do you have that GCC will still be run by the current
> maintainers?
> 
> What guarantees do you have that GCC will still be maintained at all?
> 
> What guarantees do you have that GCC won't decide next year that they
> are deleting all support for std > c89, making -traditional the default,
> and becoming a historical recreation society?
> 
> What guarantees do you have that GCC won't decide next year that they
> are deleting all support for std < c23, mandating that everyone upgrade
> to the very latest std that isn't even fully implemented today?
> 
> What guarantees do you have that reality exists as you think of it?
> Maybe you are a pink elephant and computers are a figment of your
> imagination.

Please be serious, and please don't mock your opponents.  This is a
serious discussion of a serious subject, not a Twitter post.

Back to the subject: the guarantees I would personally like to have is
that the current GCC development team sees backward compatibility as
an important goal, and will try not to break old programs without very
good technical reasons.  At least in Emacs development, that is the
consideration that is very high on our priority list when making
development decisions.  It would be nice if GCC (and any other GNU
project, for that matter) would do the same, because being able to
upgrade important tools and packages without fear is something users
value very much.  Take it from someone who uses GCC on various
platforms since version 1.40.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Eli Schwartz  writes:

> P.S. No, it is not realistic that GCC will remove support for a language
> feature of c89, until and unless GCC removes support for -std=c89. So I
> do not know why you are talking about -Wno-implicit. That isn't the
> question, that's not what's up for debate here. The question is whether
> GCC will drop support for -std=c89, with all the language functionality
> that encompasses (including defaulting to not issuing fatal diagnostics
> when you use it, or indeed issuing diagnostics at all).

Because in the real world, almost nobody writes strictly conforming ANSI
C.  Some people do want to mix declarations with statements.  Some
people do want non-local goto, typeof, zero length arrays, arithmetic on
void pointers, asm volatile, and so on.  And at the same time, they also
want to be able to use features such as various declarations with only a
storage class specifier.

All of which are presently implemented by GCC.

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Thu, 11 May 2023, 03:18 Po Lu,  wrote:

>  It also seems rather arrogant to assume that you have the privilege
> to ban others from writing code in a certain way.
>

This is about a change in defaults. There would be options to continue
compiling that code. It would not be banned, so the histrionics are
unnecessary.

Re: More C type errors by default for GCC 14

[David Brown]

On 10/05/2023 18:28, Eli Zaretskii via Gcc wrote:

Date: Wed, 10 May 2023 17:58:16 +0200
From: David Brown via Gcc 


In any case, I was not not talking about bug-compatibility, I was
talking about being able to compile code which GCC was able to compile
in past versions.  Being able to compile that code is not a bug, it's
a feature.


No, being able to compile /incorrect/ code by default is a bug.  It is
not helpful.


I actually agree; we just have different definitions of "incorrect".



Fair enough.


I've seen this kind of argument many times - "The compiler used to
accept my code and give the results I wanted, and now newer compiler
versions make a mess of it".


But we are not talking about some random code that just happened to
slip through cracks as a side effect of the particular implementation.
We are talking about code that was perfectly valid, had well-defined
semantics, and produced a working program.  I don't care about the
former; I do care about the latter.


How would you know that the code had perfectly valid, well-defined 
semantics?


I've had the dubious pleasure of trying to maintain and update code 
where the previous developer had a total disregard for things like 
function declaration - he really did dismiss compiler complaints about 
implicit function declarations as "only a warning".  The program worked 
as he expected, for the most part.  But that was despite many functions 
being defined in one part of the code with one set of parameters (number 
and type), and called elsewhere with a different set - sometimes more 
than one selection of parameter types in the same C file.


Insisting on proper function declarations and removing implicit int does 
not guarantee that such messes won't happen - but it /does/ reduce some 
of the opportunities to do so accidentally.





If the gcc developers really were required to continue to compile /all/
programs that compiled before, with the same results, then the whole gcc
project can be stopped.


You will have to explain this to me.  Just stating this is not enough.
How will accepting K&R stop GCC development?



People write incorrect code all the time.  Studies have shown that 
pretty much any sizeable C or C++ program - including gcc itself - 
contain undefined behaviour but rely on particular results from that. 
Lax interpretation and long outdated syntaxes do not, in themselves, 
imply undefined behaviour or incorrect code - but they make it far 
easier to accidentally have such errors, and to cover up such errors. 
(That's why they were removed in the first place.)


If a compiler is required to continue to compile every program that a 
previous version compiled, where the developer was satisfied that the 
program worked as expected, then the only way to guarantee that is to 
stop changing and improving gcc.


I agree that accepting fully correct programs written in K&R C would not 
limit the future development of gcc.  But how many programs written in 
K&R C, big enough and important enough to be relevant today, are fully 
correct?  I'd be surprised if you needed more than one hand to count 
them.  I would expect subtle errors and assumptions to flourish - with 
typical examples being signed integer arithmetic overflows and abuses of 
pointer casts and invalid mixing of pointer and integer types.


Continuing to give developers what they expect, rather than what the 
standards (and gcc extensions) guarantee, is always an issue for 
backwards compatibility.  Each new version of gcc can, and sometimes 
does, "break" old code - code that people relied on before, but was 
actually incorrect.  This is unavoidable if gcc is to progress.


That is why I suggested that a flag such as "-fold-code" that enables 
long outdated syntaxes should also disable the kind of optimisations 
that are most likely to cause issues with old code, and should enable 
semantics chances to match likely assumptions in such code.  I don't 
believe in the existence of correct K&R C code - but I /do/ believe in 
the importance of some K&R C code despite its errors.




As for the two's complement wrapping example: I'm okay with having
this broken because some useful feature requires to modify the basic
arithmetics and instructions emitted by GCC in a way that two's
complement wrapping can no longer be supported.  _That_ is exactly an
example of a "good reason" for backward incompatibility: GCC must do
something to compile valid programs, and that something is
incompatible with old programs which depended on some de-facto
standard that is nowadays considered UB.  


The problem for backwards compatibility and continuing to compile old 
code is that these things were /always/ UB - but they were, as you say, 
viewed as de-facto.



But the case in point is not
like that, AFAIU: in this case, GCC will deliberately break a program
although it could compile it without adversely affecting its output
for any other valid program.  To me, this would be an arbitrary
decisio