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
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
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
> 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:
> 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: 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
> 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
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
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
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:
> 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
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
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
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'?
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:
> 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
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
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:
> 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
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:
> 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
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
"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
>>
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
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?
>
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
> 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
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
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: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
> 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, 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
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
> 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, 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
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
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 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
> 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
> 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
> 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
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
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: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
> 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
> 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
> 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
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 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
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
> 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 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.
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/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:
> 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
> 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
* 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
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
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
> 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
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
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
> 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
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
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
> 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
> 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
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
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
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
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
* 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
> 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
> 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
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: 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 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: 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, 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
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
> 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
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
> 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
> 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
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
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 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, 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
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 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
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 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
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 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
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, 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
97 matches
Mail list logo