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("4
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:
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 cas
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 erro
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
rem
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 th
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
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
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
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
> > >
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 an
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 wro
> 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 r
> 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
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 t
> 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 a
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 (de
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 he
> 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 stagger
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 t
> 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
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,
> >
> 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 aroun
> 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 c
* 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
>> > produ
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 T
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
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
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 mas
> 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
> 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
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 c
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 functionalit
> 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
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 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. Her
> 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
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 t
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 a
* 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 F
> 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 acce
> 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
ch
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:
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
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.
> 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
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 p
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-convers
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, i
> 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
> 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
> 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 Fort
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
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-in
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 ar
> 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 fe
> 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 pro
> 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 j
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
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'
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 iss
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
> 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
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
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://gc
> 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 coul
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 unco
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
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 t
> 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 wi
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
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?
>
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
"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
>>
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 anyw
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 whi
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 whi
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 increasin
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. A
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 compat
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 i
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 w
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
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'?
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
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
> 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
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:
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 prop
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, afte
> 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
> > > wi
> 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
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 ju
> 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 remove
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 que
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 histrio
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 th
97 matches
Mail list logo
