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() {
> 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 motivate software packages to fix
> From: Florian Weimer
> Cc: Jakub Jelinek , Eli Zaretskii ,
> jwakely@gmail.com, ar...@aarsen.me
> Date: Tue, 09 May 2023 22:57:20 +0200
>
> * Eli Zaretskii via Gcc:
>
> >> Date: Tue, 9 May 2023 21:07:07 +0200
> >> From: Jakub Jelinek
> >> Cc: Jonathan Wakely , ar...@aarsen.me,
> >>
On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
> We are currently using gcc 12 and specifying C11. To experiment with
> these stricter warnings and slowly address them, would we need to build
> with a newer C version?
No, the proposed changes are to give errors (instead of warnings) for
rules
On Tue, May 9, 2023 at 5:28 PM David Edelsohn via Gcc
wrote:
> On Tue, May 9, 2023 at 4:40 PM Jonathan Wakely
> wrote:
>
> >
> >
> > On Tue, 9 May 2023, 21:13 David Edelsohn, wrote:
> >
> >> On Tue, May 9, 2023 at 3:22 PM Eli Zaretskii via Gcc
> >> wrote:
> >>
> >>> > Date: Tue, 9 May 2023
On Tue, May 9, 2023 at 4:40 PM Jonathan Wakely
wrote:
>
>
> On Tue, 9 May 2023, 21:13 David Edelsohn, 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,
Thomas Koenig via Gcc writes:
> Not replying to anybody in particular, just a bit of history, with
> some potential parallels.
>
> In gfortran, we have had two major issues with interfaces. One was that
> code which had happily violated the compiler ABI started failing, due
> to a fix in the
Not replying to anybody in particular, just a bit of history, with
some potential parallels.
In gfortran, we have had two major issues with interfaces. One was that
code which had happily violated the compiler ABI started failing, due
to a fix in the gfortran front end which meant that we were
* Eli Zaretskii via Gcc:
>> Date: Tue, 9 May 2023 21:07:07 +0200
>> From: Jakub Jelinek
>> Cc: Jonathan Wakely , ar...@aarsen.me, gcc@gcc.gnu.org
>>
>> On Tue, May 09, 2023 at 10:04:06PM +0300, Eli Zaretskii via Gcc wrote:
>> > People who ignore warnings will use options that disable these new
On Tue, 9 May 2023, 21:13 David Edelsohn, 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
David Edelsohn writes:
> This seems to be the core tension. If developers cared about these issues,
> they would enable appropriate warnings and -Werror.
These issues are easy to miss and overlook. Making them louder helps
prevent that.
Additionally, requiring the users to remember a dozen
Eli Zaretskii writes:
>> Cc: Jonathan Wakely , gcc@gcc.gnu.org
>> Date: Tue, 09 May 2023 18:38:05 +0200
>> From: Arsen Arsenović via Gcc
>>
>> You're actively dismissing the benefit.
>
> Which benefit?
>
> No one has yet explained why a warning about this is not enough, and
> why it must be
On Tue, May 9, 2023 at 3:22 PM Eli Zaretskii via Gcc
wrote:
> > Date: Tue, 9 May 2023 21:07:07 +0200
> > From: Jakub Jelinek
> > Cc: Jonathan Wakely , ar...@aarsen.me,
> gcc@gcc.gnu.org
> >
> > On Tue, May 09, 2023 at 10:04:06PM +0300, Eli Zaretskii via Gcc wrote:
> > > > From: Jonathan Wakely
> Date: Tue, 9 May 2023 21:07:07 +0200
> From: Jakub Jelinek
> Cc: Jonathan Wakely , ar...@aarsen.me, gcc@gcc.gnu.org
>
> On Tue, May 09, 2023 at 10:04:06PM +0300, Eli Zaretskii via Gcc wrote:
> > > From: Jonathan Wakely
> > > Date: Tue, 9 May 2023 18:15:59 +0100
> > > Cc: Arsen Arsenović ,
On Tue, May 09, 2023 at 10:04:06PM +0300, Eli Zaretskii via Gcc wrote:
> > From: Jonathan Wakely
> > Date: Tue, 9 May 2023 18:15:59 +0100
> > Cc: Arsen Arsenović , gcc@gcc.gnu.org
> >
> > On Tue, 9 May 2023 at 17:56, Eli Zaretskii wrote:
> > >
> > > No one has yet explained why a warning about
> From: Jonathan Wakely
> Date: Tue, 9 May 2023 18:15:59 +0100
> Cc: Arsen Arsenović , gcc@gcc.gnu.org
>
> On Tue, 9 May 2023 at 17:56, Eli Zaretskii wrote:
> >
> > No one has yet explained why a warning about this is not enough, and
> > why it must be made an error. Florian's initial post
> From: Sam James
> Cc: Arsen Arsenović , d...@killthe.net,
> jwakely@gmail.com, gcc@gcc.gnu.org
> Date: Tue, 09 May 2023 18:05:09 +0100
>
> Eli Zaretskii via Gcc writes:
>
> >> Cc: Jonathan Wakely , gcc@gcc.gnu.org
> >> Date: Tue, 09 May 2023 18:38:05 +0200
> >> From: Arsen Arsenović via
* David Edelsohn:
> Yes, GCC has two, distinct user groups / use cases, but GCC also has a
> very unique and crucial role, as the foundation for a large portion of
> the GNU/Linux and FOSS software ecosystem. This proposal is missing a
> motivation for this change, especially making new errors
* Sam James:
> Florian Weimer writes:
>
>> * Richard Biener:
>>
Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc :
TL;DR: This message is about turning implicit-int,
implicit-function-declaration, and possibly int-conversion into errors
for GCC 14.
>>>
>>> I
Jason Merrill writes:
> On Tue, May 9, 2023 at 12:45 PM Florian Weimer via Gcc
> wrote:
>>
>> * Richard Biener:
>>
>> > > Am 09.05.2023 um 18:13 schrieb David Edelsohn :
>> > >
>> > > On Tue, May 9, 2023 at 12:07 PM Jakub Jelinek via Gcc
>> > > wrote:
>> > >
>> > > On Tue, May 09, 2023 at
On Tue, 9 May 2023 at 17:56, Eli Zaretskii wrote:
>
> > Cc: Jonathan Wakely , gcc@gcc.gnu.org
> > Date: Tue, 09 May 2023 18:38:05 +0200
> > From: Arsen Arsenović via Gcc
> >
> > You're actively dismissing the benefit.
>
> Which benefit?
>
> No one has yet explained why a warning about this is not
Florian Weimer writes:
> * Richard Biener:
>
>>> Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc :
>>>
>>> TL;DR: This message is about turning implicit-int,
>>> implicit-function-declaration, and possibly int-conversion into errors
>>> for GCC 14.
>>
>> I suppose the goal is to not
On Tue, May 9, 2023 at 12:45 PM Florian Weimer via Gcc wrote:
>
> * Richard Biener:
>
> > > Am 09.05.2023 um 18:13 schrieb David Edelsohn :
> > >
> > > On Tue, May 9, 2023 at 12:07 PM Jakub Jelinek via Gcc
> > > wrote:
> > >
> > > On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via
Eli Zaretskii via Gcc writes:
>> Cc: Jonathan Wakely , gcc@gcc.gnu.org
>> Date: Tue, 09 May 2023 18:38:05 +0200
>> From: Arsen Arsenović via Gcc
>>
>> You're actively dismissing the benefit.
>
> Which benefit?
>
> No one has yet explained why a warning about this is not enough, and
> why it
* Richard Biener:
>> Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc :
>>
>> TL;DR: This message is about turning implicit-int,
>> implicit-function-declaration, and possibly int-conversion into errors
>> for GCC 14.
>
> I suppose the goal is to not need to rely on altering CFLAGS but
>
On Tue, May 9, 2023 at 9:45 AM Florian Weimer via Gcc wrote:
>
> The part David quoted above is about this:
>
> $ gcc -fno-gnu89-inline -std=gnu89 t.c
> cc1: error: ‘-fno-gnu89-inline’ is only supported in GNU99 or C99 mode
>
> And some packages need -fno-gnu89-inline, but also rely on implicit
> Cc: Jonathan Wakely , gcc@gcc.gnu.org
> Date: Tue, 09 May 2023 18:38:05 +0200
> From: Arsen Arsenović via Gcc
>
> You're actively dismissing the benefit.
Which benefit?
No one has yet explained why a warning about this is not enough, and
why it must be made an error. Florian's initial post
* Richard Biener:
> > Am 09.05.2023 um 18:13 schrieb David Edelsohn :
> >
> > On Tue, May 9, 2023 at 12:07 PM Jakub Jelinek via Gcc
> > wrote:
> >
> > On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote:
> > >
> > >
> > > > Am 09.05.2023 um 14:16 schrieb Florian Weimer via
Dave Blanchard writes:
> On Tue, 9 May 2023 16:14:28 +0100
> Jonathan Wakely via Gcc wrote:
>
>> This isn't "be like Clang", this is "diagnose things that have been
>> invalid C since 1999".
>
> And in the process, break half of my system, and make it even more of a pain
> in
> the ass to
Dave Blanchard writes:
> On Tue, 09 May 2023 16:07:50 +0100
> Sam James via Gcc wrote:
>
>> Florian did note this already - ABI. Implicit function declarations are
>> pretty horrible in a number of cases:
>> - they prevent fortification (_FORTIFY_SOURCE)
>
> So what? Print a warning, for those
On Tue, May 9, 2023 at 12:07 PM Jakub Jelinek via Gcc
wrote:
> On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote:
> >
> >
> > > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc >:
> > >
> > > TL;DR: This message is about turning implicit-int,
> > >
Jakub Jelinek writes:
> On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote:
>>
>>
>> > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc :
>> >
>> > TL;DR: This message is about turning implicit-int,
>> > implicit-function-declaration, and possibly int-conversion
On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote:
>
>
> > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc :
> >
> > TL;DR: This message is about turning implicit-int,
> > implicit-function-declaration, and possibly int-conversion into errors
> > for GCC 14.
>
> I
Talking about dropping anybody out of a helicopter is not acceptable
on this mailing list. Stop it.
Learn to engage rationally or leave.
On Tue, 09 May 2023 16:07:50 +0100
Sam James via Gcc wrote:
> Florian did note this already - ABI. Implicit function declarations are
> pretty horrible in a number of cases:
> - they prevent fortification (_FORTIFY_SOURCE)
So what? Print a warning, for those who are writing new code or
On Tue, May 9, 2023 at 11:14 AM Jonathan Wakely
wrote:
> On Tue, 9 May 2023 at 16:04, David Edelsohn via Gcc
> wrote:
> > Yes, GCC has two, distinct user groups / use cases, but GCC also has a
> very
> > unique and crucial role, as the foundation for a large portion of the
> > GNU/Linux and
On Tue, 9 May 2023 16:14:28 +0100
Jonathan Wakely via Gcc wrote:
> This isn't "be like Clang", this is "diagnose things that have been
> invalid C since 1999".
And in the process, break half of my system, and make it even more of a pain in
the ass to compile old software. With no real gain or
> Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc :
>
> TL;DR: This message is about turning implicit-int,
> implicit-function-declaration, and possibly int-conversion into errors
> for GCC 14.
I suppose the goal is to not need to rely on altering CFLAGS but change the
default
On Tue, 9 May 2023 at 16:04, David Edelsohn via Gcc wrote:
> Yes, GCC has two, distinct user groups / use cases, but GCC also has a very
> unique and crucial role, as the foundation for a large portion of the
> GNU/Linux and FOSS software ecosystem. This proposal is missing a
> motivation for
David Edelsohn via Gcc writes:
> On Tue, May 9, 2023 at 8:16 AM 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.
>>
>> A few of you might remember that I've been
On Tue, May 9, 2023 at 8:16 AM 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.
>
> A few of you might remember that I've been looking into turning some
> type errors from
How about this as a suitable compromise:
Just introduce a new compiler option, maybe something like
-Wjesus-christ-I-am-really-fucking-anal-and-definitely-want-EVERYTHING-TO-BE-AN-ERROR.
That way all of the weirdos who want 90% of their system build to fail with
ridiculously pedantic errors
TL;DR: This message is about turning implicit-int,
implicit-function-declaration, and possibly int-conversion into errors
for GCC 14.
A few of you might remember that I've been looking into turning some
type errors from warnings into errors by default. Mainly I've been
looking at implicit
201 - 243 of 243 matches
Mail list logo
