Re: More C type errors by default for GCC 14

* Jason Merrill: > As a compromise, it should be possible to error by default only in > cases where the implicit int (including as a return value) is either > the source or target of a non-value-preserving conversion, as those > are very likely to be bugs. That seems desirable for both camps. No

Re: More C type errors by default for GCC 14

On Tue, May 16, 2023 at 3:06 AM Florian Weimer via Gcc wrote: > * Eric Gallager via Gcc: > > > I support this plan for using -Werror= and having it be split based on > > whether -std= is set to a strict ANSI option or a GNU option; is there > > a way to do that in the optfiles, or would it have t

Re: More C type errors by default for GCC 14

* Jakub Jelinek: > On Tue, May 16, 2023 at 01:39:26PM +0300, Alexander Monakov wrote: >> >> On Tue, 16 May 2023, Florian Weimer wrote: >> >> > > (FWIW: no, this should not be an error, a warning is fine, and I >> > > actually >> > > think the current state of it not being in Wall is the right

Re: More C type errors by default for GCC 14

On Tue, 16 May 2023 at 12:01, Jakub Jelinek wrote: > > On Tue, May 16, 2023 at 01:39:26PM +0300, Alexander Monakov wrote: > > > > On Tue, 16 May 2023, Florian Weimer wrote: > > > > > > (FWIW: no, this should not be an error, a warning is fine, and I > > > > actually > > > > think the current state

Re: More C type errors by default for GCC 14

On Tue, May 16, 2023 at 01:39:26PM +0300, Alexander Monakov wrote: > > On Tue, 16 May 2023, Florian Weimer wrote: > > > > (FWIW: no, this should not be an error, a warning is fine, and I actually > > > think the current state of it not being in Wall is the right thing as > > > well) > > (this

Re: More C type errors by default for GCC 14

On Tue, 16 May 2023, Florian Weimer wrote: > > (FWIW: no, this should not be an error, a warning is fine, and I actually > > think the current state of it not being in Wall is the right thing as > > well) (this is mixed up, -Wpointer-sign is in fact enabled by -Wall) > I don't understand why

Re: More C type errors by default for GCC 14

* Michael Matz: > Hello, > > On Fri, 12 May 2023, Florian Weimer wrote: > >> * Alexander Monakov: >> >> > This is not valid (constraint violation): >> > >> > unsigned x; >> > >> > int *p = &x; >> > >> > In GCC this is diagnosed under -Wpointer-sign: >> > >> > https://gcc.gnu.org/bugzilla/sh

Re: More C type errors by default for GCC 14

* Eric Gallager via Gcc: > I support this plan for using -Werror= and having it be split based on > whether -std= is set to a strict ANSI option or a GNU option; is there > a way to do that in the optfiles, or would it have to be handled at > the specs level instead? This isn't going to work well

Re: More C type errors by default for GCC 14

On 5/15/23, Richard Earnshaw (lists) via Gcc wrote: > On 10/05/2023 03:38, Eli Zaretskii via Gcc wrote: >>> From: Arsen Arsenović >>> Cc: Eli Zaretskii , Jakub Jelinek , >>> jwakely@gmail.com, gcc@gcc.gnu.org >>> Date: Tue, 09 May 2023 22:21:03 +0200 >>> The concern is using the good w

Re: More C type errors by default for GCC 14

On 12/05/2023 13:30, Jakub Jelinek via Gcc wrote: On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote: One fairly big GCC-internal task is to clear up the C test suite so that it passes with the new compiler defaults. I already have an offer of help for that, so I think we can complet

Re: More C type errors by default for GCC 14

Hello, On Fri, 12 May 2023, Florian Weimer wrote: > * Alexander Monakov: > > > This is not valid (constraint violation): > > > > unsigned x; > > > > int *p = &x; > > > > In GCC this is diagnosed under -Wpointer-sign: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892 > > Thanks fo

Re: More C type errors by default for GCC 14

Hello, On Fri, 12 May 2023, Jakub Jelinek via Gcc wrote: > On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote: > > > One fairly big GCC-internal task is to clear up the C test suite so that > > > it passes with the new compiler defaults. I already have an offer of > > > help for that,

Re: More C type errors by default for GCC 14

On 10/05/2023 03:38, Eli Zaretskii via Gcc wrote: From: Arsen Arsenović Cc: Eli Zaretskii , Jakub Jelinek , jwakely@gmail.com, gcc@gcc.gnu.org Date: Tue, 09 May 2023 22:21:03 +0200 The concern is using the good will of the GNU Toolchain brand as the tip of the spear or battering ram to m

Re: More C type errors by default for GCC 14

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 s

Re: More C type errors by default for GCC 14

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, whethe

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

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 sto

Re: More C type errors by default for GCC 14

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,

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

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 c

Re: More C type errors by default for GCC 14

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 transl

Re: More C type errors by default for GCC 14

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 al

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

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 behav

Re: More C type errors by default for GCC 14

On 5/14/23 1:28 AM, Po Lu wrote: >> 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

Re: More C type errors by default for GCC 14

On 5/14/23 1:28 AM, Po Lu wrote: >> 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*** mean

Re: More C type errors by default for GCC 14

Eli Schwartz writes: > GNU C does not define any such thing. It may happen to turn out that > way, but that is not the same as defining its behavior. It is. >> Nor does GCC conform to the Standard by default: while it is okay for a >> conforming implementation to translate programs relying on i

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

On 5/13/23 1:53 AM, Po Lu wrote: > There are no ``errors'' in Standard C (with the possible exception of > the #error preprocessing directive), only constraint and syntax rule > violations. Such violations are required to generate diagnostic > messages, after which the behavior of the translator c

Re: More C type errors by default for GCC 14

On 5/12/23 8:45 PM, Po Lu wrote: > Gabriel Ravier writes: > >> ...You're joking, right ? You can't possibly be seriously arguing >> this, you have to be kidding... right ? > > No, I'm not. The meaning of a variable declaration with only a storage > class specifier is extremely clear: the type o

Re: More C type errors by default for GCC 14

Thomas Koenig writes: > C99, 6.7.2, "Type specifiers" > > # Constraints > > # At least one type specifier shall be given in the declaration > # specifiers in each declaration, and in the specifier-qualifier > # list in each struct declaration and type name. And? > In C99 and onwards, this is an

Re: More C type errors by default for GCC 14

On 13.05.23 02:45, Po Lu via Gcc wrote: Gabriel Ravier writes: ...You're joking, right ? You can't possibly be seriously arguing this, you have to be kidding... right ? No, I'm not. The meaning of a variable declaration with only a storage class specifier is extremely clear: the type of the

Re: More C type errors by default for GCC 14

Gabriel Ravier writes: > ...You're joking, right ? You can't possibly be seriously arguing > this, you have to be kidding... right ? No, I'm not. The meaning of a variable declaration with only a storage class specifier is extremely clear: the type of the variable is `int'. There's absolutely n

Re: More C type errors by default for GCC 14

* Sam James: > Florian Weimer writes: > >> * Sam James: >> >>> Florian Weimer writes: >>> [...] In summary, all these seems to be good candidates for errors by default: * int-conversion as errors (already raised separately * -Wint-conversion for ?: * parameter names

Re: More C type errors by default for GCC 14

Florian Weimer writes: > * Sam James: > >> Florian Weimer writes: >> >>> [...] >>> In summary, all these seems to be good candidates for errors by default: >>> >>> * int-conversion as errors (already raised separately >>> * -Wint-conversion for ?: >>> * parameter names in non-prototype functio

Re: More C type errors by default for GCC 14

* Sam James: > Florian Weimer writes: > >> [...] >> In summary, all these seems to be good candidates for errors by default: >> >> * int-conversion as errors (already raised separately >> * -Wint-conversion for ?: >> * parameter names in non-prototype function declarations >> * the union wait fun

Re: More C type errors by default for GCC 14

Florian Weimer writes: > [...] > In summary, all these seems to be good candidates for errors by default: > > * int-conversion as errors (already raised separately > * -Wint-conversion for ?: > * parameter names in non-prototype function declarations > * the union wait function pointer compatibi

Re: More C type errors by default for GCC 14

Florian Weimer writes: > * Jason Merrill: > >> On Fri, May 12, 2023 at 11:03 AM Florian Weimer wrote: >>> >>> * 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

Re: More C type errors by default for GCC 14

* Jason Merrill: > On Fri, May 12, 2023 at 11:03 AM Florian Weimer wrote: >> >> * 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

Re: More C type errors by default for GCC 14

* Joseph Myers: > On Fri, 12 May 2023, Florian Weimer wrote: > >> This sone seems to be a good candidate for additional errors, though: >> >> warned_here = pedwarn >> (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0, >> "% with no value, in function returning non-void"); >> >> It's

Re: More C type errors by default for GCC 14

On Fri, May 12, 2023 at 11:03 AM Florian Weimer wrote: > > * 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

Re: More C type errors by default for GCC 14

On Fri, 12 May 2023, Florian Weimer wrote: > This sone seems to be a good candidate for additional errors, though: > > warned_here = pedwarn > (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0, > "% with no value, in function returning non-void"); > > It's a clear type volation that

Re: More C type errors by default for GCC 14

* Alexander Monakov: > This is not valid (constraint violation): > > unsigned x; > > int *p = &x; > > In GCC this is diagnosed under -Wpointer-sign: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892 Thanks for the reference. I filed: -Wpointer-sign must be enabled by default

Re: More C type errors by default for GCC 14

On Fri, 12 May 2023, Gabriel Ravier via Gcc wrote: > On 5/12/23 19:52, Florian Weimer wrote: > > I think we have another problem. > > > > We do not warn by default for: > > > >int x; > >unsigned *p; > > > >p = &x; > > > > Isn't that a conformance issue because the pointers are incomp

Re: More C type errors by default for GCC 14

* Gabriel Ravier: > On 5/12/23 19:52, Florian Weimer wrote: >> * Florian Weimer: >> >>> In summary, all these seems to be good candidates for errors by default: >>> >>> * int-conversion as errors (already raised separately >>> * -Wint-conversion for ?: >>> * parameter names in non-prototype functi

Re: More C type errors by default for GCC 14

On 5/12/23 19:52, Florian Weimer wrote: * Florian Weimer: In summary, all these seems to be good candidates for errors by default: * int-conversion as errors (already raised separately * -Wint-conversion for ?: * parameter names in non-prototype function declarations * the union wait function

Re: More C type errors by default for GCC 14

* Florian Weimer: > In summary, all these seems to be good candidates for errors by default: > > * int-conversion as errors (already raised separately > * -Wint-conversion for ?: > * parameter names in non-prototype function declarations > * the union wait function pointer compatibility kludge > *

Re: More C type errors by default for GCC 14

On Fri, May 12, 2023 at 9:20 AM Po Lu via Gcc wrote: > Yes, just these quotes from a former GCC maintainer: > > 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

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

Re: More C type errors by default for GCC 14

On Fri, 12 May 2023 at 14:54, Po Lu via Gcc wrote: > From my perspective, I also see only a few extremely loud people > repeating the same arguments over and over. Maybe stop then? > But how many times have I > mentioned that? The number of people in this thread is too small to > conclude anyth

Re: More C type errors by default for GCC 14

Gabriel Ravier writes: > As somebody that spends a lot of time helping beginners, yes, > constantly. I'd go as far as to say it's an error that seemingly > everyone has made at least once. Really? And after making this mistake (and learning its solution), did they continue to make the same mist

Re: More C type errors by default for GCC 14

Eli Schwartz writes: > This sounds like a "you" problem. I don't write these Makefiles. Others do. It wasn't the problem of their authors before, so why should it be now?

Re: More C type errors by default for GCC 14

Gabriel Ravier writes: > It's "extra work" to add 10 characters to a Makefile, but normal to > add random faulty declarations everywhere ? You're assuming that people are willing to edit Makefiles, which is all kinds of pain, and then put up with a complete recompile of whatever software is bei

Re: More C type errors by default for GCC 14

Pedro Alves writes: > Then write a wrapper script named "cc", and put that in the PATH: > > $ cat cc > #!/bin/sh > > exec /my/real/gcc -fwhatever "$@" > > Done. And how many people are going to be forced to do this? Though this is a good point: I suspect if such an option were actually added

Re: More C type errors by default for GCC 14

On 5/12/23 15:19, Po Lu via Gcc wrote: Jonathan Wakely writes: It's not about popularity. If that's your takeaway then you're not paying attention, whatever you claim about reading everything in the thread. It's about helping people write correct code, first time, without some of the avoidabl

Re: More C type errors by default for GCC 14

Jonathan Wakely writes: > Then they should not use implicit int and implicit function > declarations. And why is that? Is GCC really arrogant enough to think that it is the only C translator in the world? BTW, standards.info used to say something along the lines of: Do not declare functions

Re: More C type errors by default for GCC 14

Jonathan Wakely writes: > It's not about popularity. If that's your takeaway then you're not > paying attention, whatever you claim about reading everything in the > thread. It's about helping people write correct code, first time, > without some of the avoidable traps that C presents. > > The C

Re: More C type errors by default for GCC 14

On 5/12/23 04:36, Po Lu via Gcc wrote: Arsen Arsenović writes: Indeed they should be - but warning vs. error holds significance. A beginner is much less likely to be writing clever code that allegedly uses these features properly than to be building new code, and simply having made an error t

Re: More C type errors by default for GCC 14

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

Re: More C type errors by default for GCC 14

On 5/12/23 2:01 AM, Po Lu wrote: > Jason Merrill writes: > >> You shouldn't have to change any of those, just configure with CC="gcc >> -fwhatever". > > If it were so simple... > > Many Makefiles come with a habit of using not CC_FOR_BUILD, but just > `cc', to build programs which are run on th

Is the GNUC dialect anything that GCC does when given source code containing UB? (Was: More C type errors by default for GCC 14)

On 5/12/23 1:57 AM, Po Lu wrote: > Eli Schwartz writes: >> It's still no big deal, no matter how much you dramatize the intensity >> of adding a flag to your Makefiles. > > It's extra work. Why don't I just write: > > extern int foo (); > > above each of the new errors? > That is just about

Re: More C type errors by default for GCC 14

On 12/05/2023 04:08, Po Lu via Gcc wrote: Eli Schwartz writes: Because that's exactly what is going on here. Features that were valid C89 code are being used in a GNU99 or GNU11 code file, despite that ***not*** being valid GNU99 or GNU11 code. How GCC currently behaves defines what is va

Re: More C type errors by default for GCC 14

On 5/12/23 08:25, Eli Zaretskii via Gcc wrote: Date: Thu, 11 May 2023 18:43:32 -0400 Cc: luang...@yahoo.com, gcc@gcc.gnu.org From: Eli Schwartz On 5/11/23 2:24 AM, Eli Zaretskii wrote: Back to the subject: the guarantees I would personally like to have is that the current GCC development team

Re: More C type errors by default for GCC 14

On 5/12/23 07:57, Po Lu via Gcc wrote: Eli Schwartz writes: There are ***not*** thousands of Makefiles that have this issue. But if there were, then Makefiles are very easy to update, and only have to be updated once per project, not thousands of times. So this is fine. You may have to update

Re: More C type errors by default for GCC 14

On 2023-05-12 7:01 a.m., Po Lu via Gcc wrote: > Jason Merrill writes: > >> You shouldn't have to change any of those, just configure with CC="gcc >> -fwhatever". > > If it were so simple... > > Many Makefiles come with a habit of using not CC_FOR_BUILD, but just > `cc', to build programs which

Re: More C type errors by default for GCC 14

> Date: Fri, 12 May 2023 10:15:45 +0200 > From: Jakub Jelinek > Cc: Arsen Arsenović , luang...@yahoo.com, > jwakely@gmail.com, gcc@gcc.gnu.org > > On Fri, May 12, 2023 at 10:53:28AM +0300, Eli Zaretskii via Gcc wrote: > > > > Let's keep in mind that veterans are much more likely to h

Re: More C type errors by default for GCC 14

> From: Jonathan Wakely > Date: Fri, 12 May 2023 08:28:00 +0100 > Cc: Eli Schwartz , Po Lu , > "gcc@gcc.gnu.org" > > It is on topic because there doesn't seem to be anything in the > arguments brought up for this current proposal that couldn't be > brought up in favor of removing -fper

Re: More C type errors by default for GCC 14

On Fri, 12 May 2023 at 09:46, Christian Groessler wrote: > > On 5/12/23 09:53, Eli Zaretskii via Gcc wrote: > > > >> With all that to consider, is it *really* a significant cost to add > >> -fpermissive? > > > > See above (and my earlier message): the significant cost is to > > discover the root c

Re: More C type errors by default for GCC 14

Hi, On Tue, May 09 2023, Florian Weimer via Gcc wrote: > TL;DR: This message is about turning implicit-int, > implicit-function-declaration, and possibly int-conversion into errors > for GCC 14. > FWIW, I personally support the proposal. Regarding the huge discussion that ensued, I would just li

Re: More C type errors by default for GCC 14

On 12.05.23 09:53, Eli Zaretskii via Gcc wrote: I described in an earlier message how this breakage looks in real life, and why it causes a lot of frustration. The main problem is discovering that things broke because GCC defaults, and then discovering how to pacify GCC with the least effort.

Re: More C type errors by default for GCC 14

On 5/12/23 09:53, Eli Zaretskii via Gcc wrote: With all that to consider, is it *really* a significant cost to add -fpermissive? See above (and my earlier message): the significant cost is to discover the root cause of the problem, and that -fpermissive is the solution. The rest might be rel

Re: More C type errors by default for GCC 14

On Fri, May 12, 2023 at 10:53:28AM +0300, Eli Zaretskii via Gcc wrote: > > From: Arsen Arsenović > > Cc: luang...@yahoo.com, jwakely@gmail.com, gcc@gcc.gnu.org > > Date: Thu, 11 May 2023 21:25:53 +0200 > > > > >> This seems like a good route to me - it facilitates both veterans > > >> maintai

Re: More C type errors by default for GCC 14

> From: Arsen Arsenović > Cc: luang...@yahoo.com, jwakely@gmail.com, gcc@gcc.gnu.org > Date: Thu, 11 May 2023 21:25:53 +0200 > > >> This seems like a good route to me - it facilitates both veterans > >> maintaining code and beginners just learning how to write C. > > > > No, it prefers beginn

Re: More C type errors by default for GCC 14

On Fri, 12 May 2023, 07:56 Eli Zaretskii via Gcc, wrote: > > Date: Thu, 11 May 2023 23:07:55 -0400 > > Cc: gcc@gcc.gnu.org > > From: Eli Schwartz via Gcc > > > > > Being sceptical about the future is perfectly reasonable. > > > > My opinion on this is (still) that if your argument is that you do

Re: More C type errors by default for GCC 14

> Date: Thu, 11 May 2023 23:07:55 -0400 > Cc: gcc@gcc.gnu.org > From: Eli Schwartz via Gcc > > > Being sceptical about the future is perfectly reasonable. > > My opinion on this is (still) that if your argument is that you don't > want -fpermissive or -std=c89 to be removed, you are more than we

Re: More C type errors by default for GCC 14

> From: Jason Merrill > Date: Thu, 11 May 2023 22:55:07 -0400 > Cc: Eli Schwartz , Eli Zaretskii , > gcc@gcc.gnu.org > > > Because now people will have to go through dozens and dozens of > > Makefiles, configure.in, *.m4 > > You shouldn't have to change any of those, just configure with CC="gcc

Re: More C type errors by default for GCC 14

On Fri, 12 May 2023, 07:02 Po Lu via Gcc, wrote: > Jason Merrill writes: > > > You shouldn't have to change any of those, just configure with CC="gcc > > -fwhatever". > > If it were so simple... > > Many Makefiles come with a habit of using not CC_FOR_BUILD, but just > `cc', to build programs wh

Re: More C type errors by default for GCC 14

> Date: Thu, 11 May 2023 18:43:32 -0400 > Cc: luang...@yahoo.com, gcc@gcc.gnu.org > From: Eli Schwartz > > On 5/11/23 2:24 AM, Eli Zaretskii wrote: > > > Back to the subject: the guarantees I would personally like to have is > > that the current GCC development team sees backward compatibility a

Re: More C type errors by default for GCC 14

> Date: Thu, 11 May 2023 18:30:20 -0400 > Cc: luang...@yahoo.com, gcc@gcc.gnu.org > From: Eli Schwartz > > On 5/11/23 2:12 AM, Eli Zaretskii wrote: > > > > He is telling you that removing support for these old features, you > > draw users away from GCC and towards proprietary compilers. > > > >

Re: More C type errors by default for GCC 14

Jason Merrill writes: > You shouldn't have to change any of those, just configure with CC="gcc > -fwhatever". If it were so simple... Many Makefiles come with a habit of using not CC_FOR_BUILD, but just `cc', to build programs which are run on the build machine. These programs are intended to

Re: More C type errors by default for GCC 14

Eli Schwartz writes: > There are ***not*** thousands of Makefiles that have this issue. But if > there were, then Makefiles are very easy to update, and only have to be > updated once per project, not thousands of times. So this is fine. You > may have to update your Makefile, but that is no big

Re: More C type errors by default for GCC 14

Sam James writes: > They're using > c89/gnu89 often because defaults have changed (a point > others have raised, including Arsen and Eli Schwartz) even though they > weren't intended to be compiled with newer C. > > A fair amount of other projects do explicitly ask for either c99/gnu99 > or c11/g

Re: More C type errors by default for GCC 14

On 5/11/23 10:39 PM, Po Lu wrote: >> If so, then as far as I can tell, that was the original plan? The flag >> already exists, even. And the original proposal was to provide another >> flag that doesn't even restrict you to c89. > > And what will guarantee this ``always'' always remains true? No

Re: More C type errors by default for GCC 14

On 5/11/23 10:08 PM, Po Lu wrote: >> I do not consider that you are being told what to do with your code. >> Your code is not being broken. You may have to update your Makefile to > > > My code is being broken. There are thousa

Re: More C type errors by default for GCC 14

Po Lu via Gcc writes: > Eli Schwartz writes: > >> This discussion thread is about having very good technical reasons -- as >> explained multiple times, including instances where you agreed that the >> technical reasons were good. >> >> Furthermore, even despite those technical reasons, GCC is *

Re: More C type errors by default for GCC 14

Po Lu via Gcc writes: > Eli Schwartz writes: > >> This discussion thread is about having very good technical reasons -- as >> explained multiple times, including instances where you agreed that the >> technical reasons were good. >> >> Furthermore, even despite those technical reasons, GCC is *

Re: More C type errors by default for GCC 14

On Thu, May 11, 2023 at 10:39 PM Po Lu via Gcc wrote: > > Eli Schwartz writes: > > > This discussion thread is about having very good technical reasons -- as > > explained multiple times, including instances where you agreed that the > > technical reasons were good. > > > > Furthermore, even desp

Re: More C type errors by default for GCC 14

Po Lu writes: > Sam James writes: > >> And I would not want to see that happen either, nor do I think Florian >> would, or many of the other participants in this thread. >> >> Indeed, for some projects, where it's hopeless^Wlots of work, >> we're using -std=c89 or -std=gnu89 as appropriate - as

Re: More C type errors by default for GCC 14

Sam James writes: > And I would not want to see that happen either, nor do I think Florian > would, or many of the other participants in this thread. > > Indeed, for some projects, where it's hopeless^Wlots of work, > we're using -std=c89 or -std=gnu89 as appropriate - as already stated. > > But

Re: More C type errors by default for GCC 14

Eli Schwartz writes: > Except this thread is not arguing to remove support for -std=c89 as far > as I can tell? > > The argument is that on newer values for -std (such as the one GCC > defaults to if no -std is specified), GCC should adapt its diagnostics > better for the std in question. These n

Re: More C type errors by default for GCC 14

Eli Schwartz writes: > This discussion thread is about having very good technical reasons -- as > explained multiple times, including instances where you agreed that the > technical reasons were good. > > Furthermore, even despite those technical reasons, GCC is *still* > committed to not breakin

Re: More C type errors by default for GCC 14

Arsen Arsenović writes: > Indeed they should be - but warning vs. error holds significance. A > beginner is much less likely to be writing clever code that allegedly > uses these features properly than to be building new code, and simply > having made an error that they do not want and will suff

Re: More C type errors by default for GCC 14

Eli Schwartz writes: > I expect no such thing, but I do expect that people making decisions in > the real world acknowledge that ***they*** (and no one else) made those > decisions of their own volition. > > I am unsure what "decisions made in the real world" has to do with my > observation that

Re: More C type errors by default for GCC 14

Arsen Arsenović writes: > Seems that the algorithm and I agree. I don't see any use in the int() > guess that the compiler does, besides accepting old code (which makes it > candidate for -fpermissive). I believe: extern int foo (); covers at least 50% of all C functions, since they are gen

Re: More C type errors by default for GCC 14

On 5/11/23 2:24 AM, Eli Zaretskii wrote: > Please be serious, and please don't mock your opponents. This is a > serious discussion of a serious subject, not a Twitter post. I responded with precisely the degree of seriousness as the statement I responded to. For the record, I believe both state

Re: More C type errors by default for GCC 14

On 5/11/23 2:18 AM, Po Lu wrote: > Eli Schwartz writes: >> 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. A

Re: More C type errors by default for GCC 14

Eli Schwartz via Gcc writes: > On 5/11/23 2:12 AM, Eli Zaretskii wrote: >>> 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

Re: More C type errors by default for GCC 14

On 5/11/23 2:12 AM, Eli Zaretskii wrote: >> 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

Re: More C type errors by default for GCC 14

Hi Florian, On Tue, May 09, 2023 at 08:22:44PM +0200, Florian Weimer via Gcc wrote: > * alleged code generation bugs because the upper 32 bits of a pointer > are set to zero or 0x, resulting in crashes. This can happen > if GCC synthesizes an implicit int declaration for a pointer-ret

Re: More C type errors by default for GCC 14

Eli Zaretskii writes: >> Cc: Jonathan Wakely , gcc@gcc.gnu.org >> Date: Thu, 11 May 2023 10:44:47 +0200 >> From: Arsen Arsenović via Gcc >> >> the current default of accepting this code in C is harmful to those >> who are writing new code, or are learning C. > > People who learn C should be ad

  1   2   3   >