Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Sun, 14 May 2023, 06:28 Po Lu,  wrote:

> Eli Schwartz  writes:
>
> > Quoting my previous reply on the topic.
> >
> > Until everyone is on the same page as you about whether these are GNUC
> > extensions, this conversation will go nowhere.
> >
> > You are of the opinion that "GCC currently behaves a certain way when
> > compiling the code" means that the behavior is documented and specified
> > as a "C Extension" for the GNUC language dialect.
>
> Yes, by the definition of ``extension'' used by everyone except you.
>

Wrong. I wouldn't bother replying to you again in this thread, but I feel
that as a gcc maintainer I should confirm that Eli S. is right here; and
nobody else I know agrees with your definition of extension as "every
non-standard aspect of the compiler's behaviour, whether intentional or
accidental". That's just silly.



> > You've provided some excuses like "C++ is a valid language for writing
> > documentation in, and the HTML docs are lacking", but your arguments are
> > not convincing.
> >
> > GCC has formal documentation. It is written in HTML. If it is lacking,
> > then the only valid move is to improve the HTML documentation and then
> > abide by it. In the absence of documentation, all behavior is, well,
> > "undocumented", which ***definitely*** means it isn't a formal GNUC
> > language dialect extension.
>
> GCC documentation is written in HTML? That's news to me.  I always
> thought it was written in Texinfo.
>

Some is in docbook XML, and some is in HTML (namely the release notes).



> > You can stop arguing your opinions based on what running gcc or g++
> > produces in the form of machine code. What gcc or g++ produces in the
> > form of machine code is not guaranteed even across bugfix releases --
> > your only guarantee is that if it is documented in the ISO standards
> > documents or in the GCC html manual, the produced machine code shall be
> > in accordance with what the documentation says it shall do.
>
> Generated machine code, really?  Not long-standing and observable
> behavior of the translator itself, as has been re-iterated over and over
> again?
>
> > Undefined and undocumented behavior is not a language extension. It is
> > undefined and undocumented behavior.
>
> But when it becomes defined by the translator, in a precise way, it
> becomes an extension to the Standard.
>

No, Eli S. is quite right.


> > You may feel free to take an exact GCC release (source or binary),
> > analyze it, reverse-engineer it, or verify that it does what you want
> > it to do, and then trust that those undefined and undocumented
> > behaviors are ***benevolent***, but that doesn't cause it to be
> > defined and documented, and your trust will, if you are wise, depend
> > on you pinning an exact source code commit of the compiler. Do not
> > depend on bugfix releases of GCC to preserve your undocumented
> > semantics. They may or they may not, but if they don't, it's not a GCC
> > bug, because it is ***undocumented***.
>
> GCC does not implement its documentation.  The documentation is supposed
> to describe (_not_ specify) how GCC behaves, and when the documentation
> is wrong or contains omissions, the documentation will have to be fixed.
> Not the compiler itself.
>

And when the compiler is wrong and the documentation is correct, the
compiler is fixed.



> And it's not just GCC.  Almost all programs work this way.
>

Re: More C type errors by default for GCC 14

[David Brown]

On 14/05/2023 07:38, Po Lu via Gcc wrote:


No, all you have to do is to tell GNU CC to compile Standard C.  But
what's being debated here is the behavior of GNU CC when translating
both Standard C and GNU C, so your demonstration is almost completely
pointless.


You keep using the term "Standard C", but you are using it incorrectly.

"Standard C" means "The language C as recognised by standardisation 
bodies".  It is, currently, ISO/IEC 9899:2018 - also known as C17/C18. 
(The standard was completed in C17, but not actually published until C18.)


If you want to refer to older standards (or unpublished future 
standards), you should do so explicitly - C90, C99, C11, C23.


Then there are "extended standards" - specific documented extensions on 
top of an official standard.  "gnu17" would be an example of that.


Any language from before the first ANSI C is /not/ standard, since it is 
not based on any standards document.  The nearest would be the de-facto 
"standard" (anything "de-facto" is, by definition, not an actual 
standard) language described in the first edition of "The C Programming 
Language", and known as "K&R C".  Many of the C compilers of that time 
followed the book and implemented - modulo bugs, extensions, 
inconsistencies, and missing features - the language "K&R C".  Many also 
had their own variants, as "C" was already popular before the book was 
published.



So - if you are referring to "K&R C", then use that term.  It is quite 
well defined, and accurately describes a popular pre-standard C language.


And you may note that if you look at the GCC manual, it supports all 
standards of C (at least as closely as possible).  All /standards/. 
"K&R C" is not a standard, and not officially supported by GCC - there 
has never, to my knowledge, been any kind of guarantee that GCC would 
support pre-standard syntax.  There has only been a guarantee that 
appropriate choices of flags would cause pre-standard syntax to be 
detected and rejected or diagnosed.  Ironically, the discussion here, 
with its suggestions of explicit flags to allow "K&R C" constructs, has 
come closer to guaranteeing support for that pre-standard dialect than 
GCC has ever had before.








(When people refer to "ANSI C", they almost invariably mean the ANSI 
standard from 1989 that formed, after a bit of section renumbering, ISO 
C90, it is worth remembering that ANSI actually delegates the C 
standardisation to ISO.  So "ANSI C" refers to the same language as 
C17/C18.)

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Sun, 14 May 2023, 10:47 David Brown,  wrote:

> On 14/05/2023 07:38, Po Lu via Gcc wrote:
>
> > No, all you have to do is to tell GNU CC to compile Standard C.  But
> > what's being debated here is the behavior of GNU CC when translating
> > both Standard C and GNU C, so your demonstration is almost completely
> > pointless.
> >
> You keep using the term "Standard C", but you are using it incorrectly.
>
> "Standard C" means "The language C as recognised by standardisation
> bodies".  It is, currently, ISO/IEC 9899:2018 - also known as C17/C18.
> (The standard was completed in C17, but not actually published until C18.)
>
> If you want to refer to older standards (or unpublished future
> standards), you should do so explicitly - C90, C99, C11, C23.
>
> Then there are "extended standards" - specific documented extensions on
> top of an official standard.  "gnu17" would be an example of that.
>
> Any language from before the first ANSI C is /not/ standard, since it is
> not based on any standards document.  The nearest would be the de-facto
> "standard" (anything "de-facto" is, by definition, not an actual
> standard) language described in the first edition of "The C Programming
> Language", and known as "K&R C".  Many of the C compilers of that time
> followed the book and implemented - modulo bugs, extensions,
> inconsistencies, and missing features - the language "K&R C".  Many also
> had their own variants, as "C" was already popular before the book was
> published.
>
>
> So - if you are referring to "K&R C", then use that term.  It is quite
> well defined, and accurately describes a popular pre-standard C language.
>
> And you may note that if you look at the GCC manual, it supports all
> standards of C (at least as closely as possible).  All /standards/.
> "K&R C" is not a standard, and not officially supported by GCC - there
> has never, to my knowledge, been any kind of guarantee that GCC would
> support pre-standard syntax.



There used to be the -traditional option which was deprecated in gcc 3.1
and removed in gcc 3.3

https://gcc.gnu.org/gcc-3.1/changes.html
https://gcc.gnu.org/gcc-3.3/changes.html

There has only been a guarantee that
> appropriate choices of flags would cause pre-standard syntax to be
> detected and rejected or diagnosed.  Ironically, the discussion here,
> with its suggestions of explicit flags to allow "K&R C" constructs, has
> come closer to guaranteeing support for that pre-standard dialect than
> GCC has ever had before.
>
> 
> 
>
>
>
>
> (When people refer to "ANSI C", they almost invariably mean the ANSI
> standard from 1989 that formed, after a bit of section renumbering, ISO
> C90, it is worth remembering that ANSI actually delegates the C
> standardisation to ISO.  So "ANSI C" refers to the same language as
> C17/C18.)
>
>
>

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Sun, 14 May 2023, 11:21 Jonathan Wakely,  wrote:

>
>
> On Sun, 14 May 2023, 10:47 David Brown,  wrote:
>
>> On 14/05/2023 07:38, Po Lu via Gcc wrote:
>>
>> > No, all you have to do is to tell GNU CC to compile Standard C.  But
>> > what's being debated here is the behavior of GNU CC when translating
>> > both Standard C and GNU C, so your demonstration is almost completely
>> > pointless.
>> >
>> You keep using the term "Standard C", but you are using it incorrectly.
>>
>> "Standard C" means "The language C as recognised by standardisation
>> bodies".  It is, currently, ISO/IEC 9899:2018 - also known as C17/C18.
>> (The standard was completed in C17, but not actually published until C18.)
>>
>> If you want to refer to older standards (or unpublished future
>> standards), you should do so explicitly - C90, C99, C11, C23.
>>
>> Then there are "extended standards" - specific documented extensions on
>> top of an official standard.  "gnu17" would be an example of that.
>>
>> Any language from before the first ANSI C is /not/ standard, since it is
>> not based on any standards document.  The nearest would be the de-facto
>> "standard" (anything "de-facto" is, by definition, not an actual
>> standard) language described in the first edition of "The C Programming
>> Language", and known as "K&R C".  Many of the C compilers of that time
>> followed the book and implemented - modulo bugs, extensions,
>> inconsistencies, and missing features - the language "K&R C".  Many also
>> had their own variants, as "C" was already popular before the book was
>> published.
>>
>>
>> So - if you are referring to "K&R C", then use that term.  It is quite
>> well defined, and accurately describes a popular pre-standard C language.
>>
>> And you may note that if you look at the GCC manual, it supports all
>> standards of C (at least as closely as possible).  All /standards/.
>> "K&R C" is not a standard, and not officially supported by GCC - there
>> has never, to my knowledge, been any kind of guarantee that GCC would
>> support pre-standard syntax.
>
>
>
> There used to be the -traditional option which was deprecated in gcc 3.1
> and removed in gcc 3.3
>
> https://gcc.gnu.org/gcc-3.1/changes.html
> https://gcc.gnu.org/gcc-3.3/changes.html
>

But even as far back as gcc 2.95.3 that was documented only to "attempt" to
support "some" features of pre -standard C:

"Attempt to support some aspects of traditional C compilers."



>
> There has only been a guarantee that
>> appropriate choices of flags would cause pre-standard syntax to be
>> detected and rejected or diagnosed.  Ironically, the discussion here,
>> with its suggestions of explicit flags to allow "K&R C" constructs, has
>> come closer to guaranteeing support for that pre-standard dialect than
>> GCC has ever had before.
>>
>> 
>> 
>>
>>
>>
>>
>> (When people refer to "ANSI C", they almost invariably mean the ANSI
>> standard from 1989 that formed, after a bit of section renumbering, ISO
>> C90, it is worth remembering that ANSI actually delegates the C
>> standardisation to ISO.  So "ANSI C" refers to the same language as
>> C17/C18.)
>>
>>
>>

Re: More C type errors by default for GCC 14

[David Brown]

On 14/05/2023 07:28, Po Lu via Gcc wrote:

Eli Schwartz  writes:


Quoting my previous reply on the topic.

Until everyone is on the same page as you about whether these are GNUC
extensions, this conversation will go nowhere.

You are of the opinion that "GCC currently behaves a certain way when
compiling the code" means that the behavior is documented and specified
as a "C Extension" for the GNUC language dialect.


Yes, by the definition of ``extension'' used by everyone except you.


I can't speak for "everyone", and I don't think you can either.  But I 
believe I am safe in saying that everyone who has expressed an opinion 
in this thread, agrees with Eli's definition - GCC C extensions are what 
the GCC C manual documents as extensions.


The behaviour of a particular compiler does not define the extensions. 
At best, these are "undocumented features" - if you find them consistent 
enough and useful enough on a particular version of a particular 
compiler, then you may be willing to rely on them despite a lack of any 
kind of guarantees or documentation.


(You might note that there are several compilers, not just GCC, that 
implement many of the GNU C extensions.  I don't believe any of them 
makes any guarantees about your imagined undocumented extensions either.)





Undefined and undocumented behavior is not a language extension. It is
undefined and undocumented behavior.


But when it becomes defined by the translator, in a precise way, it
becomes an extension to the Standard.


No, it becomes an artefact of the particular implementation.  And if you 
have studied that implementation closely enough to see that it fulfils 
the specifications you want, not just its actual specifications, then 
feel free to keep that implementation and use it.  But you have 
absolutely no basis for expecting that any other implementation (such as 
future gcc versions) implement the same undocumented specifications.





You may feel free to take an exact GCC release (source or binary),
analyze it, reverse-engineer it, or verify that it does what you want
it to do, and then trust that those undefined and undocumented
behaviors are ***benevolent***, but that doesn't cause it to be
defined and documented, and your trust will, if you are wise, depend
on you pinning an exact source code commit of the compiler. Do not
depend on bugfix releases of GCC to preserve your undocumented
semantics. They may or they may not, but if they don't, it's not a GCC
bug, because it is ***undocumented***.


GCC does not implement its documentation.  The documentation is supposed
to describe (_not_ specify) how GCC behaves, and when the documentation
is wrong or contains omissions, the documentation will have to be fixed.
Not the compiler itself.

And it's not just GCC.  Almost all programs work this way.



It is a sad fact that many programs /are/ written that way - rushed 
coding under a manager's whip until the code works well enough to pass 
some basic tests, then it is shipped to end users.  Documentation, if 
any, is written afterwards with barely a nod towards a specification.


The /correct/ way to write code is to specify first (as formally and 
thoroughly as appropriate for the project), and have everyone agree that 
the specification fulfils the requirements for the program and that it 
is feasible to implement in practice.  /Then/ start writing code.  If 
the specification is user readable, then it forms the basis for the user 
documentation - if not, then user documentation can be written before, 
during or after code development.


For a living and evolving project like GCC, this all works in lots of 
small steps and in practice changes to the code and changes to the 
documented specifications get committed together, to keep them 
synchronised.  But it is always logically a documented feature and code 
that implements that specification.  (The specification can be a bug 
report, not just the user documentation.)



Attempting to do what you describe - look at the behaviour of gcc in 
practice, document it and call it the specification - would be insane. 
I've already tried to explain on this thread how the logical consequence 
of such ideas is total stagnation of the gcc development.  Look at the 
bugzilla database for GCC - it is /huge/.  Every (valid) bug there is a 
case where GCC does not do what it was supposed to do - what it is 
/documented/ to do.  You would have the GCC folks spend their time 
updating the documentation to redefine these bugs as previously 
undocumented features, rather than fixing the bugs in the code, and 
requiring all future versions of gcc to maintain bug-for-bug 
compatibility with the older versions.


Or could it be that you think this only applies to the features that 
/you/, personally, want to keep?  Sod the rest of the world, as long as 
/you/ don't need to fix your code?



I've come across a fair number of C programmers with your attitude 
before.  Generally they don't realise the con

GCC 12.3.0 regression, ccache 4.8.0 build fails witch ICE, upstream fix identified

[Thomas Backlund via Gcc]

ccache 4.8.0 build fails with ICE when building with gcc 12.3.0:
https://bugs.mageia.org/show_bug.cgi?id=31893#c0
regression introduced in gcc-12-20230421 snapshot by commit:

From 890d711a2477119a34cf435f6159b6253b124374 Mon Sep 17 00:00:00 2001
From: Jason Merrill <
ja...@redhat.com
>
Date: Thu, 16 Mar 2023 15:11:25 -0400
Subject: [PATCH 35/61] c++: generic lambda, local class, __func__ [PR108242]

I fixed  gcc ICE by backporting from upstream master branch:

From 4872e46e080c6695dfe1f9dc9db26b4703bc348c Mon Sep 17 00:00:00 2001
From: Jason Merrill <
ja...@redhat.com
>
Date: Wed, 22 Mar 2023 16:11:47 -0400
Subject: [PATCH] c++: local class in nested generic lambda [PR109241]

--
Thomas

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Eli Schwartz  writes:

> Does this mean you've conceded the point, and no longer think it is
> written in C++?

No.

> You are correct in reading my sentence, that is indeed what I said.
>
> Aside: you have reiterated "the behavior of the translator itself" over
> and over again, but it hasn't been generally reiterated, or even iterated.

Parse error.

> Repeating this statement won't make it true.

Before you say this, I suggest that you take some time to look at
yourself in a mirror.

> In fact, lots and lots and lots of programs do indeed operate such that
> the documentation specifies how the program shall behave, and when the
> program fails to behave in the manner in which it is documented to
> behave, the program shall be fixed.
>
> We call these failures to behave according to the documentation,
>
>
> Bugs.
>
>
> Occasionally it is also called specification-driven development.
>
> ...
>
> In cases where the documentation says nothing at all, for good or ill,
> the behavior of the program is undefined -- users cannot rely on it, for
> they cannot know what is intended and what is not intended -- in this
> case, the intended behavior must be defined, documented, and
> implemented, and "the program currently does X" gets one vote out of
> many and is not guaranteed to get its way.
>
> Very often in such cases the best user-serving thing to do is to define
> the behavior as "shall not be used, and for legacy reasons if you use it
> it will continue to do X but raise a warning telling you that you are
> required to stop depending on it" and possibly even "it may disappear in
> semver version YYY".

Where is it written that GNU CC follows your so-called
``specification-driven development''?

Here is an explanation from one of the original GCC developers.  It
discusses strict aliasing, but the same principles apply here:

(199909100634.caa01...@psilocin.gnu.org)

  My comment is similar to Mark's comment.  Documentation, what can
  we document as working?

  We should not even try to document that these cases work.
  Documentation is what we do when we add a feature.

  I am not proposing this as a feature, just as a way to avoid evitable
  trouble for users.  We should not even try to document a class of
  cases that are "supposed" to work, because I'm not saying these are
  "supposed" to work.  We should just let them work.
   

  Anway, more questions from me than answers...  Off hand though, if
  we can make the compiler generate `right' code in more cases, even
  if the users code is wrong, I think we should probably do it.

  In C, we cannot divide all user code into "right" and "wrong" in this
  kind of simple way, and certainly not based on the ISO standard.  That
  standard is just the decisions of a certain committee (which I was a
  member of) about what cases conforming compilers should commit to
  support.  We must not let ourselves start thinking that C code is
  "wrong", just because it is not conforming ISO C code.

  C programs use many cases that are not conforming, but do work.  This
  will be true for as long as C is used, because changing it would
  require major changes in the C language.

  From time to time, there is a real *need* to make some of these cases
  stop working, for the sake of some benefit that users want.  When this
  happens, we should do it; the user community will accept it, because
  they will see that it is being done for their sake.  Some will
  grumble, but the users who appreciate the benefits will convince them.

  But when there is no *need* to break these cases, when we can keep
  them working fairly easily, we should keep them working.  If we break
  them unnecessarily, we invite the legitimate anger of the users.

and another (199909100634.caa01...@psilocin.gnu.org):

  However, I have a rather serious objection: it means that users
  cannot tell whether their code is valid, even according to the GCC
  rules, without knowing the internals of the compiler.

  This has always been true.  It is true in the current version of GCC
  with regard to aliasing, even when -fstrict-aliasing is used.  It is
  part of the nature of C.

  The goal of trying to avoid it is unrealistic and misguided; it can't
  be done.  So this cannot be a valid reason to reject a change.

  The compiler should continue to aggressively break code that
  misbehaves in this way.

  This proposes to break users' code, just to bully them into changing
  it.  That is a callous and harsh attitude towards the users of GCC.
  No wonder users are angry.  They know that the problems are not due to
  necessity, but due to callous disregard for them.

  We cannot do everything all users want, and sometimes a maintainer has
  to say no to users.  "You cannot please everyone," as the saying goes.
  There are many kinds of reasons which can sometimes be good reasons to
  say no.

  But maintainers should always say

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Jonathan Wakely  writes:

> Wrong. I wouldn't bother replying to you again in this thread, but I
> feel that as a gcc maintainer I should confirm that Eli S. is right
> here; and nobody else I know agrees with your definition of extension
> as "every non-standard aspect of the compiler's behaviour, whether
> intentional or accidental". That's just silly.

GCC's support for implicit int is clearly intentional.
I never claimed that accidental GNU CC behavior was part of GNU C.

> No, Eli S. is quite right.

[...]

> And when the compiler is wrong and the documentation is correct, the
> compiler is fixed.

And the documentation is wrong, while the translator is correct.

GCC development, being part of the GNU project, is supposed to act in
its interests and that of Free Software in general.  I remind you of of
this statement, which was made here, on this list, by clearer minds:

  We cannot do everything all users want, and sometimes a maintainer has
  to say no to users.  "You cannot please everyone," as the saying goes.
  There are many kinds of reasons which can sometimes be good reasons to
  say no.

  But maintainers should always say no reluctantly--never eagerly.  We
  should never aggressively cause trouble for users today, just because
  someday it might be necessary.  That is like amputating limbs because
  someday they might be crushed.

  This treatment of users brings shame on the GNU Project.  I ask
  everyone therefore not to suggest that we should treat users this way.

And yes, such shameful treatment is directly harmful to the goals of the
GNU Project: at least one organization, likely more, has been forced to
adopt proprietary compilers as a direct result.

Re: More C type errors by default for GCC 14

[Mark Wielaard]

Hi Po,

On Fri, May 12, 2023 at 09:53:30PM +0800, Po Lu via Gcc wrote:
> I don't want anything, seeing as I've been using GCC less and less over
> the years (for this and other reasons.)  I'm just throwing in my two or
> so cents.

I think you have contributed more than two cents and it time to stop
repeating your opinion over and over again (and for others to stop
replying to your posts). You have posted more than anybody else to
this thread and it is not contributing anything new. Please let the
actual gcc maintainers work out the technical details of the default
diagnostics.

Thanks,

Mark

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Po Lu via Gcc  writes:

...

> Where is it written that GNU CC follows your so-called
> ``specification-driven development''?

Any development style making documentation a source of truth matches
this principle.  This does not refer to ISO specifications specifically,
though, normally, unless the standard disagrees with reality, as
implicit-... did many years ago, ISO decisions are taken seriously.

> Here is an explanation from one of the original GCC developers.  It
> discusses strict aliasing, but the same principles apply here:
>
> (199909100634.caa01...@psilocin.gnu.org)
>
>   My comment is similar to Mark's comment.  Documentation, what can
>   we document as working?
>
>   We should not even try to document that these cases work.
>   Documentation is what we do when we add a feature.
>
>   I am not proposing this as a feature, just as a way to avoid evitable
>   trouble for users.  We should not even try to document a class of
>   cases that are "supposed" to work, because I'm not saying these are
>   "supposed" to work.  We should just let them work.
>
>
>   Anway, more questions from me than answers...  Off hand though, if
>   we can make the compiler generate `right' code in more cases, even
>   if the users code is wrong, I think we should probably do it.
>
>   In C, we cannot divide all user code into "right" and "wrong" in this
>   kind of simple way, and certainly not based on the ISO standard.  That
>   standard is just the decisions of a certain committee (which I was a
>   member of) about what cases conforming compilers should commit to
>   support.  We must not let ourselves start thinking that C code is
>   "wrong", just because it is not conforming ISO C code.
>
>   C programs use many cases that are not conforming, but do work.  This
>   will be true for as long as C is used, because changing it would
>   require major changes in the C language.
>
>   From time to time, there is a real *need* to make some of these cases
>   stop working, for the sake of some benefit that users want.  When this
>   happens, we should do it; the user community will accept it, because
>   they will see that it is being done for their sake.  Some will
>   grumble, but the users who appreciate the benefits will convince them.
>
>   But when there is no *need* to break these cases, when we can keep
>   them working fairly easily, we should keep them working.  If we break
>   them unnecessarily, we invite the legitimate anger of the users.
>
> and another (199909100634.caa01...@psilocin.gnu.org):
>
>   However, I have a rather serious objection: it means that users
>   cannot tell whether their code is valid, even according to the GCC
>   rules, without knowing the internals of the compiler.
>
>   This has always been true.  It is true in the current version of GCC
>   with regard to aliasing, even when -fstrict-aliasing is used.  It is
>   part of the nature of C.
>
>   The goal of trying to avoid it is unrealistic and misguided; it can't
>   be done.  So this cannot be a valid reason to reject a change.
>
>   The compiler should continue to aggressively break code that
>   misbehaves in this way.
>
>   This proposes to break users' code, just to bully them into changing
>   it.  That is a callous and harsh attitude towards the users of GCC.
>   No wonder users are angry.  They know that the problems are not due to
>   necessity, but due to callous disregard for them.
>
>   We cannot do everything all users want, and sometimes a maintainer has
>   to say no to users.  "You cannot please everyone," as the saying goes.
>   There are many kinds of reasons which can sometimes be good reasons to
>   say no.
>
>   But maintainers should always say no reluctantly--never eagerly.  We
>   should never aggressively cause trouble for users today, just because
>   someday it might be necessary.  That is like amputating limbs because
>   someday they might be crushed.
>
>   This treatment of users brings shame on the GNU Project.  I ask
>   everyone therefore not to suggest that we should treat users this way.
>
>> Sound familiar? A bit like GCC triggering a warning, telling you that
>> what you're doing is bad and should not be relied on?
>
> A diagnostic message is supposed to inform me of a diagnosis by the
> translator.  The severity of the diagnosis, is, as always, up to the
> user to decide, as long as enough information remains for translation to
> continue.

It is, after this proposal is accepted, still up to the user to decide.
The only difference is that the default would be friendlier to new code
and users and most code that exists today, rather than to very old code
and incorrect code.

Additionally, there isn't enough information to compile.  The compiler
makes up new information to fill in the gaps.

If that definition accepted, most error recovery should be turned into
valid code paths that participate as GNU exte

Re: More C type errors by default for GCC 14

[Nicholas Vinson via Gcc]

Jonathan Wakely  writes:

Wrong. I wouldn't bother replying to you again in this thread, but I
feel that as a gcc maintainer I should confirm that Eli S. is right
here; and nobody else I know agrees with your definition of extension
as "every non-standard aspect of the compiler's behaviour, whether
intentional or accidental". That's just silly.

GCC's support for implicit int is clearly intentional.
I never claimed that accidental GNU CC behavior was part of GNU C.


You might not have explicitly stated that, but you have made that 
argument in this thread.


You have asserted that the compiler's behavior, and not its 
documentation, determines what should be consider a language extension.


That assertion when taken to its natural conclusion show support for the 
idea that "accidental GNU CC behavior" should be considered a language 
extension, and by becoming a language extension it would be part of GNU C.


If the behavior, and not the documentation, determines what is and is 
not an extension unless it's "accidental behavior", then how is anyone 
to know what is or is not a GNU C extension?

Re: GCC 12.3.0 regression, ccache 4.8.0 build fails witch ICE, upstream fix identified

[Paul Smith]

FYI I reported this crash to the GCC bugzilla yesterday:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850

and it was closed as a dup of this:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241

If people want to watch it.


On Sun, 2023-05-14 at 10:50 +, Thomas Backlund via Gcc wrote:
> ccache 4.8.0 build fails with ICE when building with gcc 12.3.0:
> https://bugs.mageia.org/show_bug.cgi?id=31893#c0
> regression introduced in gcc-12-20230421 snapshot by commit:
> 
> From 890d711a2477119a34cf435f6159b6253b124374 Mon Sep 17 00:00:00
> 2001
> From: Jason Merrill <
> ja...@redhat.com
> > 
> Date: Thu, 16 Mar 2023 15:11:25 -0400
> Subject: [PATCH 35/61] c++: generic lambda, local class, __func__
> [PR108242]
> 
> I fixed  gcc ICE by backporting from upstream master branch:
> 
> From 4872e46e080c6695dfe1f9dc9db26b4703bc348c Mon Sep 17 00:00:00
> 2001
> From: Jason Merrill <
> ja...@redhat.com
> > 
> Date: Wed, 22 Mar 2023 16:11:47 -0400
> Subject: [PATCH] c++: local class in nested generic lambda [PR109241]
> 
> --
> Thomas

gcc-14-20230514 is now available

[GCC Administrator via Gcc]

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

This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision aed51e2051b24a6a2127c6626f451641557a571a

You'll find:

 gcc-14-20230514.tar.xz   Complete GCC

  SHA256=e72a048782d00d774f98c72aa6f6027d01b18bcae6ab9d46e31f806786c2f66e
  SHA1=6b7289b1b43b5716791e494a76a63f1fd8cbdab8

Diffs from 14-20230507 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-14
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

[Po Lu via Gcc]

Arsen Arsenović  writes:

> Any development style making documentation a source of truth matches
> this principle.  This does not refer to ISO specifications specifically,
> though, normally, unless the standard disagrees with reality, as
> implicit-... did many years ago, ISO decisions are taken seriously.

We're not talking about the C Standard here.  Eli S. is claiming that
gcc.info is the source of truth for the behavior of GCC, and whenever
some behavior of GCC is not documented (or contradicts the
documentation), GCC should be fixed to behave as its documentation
specifies.

> It is, after this proposal is accepted, still up to the user to decide.
> The only difference is that the default would be friendlier to new code
> and users and most code that exists today, rather than to very old code
> and incorrect code.

That's not correct.  It would be as friendly to new code as it is now --
but old (and very likely still correct) code would be put at a
disadvantage.

> Additionally, there isn't enough information to compile.  The compiler
> makes up new information to fill in the gaps.

According to a specific formula that all C programmers (at least, those
who write such code) know.

> If that definition accepted, most error recovery should be turned into
> valid code paths that participate as GNU extensions, for instance,
> there's no reason that:
>
>int f (int x) { x += 10 return x + 123 }
>
> shouldn't compile, as the compiler knows where to insert semicolons to
> make it (probably) work.  I'd say that extension is more acceptable than
> the ones being proposed into turning into errors by default, since it
> isn't very ambiguous, unlike an implicit function declaration or such.

Unfortunately, this has never worked in any C compiler, and is very
ambiguous.  Implicit int and function declarations have been included in
every ANSI and K&R C compiler, and then some more after that, so what
the compiler should do is very precisely specified and known.

> It has been 25 years since the addition of -fpermissive to G++.  I'm
> optimistic.

But -fpermissive is considered ``useful'' by the many loud people who
find it necessary to compile C as C++.