* [RFC] -Weverything
@ 2019-01-22 18:34 Thomas Koenig
2019-01-22 18:45 ` Marc Glisse
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Thomas Koenig @ 2019-01-22 18:34 UTC (permalink / raw)
To: gcc mailing list, fortran
Hi,
What would people think about a -Weverything option which turns on
every warning there is?
I think that could be quite useful in some circumstances, especially
to find potential bugs with warnings that people, for some reason
or other, found too noisy for -Wextra.
The name could be something else, of course. In the best GNU tradition,
-Wkitchen-sink could be another option :-)
Regards
Thomas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-22 18:34 [RFC] -Weverything Thomas Koenig
@ 2019-01-22 18:45 ` Marc Glisse
2019-01-22 18:56 ` Jonathan Wakely
2019-01-22 20:53 ` Jeffrey Walton
2019-01-23 0:53 ` Martin Sebor
2 siblings, 1 reply; 22+ messages in thread
From: Marc Glisse @ 2019-01-22 18:45 UTC (permalink / raw)
To: Thomas Koenig; +Cc: gcc mailing list, fortran
On Tue, 22 Jan 2019, Thomas Koenig wrote:
> Hi,
>
> What would people think about a -Weverything option which turns on
> every warning there is?
>
> I think that could be quite useful in some circumstances, especially
> to find potential bugs with warnings that people, for some reason
> or other, found too noisy for -Wextra.
>
> The name could be something else, of course. In the best GNU tradition,
> -Wkitchen-sink could be another option :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573 and duplicates already
list quite a few arguments. Basically, it could be useful for debugging
gcc or to discover warnings, but gcc devs fear that users will actually
use it for real.
--
Marc Glisse
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-22 18:45 ` Marc Glisse
@ 2019-01-22 18:56 ` Jonathan Wakely
2019-01-22 19:00 ` Jonathan Wakely
2019-01-23 11:21 ` Franz Sirl
0 siblings, 2 replies; 22+ messages in thread
From: Jonathan Wakely @ 2019-01-22 18:56 UTC (permalink / raw)
To: gcc; +Cc: Thomas Koenig, fortran
On Tue, 22 Jan 2019 at 18:46, Marc Glisse <marc.glisse@inria.fr> wrote:
>
> On Tue, 22 Jan 2019, Thomas Koenig wrote:
>
> > Hi,
> >
> > What would people think about a -Weverything option which turns on
> > every warning there is?
> >
> > I think that could be quite useful in some circumstances, especially
> > to find potential bugs with warnings that people, for some reason
> > or other, found too noisy for -Wextra.
> >
> > The name could be something else, of course. In the best GNU tradition,
> > -Wkitchen-sink could be another option :-)
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573 and duplicates already
> list quite a few arguments. Basically, it could be useful for debugging
> gcc or to discover warnings, but gcc devs fear that users will actually
> use it for real.
Every LLVM dev I've spoken to thinks their -Weverything was a mistake
and hates it. It was meant to be for option discovery by automated
tools, but users started using it.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-22 18:56 ` Jonathan Wakely
@ 2019-01-22 19:00 ` Jonathan Wakely
2019-01-23 11:21 ` Franz Sirl
1 sibling, 0 replies; 22+ messages in thread
From: Jonathan Wakely @ 2019-01-22 19:00 UTC (permalink / raw)
To: gcc; +Cc: Thomas Koenig, fortran
On Tue, 22 Jan 2019 at 18:56, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Tue, 22 Jan 2019 at 18:46, Marc Glisse <marc.glisse@inria.fr> wrote:
> >
> > On Tue, 22 Jan 2019, Thomas Koenig wrote:
> >
> > > Hi,
> > >
> > > What would people think about a -Weverything option which turns on
> > > every warning there is?
> > >
> > > I think that could be quite useful in some circumstances, especially
> > > to find potential bugs with warnings that people, for some reason
> > > or other, found too noisy for -Wextra.
> > >
> > > The name could be something else, of course. In the best GNU tradition,
> > > -Wkitchen-sink could be another option :-)
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573 and duplicates already
> > list quite a few arguments. Basically, it could be useful for debugging
> > gcc or to discover warnings, but gcc devs fear that users will actually
> > use it for real.
>
> Every LLVM dev I've spoken to thinks their -Weverything was a mistake
> and hates it. It was meant to be for option discovery by automated
> tools, but users started using it.
My other arguments against it: https://stackoverflow.com/a/11720263/981959
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-22 18:34 [RFC] -Weverything Thomas Koenig
2019-01-22 18:45 ` Marc Glisse
@ 2019-01-22 20:53 ` Jeffrey Walton
2019-01-23 0:53 ` Martin Sebor
2 siblings, 0 replies; 22+ messages in thread
From: Jeffrey Walton @ 2019-01-22 20:53 UTC (permalink / raw)
To: Thomas Koenig; +Cc: gcc mailing list, fortran
On Tue, Jan 22, 2019 at 1:35 PM Thomas Koenig <tkoenig@netcologne.de> wrote:
>
> What would people think about a -Weverything option which turns on
> every warning there is?
I tried to use -Weverything on a C++ project with about 350 source
files. It was a failed experiment. It created too much noise to be
useful.
Your mileage may vary.
Jeff
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-22 18:34 [RFC] -Weverything Thomas Koenig
2019-01-22 18:45 ` Marc Glisse
2019-01-22 20:53 ` Jeffrey Walton
@ 2019-01-23 0:53 ` Martin Sebor
2019-01-23 7:17 ` Thomas König
2 siblings, 1 reply; 22+ messages in thread
From: Martin Sebor @ 2019-01-23 0:53 UTC (permalink / raw)
To: Thomas Koenig, gcc mailing list, fortran
On 1/22/19 11:34 AM, Thomas Koenig wrote:
> Hi,
>
> What would people think about a -Weverything option which turns on
> every warning there is?
>
> I think that could be quite useful in some circumstances, especially
> to find potential bugs with warnings that people, for some reason
> or other, found too noisy for -Wextra.
>
> The name could be something else, of course. In the best GNU tradition,
> -Wkitchen-sink could be another option :-)
I often wish GCC supported it -- not in the hopes of finding every
conceivable bug or transgression against known coding styles but
as a tool to discover warnings that have to be explicitly enabled
either by using their own options or by specifying a higher level
than the default.
I agree that using -Weverything on real code would lead to far too
too much noise to be practical, but I think the concern that it would
cause frustration and lead to complaints and bug reports could be
mitigated by documenting the option's purpose or even by issuing
a warning for using it.
Martin
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-23 0:53 ` Martin Sebor
@ 2019-01-23 7:17 ` Thomas König
2019-01-23 7:31 ` Jakub Jelinek
2019-01-23 9:31 ` Jonathan Wakely
0 siblings, 2 replies; 22+ messages in thread
From: Thomas König @ 2019-01-23 7:17 UTC (permalink / raw)
To: Martin Sebor; +Cc: Thomas Koenig, gcc mailing list, fortran
> Am 23.01.2019 um 01:53 schrieb Martin Sebor <msebor@gmail.com>:
> I often wish GCC supported it -- not in the hopes of finding every
> conceivable bug or transgression against known coding styles but
> as a tool to discover warnings that have to be explicitly enabled
> either by using their own options or by specifying a higher level
> than the default.
So, maybe an option to list every warning would be better?
I am sure the number of people doing
gcc `gcc —list-warnings=all`
and complaining about the result be small 😉
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-23 7:17 ` Thomas König
@ 2019-01-23 7:31 ` Jakub Jelinek
2019-01-23 8:26 ` Marc Glisse
2019-01-23 9:31 ` Jonathan Wakely
1 sibling, 1 reply; 22+ messages in thread
From: Jakub Jelinek @ 2019-01-23 7:31 UTC (permalink / raw)
To: Thomas König; +Cc: Martin Sebor, Thomas Koenig, gcc mailing list, fortran
On Wed, Jan 23, 2019 at 08:17:00AM +0100, Thomas König wrote:
>
>
> > Am 23.01.2019 um 01:53 schrieb Martin Sebor <msebor@gmail.com>:
>
> > I often wish GCC supported it -- not in the hopes of finding every
> > conceivable bug or transgression against known coding styles but
> > as a tool to discover warnings that have to be explicitly enabled
> > either by using their own options or by specifying a higher level
> > than the default.
>
> So, maybe an option to list every warning would be better?
>
> I am sure the number of people doing
>
> gcc `gcc âlist-warnings=all`
>
> and complaining about the result be small ð
We have that, gcc -Q --help=warning
Of course, for warnings which do require arguments (numerical, or
enumeration/string), one still needs to pick up his choices of those
arguments; no idea what -Weverything would do here, while some warnings
have different levels where a higher (or lower) level is a superset of
another level, what numbers would you pick for e.g. warnings where the
argument is bytes?
And, I agree -Weverything is a terrible idea.
Jakub
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-23 7:31 ` Jakub Jelinek
@ 2019-01-23 8:26 ` Marc Glisse
0 siblings, 0 replies; 22+ messages in thread
From: Marc Glisse @ 2019-01-23 8:26 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Thomas König, Martin Sebor, Thomas Koenig, gcc mailing list,
fortran
On Wed, 23 Jan 2019, Jakub Jelinek wrote:
> We have that, gcc -Q --help=warning
> Of course, for warnings which do require arguments (numerical, or
> enumeration/string), one still needs to pick up his choices of those
> arguments; no idea what -Weverything would do here, while some warnings
> have different levels where a higher (or lower) level is a superset of
> another level, what numbers would you pick for e.g. warnings where the
> argument is bytes?
For most of them, there is a value that maximizes the number of warnings,
so the same superset argument applies. -Wframe-larger-than=0 so it shows
the estimated frame size on every function, -Walloca-larger-than=0 so it
is equivalent to -Walloca, etc.
--
Marc Glisse
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-23 7:17 ` Thomas König
2019-01-23 7:31 ` Jakub Jelinek
@ 2019-01-23 9:31 ` Jonathan Wakely
1 sibling, 0 replies; 22+ messages in thread
From: Jonathan Wakely @ 2019-01-23 9:31 UTC (permalink / raw)
To: Thomas König; +Cc: Martin Sebor, Thomas Koenig, gcc mailing list, fortran
On Wed, 23 Jan 2019 at 07:17, Thomas König <tk@tkoenig.net> wrote:
>
>
> > Am 23.01.2019 um 01:53 schrieb Martin Sebor <msebor@gmail.com>:
>
> > I often wish GCC supported it -- not in the hopes of finding every
> > conceivable bug or transgression against known coding styles but
> > as a tool to discover warnings that have to be explicitly enabled
> > either by using their own options or by specifying a higher level
> > than the default.
>
> So, maybe an option to list every warning would be better?
>
>
Yes, if the idea is to add something to help debug GCC itself, or help GCC
devs, please don't spell it -Wxxx so it doesn't look like something that
users should care about.
As someone doing lots of support via gcc-help, #gcc@freenode, stackoverflow
and elsewhere, I really don't want to have to keep explaining that
-Weverything was not meant to be used on user code.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-22 18:56 ` Jonathan Wakely
2019-01-22 19:00 ` Jonathan Wakely
@ 2019-01-23 11:21 ` Franz Sirl
2019-01-23 11:37 ` Jonathan Wakely
1 sibling, 1 reply; 22+ messages in thread
From: Franz Sirl @ 2019-01-23 11:21 UTC (permalink / raw)
To: Jonathan Wakely, gcc; +Cc: Thomas Koenig, fortran
Am 2019-01-22 um 19:56 schrieb Jonathan Wakely:
> On Tue, 22 Jan 2019 at 18:46, Marc Glisse <marc.glisse@inria.fr> wrote:
>>
>> On Tue, 22 Jan 2019, Thomas Koenig wrote:
>>
>>> Hi,
>>>
>>> What would people think about a -Weverything option which turns on
>>> every warning there is?
>>>
>>> I think that could be quite useful in some circumstances, especially
>>> to find potential bugs with warnings that people, for some reason
>>> or other, found too noisy for -Wextra.
>>>
>>> The name could be something else, of course. In the best GNU tradition,
>>> -Wkitchen-sink could be another option :-)
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31573 and duplicates already
>> list quite a few arguments. Basically, it could be useful for debugging
>> gcc or to discover warnings, but gcc devs fear that users will actually
>> use it for real.
>
> Every LLVM dev I've spoken to thinks their -Weverything was a mistake
> and hates it. It was meant to be for option discovery by automated
> tools, but users started using it.
>
The LLVM devs may hate it, but as maintainer of a multi-platform
multi-compiler automated build framework I _love_ -Weverything. It's
much easier to handle a compiler upgrade this way without missing any
new warnings not enabled by -Wall -Wextra. When a new warning shows up
due to the changed compiler I can immediately decide if I want to
disable it, leave it as a warning or turn it into an error. Longterm
maintenance of a -Wno-* list is also a lot less error prone than a
positive -W* list in my experience.
Franz
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-23 11:21 ` Franz Sirl
@ 2019-01-23 11:37 ` Jonathan Wakely
2019-01-23 13:26 ` Thomas König
0 siblings, 1 reply; 22+ messages in thread
From: Jonathan Wakely @ 2019-01-23 11:37 UTC (permalink / raw)
To: Franz Sirl; +Cc: gcc, Thomas Koenig, fortran
On Wed, 23 Jan 2019 at 11:21, Franz Sirl wrote:
> The LLVM devs may hate it, but as maintainer of a multi-platform
> multi-compiler automated build framework I _love_ -Weverything. It's
> much easier to handle a compiler upgrade this way without missing any
> new warnings not enabled by -Wall -Wextra.
When there are new warnings that aren't enabled by -Wall -Wextra,
there's probably a reason they aren't enabled by default.
"Gotta catch 'em all" is for Pokemon, not compiler warnings ;-)
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-23 11:37 ` Jonathan Wakely
@ 2019-01-23 13:26 ` Thomas König
2019-01-23 13:53 ` Paul Richard Thomas
2019-01-27 13:56 ` N.M. Maclaren
0 siblings, 2 replies; 22+ messages in thread
From: Thomas König @ 2019-01-23 13:26 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: Franz Sirl, gcc, Thomas Koenig, fortran
> Am 23.01.2019 um 12:36 schrieb Jonathan Wakely <jwakely.gcc@gmail.com>:
>
> When there are new warnings that aren't enabled by -Wall -Wextra,
> there's probably a reason they aren't enabled by default.
-Wconversion-extra is an example of such a warning.
It catches a very common error people make in Fortran, see https://gcc.gnu.org/ml/fortran/2019-01/msg00178.html for a false bug report which it would have caught early.
We left it out of -Wextra because people felt it was too noisy.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-23 13:26 ` Thomas König
@ 2019-01-23 13:53 ` Paul Richard Thomas
2019-01-27 13:56 ` N.M. Maclaren
1 sibling, 0 replies; 22+ messages in thread
From: Paul Richard Thomas @ 2019-01-23 13:53 UTC (permalink / raw)
To: Thomas König
Cc: Jonathan Wakely, Franz Sirl, gcc, Thomas Koenig, fortran
Hi Thomas,
Thanks for initiating this discussion. The responses are very useful.
That said, wouldn't a -ffix-everything option be more useful? :-)
Cheers
Paul
On Wed, 23 Jan 2019 at 13:27, Thomas König <tk@tkoenig.net> wrote:
>
>
>
> > Am 23.01.2019 um 12:36 schrieb Jonathan Wakely <jwakely.gcc@gmail.com>:
> >
> > When there are new warnings that aren't enabled by -Wall -Wextra,
> > there's probably a reason they aren't enabled by default.
>
> -Wconversion-extra is an example of such a warning.
>
> It catches a very common error people make in Fortran, see https://gcc.gnu.org/ml/fortran/2019-01/msg00178.html for a false bug report which it would have caught early.
>
> We left it out of -Wextra because people felt it was too noisy.
>
>
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-23 13:26 ` Thomas König
2019-01-23 13:53 ` Paul Richard Thomas
@ 2019-01-27 13:56 ` N.M. Maclaren
2019-01-27 20:35 ` Jonathan Wakely
1 sibling, 1 reply; 22+ messages in thread
From: N.M. Maclaren @ 2019-01-27 13:56 UTC (permalink / raw)
To: Thomas König
Cc: Jonathan Wakely, Franz Sirl, gcc, Thomas Koenig, fortran
On Jan 23 2019, Thomas König wrote:
>
>> Am 23.01.2019 um 12:36 schrieb Jonathan Wakely <jwakely.gcc@gmail.com>:
>>
>> When there are new warnings that aren't enabled by -Wall -Wextra,
>> there's probably a reason they aren't enabled by default.
>are a higher form of life than mere Fortran
>-Wconversion-extra is an example of such a warning.
>
> It catches a very common error people make in Fortran, see
> https://gcc.gnu.org/ml/fortran/2019-01/ms are a higher form of life than
> mere sg00178.html for a false bug report which it would have caught
> early.
>
>We left it out of -Wextra because people felt it was too noisy.
A bit like discussions on what warnings a compiler should give :-)
There are a few points that don't seem to have been made, though I may have
missed them, which means that quite a few people would like it.
Despite its older and wider implementation history, Fortran has never
accumulated the incompatibilities, inconsistencies and system-dependent
behaviours that C and C++ have. So the arguments against such a warning
for those don't really apply. Obviously, we wouldn't want warnings that a
construct behaved differently in Fortran 66 or in CDC or DEC Fortran, but I
don't think that there are any.
I don't buy the claim that developer options are unsuitable for mere users.
Those of us who wrote highly portable code (and I assume that people still
do) wanted to know that a construct might misbehave on a bizarre,
unsupported but still used system, which the author had never heard of and
has no access to. While that applies to all languages, the attitude that a
portable program should work on a new system with NO modification,
pre-processing or make configuration is rare in C and C++, but still common
in Fortran.
All experience is that warning about things that the programmer might not
have realised are potentially problematic are very useful. In the cases
where I have had to suppress warnings, most of them have been because the
warning was too crude, not that it wasn't useful. For example, in C/C++,
mixing signed and unsigned when the promoted operand was constant and not
going to change value. Or, in Fortran, converting obviously exact constants
to a higher precision - yes, even that WAS an important warning in the
1960s, but people really should move on a bit!
So I think that there is a strong argument for such an option in gfortran,
irrespective of whether there is for gcc and g++.
Regards,
Nick Maclaren.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-27 13:56 ` N.M. Maclaren
@ 2019-01-27 20:35 ` Jonathan Wakely
2019-01-27 20:52 ` Steve Kargl
0 siblings, 1 reply; 22+ messages in thread
From: Jonathan Wakely @ 2019-01-27 20:35 UTC (permalink / raw)
To: N.M. Maclaren; +Cc: Thomas König, Franz Sirl, gcc, Thomas Koenig, fortran
On Sun, 27 Jan 2019 at 13:56, N.M. Maclaren <nmm1@cam.ac.uk> wrote:
>
> On Jan 23 2019, Thomas König wrote:
> >
> >> Am 23.01.2019 um 12:36 schrieb Jonathan Wakely <jwakely.gcc@gmail.com>:
> >>
> >> When there are new warnings that aren't enabled by -Wall -Wextra,
> >> there's probably a reason they aren't enabled by default.
> >are a higher form of life than mere Fortran
> >-Wconversion-extra is an example of such a warning.
> >
> > It catches a very common error people make in Fortran, see
> > https://gcc.gnu.org/ml/fortran/2019-01/ms are a higher form of life than
> > mere sg00178.html for a false bug report which it would have caught
> > early.
> >
> >We left it out of -Wextra because people felt it was too noisy.
>
> A bit like discussions on what warnings a compiler should give :-)
>
> There are a few points that don't seem to have been made, though I may have
> missed them, which means that quite a few people would like it.
>
> Despite its older and wider implementation history, Fortran has never
> accumulated the incompatibilities, inconsistencies and system-dependent
> behaviours that C and C++ have. So the arguments against such a warning
> for those don't really apply. Obviously, we wouldn't want warnings that a
> construct behaved differently in Fortran 66 or in CDC or DEC Fortran, but I
> don't think that there are any.
>
> I don't buy the claim that developer options are unsuitable for mere users.
> Those of us who wrote highly portable code (and I assume that people still
> do) wanted to know that a construct might misbehave on a bizarre,
> unsupported but still used system, which the author had never heard of and
> has no access to. While that applies to all languages, the attitude that a
> portable program should work on a new system with NO modification,
> pre-processing or make configuration is rare in C and C++, but still common
> in Fortran.
>
> All experience is that warning about things that the programmer might not
> have realised are potentially problematic are very useful. In the cases
> where I have had to suppress warnings, most of them have been because the
> warning was too crude, not that it wasn't useful. For example, in C/C++,
> mixing signed and unsigned when the promoted operand was constant and not
> going to change value. Or, in Fortran, converting obviously exact constants
> to a higher precision - yes, even that WAS an important warning in the
> 1960s, but people really should move on a bit!
>
> So I think that there is a strong argument for such an option in gfortran,
> irrespective of whether there is for gcc and g++.
Then -Wall should enable them for Fortran.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-27 20:35 ` Jonathan Wakely
@ 2019-01-27 20:52 ` Steve Kargl
2019-01-27 21:02 ` Thomas König
0 siblings, 1 reply; 22+ messages in thread
From: Steve Kargl @ 2019-01-27 20:52 UTC (permalink / raw)
To: Jonathan Wakely
Cc: N.M. Maclaren, Thomas König, Franz Sirl, gcc, Thomas Koenig,
fortran
On Sun, Jan 27, 2019 at 08:34:57PM +0000, Jonathan Wakely wrote:
> On Sun, 27 Jan 2019 at 13:56, N.M. Maclaren <nmm1@cam.ac.uk> wrote:
> >
> > So I think that there is a strong argument for such an option in gfortran,
> > irrespective of whether there is for gcc and g++.
>
> Then -Wall should enable them for Fortran.
I will as a Fortran contributor/maintainer oppose inclusion
of additional warnings under -Wall unless there is some
miraculous compelling reason to include them. With my own
Fortran projects, I already need to add "-Wno-maybe-uninitialized
-Wno-conversion -Wno-integer-division" after -Wall, because
options are just too damn noisy.
In fact, I would be in favor of removing -Wall, as it is misnamed,
in favor of -Wlevel=0,1,2,3... -Wlevel=0 default warnings.
-Wlevel=1 is equivalent to -Wall. -Wlevel=2 is -Wall -Wextra
(and maybe -Wsurprising).
--
Steve
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-27 20:52 ` Steve Kargl
@ 2019-01-27 21:02 ` Thomas König
2019-01-27 21:19 ` Andrew Pinski
0 siblings, 1 reply; 22+ messages in thread
From: Thomas König @ 2019-01-27 21:02 UTC (permalink / raw)
To: sgk, Jonathan Wakely
Cc: N.M. Maclaren, Franz Sirl, gcc, Thomas Koenig, fortran
Am 27.01.19 um 21:52 schrieb Steve Kargl:
> In fact, I would be in favor of removing -Wall, as it is misnamed,
> in favor of -Wlevel=0,1,2,3... -Wlevel=0 default warnings.
> -Wlevel=1 is equivalent to -Wall. -Wlevel=2 is -Wall -Wextra
> (and maybe -Wsurprising).
... and -Wlevel=3 could then be -Wkitchen-sink, at least from the
Fortran-only side. :-)
I quite like that idea. I don't think -Wall will be deprecated soon,
but -Wlevel sounds like a good thing to implement.
Regards
Thomas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-27 21:02 ` Thomas König
@ 2019-01-27 21:19 ` Andrew Pinski
2019-01-27 21:28 ` Steve Kargl
2019-01-28 22:53 ` Segher Boessenkool
0 siblings, 2 replies; 22+ messages in thread
From: Andrew Pinski @ 2019-01-27 21:19 UTC (permalink / raw)
To: Thomas König
Cc: Steve Kargl, Jonathan Wakely, N.M. Maclaren, Franz Sirl, gcc,
Thomas Koenig, fortran
On Sun, Jan 27, 2019 at 1:02 PM Thomas König <tk@tkoenig.net> wrote:
>
> Am 27.01.19 um 21:52 schrieb Steve Kargl:
>
> > In fact, I would be in favor of removing -Wall, as it is misnamed,
> > in favor of -Wlevel=0,1,2,3... -Wlevel=0 default warnings.
> > -Wlevel=1 is equivalent to -Wall. -Wlevel=2 is -Wall -Wextra
> > (and maybe -Wsurprising).
>
> ... and -Wlevel=3 could then be -Wkitchen-sink, at least from the
> Fortran-only side. :-)
>
> I quite like that idea. I don't think -Wall will be deprecated soon,
> but -Wlevel sounds like a good thing to implement.
Maybe instead of -Wlevel= why not just -W0, -W1, -W2, -W3; -W would be
-W1 (because -W already exists)? Just like -O :).
Thanks,
Andrew
>
> Regards
>
> Thomas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-27 21:19 ` Andrew Pinski
@ 2019-01-27 21:28 ` Steve Kargl
2019-01-28 9:57 ` N.M. Maclaren
2019-01-28 22:53 ` Segher Boessenkool
1 sibling, 1 reply; 22+ messages in thread
From: Steve Kargl @ 2019-01-27 21:28 UTC (permalink / raw)
To: Andrew Pinski
Cc: Thomas König, Jonathan Wakely, N.M. Maclaren, Franz Sirl,
gcc, Thomas Koenig, fortran
On Sun, Jan 27, 2019 at 01:19:08PM -0800, Andrew Pinski wrote:
> On Sun, Jan 27, 2019 at 1:02 PM Thomas König <tk@tkoenig.net> wrote:
> >
> > Am 27.01.19 um 21:52 schrieb Steve Kargl:
> >
> > > In fact, I would be in favor of removing -Wall, as it is misnamed,
> > > in favor of -Wlevel=0,1,2,3... -Wlevel=0 default warnings.
> > > -Wlevel=1 is equivalent to -Wall. -Wlevel=2 is -Wall -Wextra
> > > (and maybe -Wsurprising).
> >
> > ... and -Wlevel=3 could then be -Wkitchen-sink, at least from the
> > Fortran-only side. :-)
> >
> > I quite like that idea. I don't think -Wall will be deprecated soon,
> > but -Wlevel sounds like a good thing to implement.
>
> Maybe instead of -Wlevel= why not just -W0, -W1, -W2, -W3; -W would be
> -W1 (because -W already exists)? Just like -O :).
>
That would work. With -Wlevel, I'm thinking that -Wlevel=-1 would be
the kitchen-sink. This means one can add new levels for positive
levels if desired: -Wlevel=n+1 = -Wlevel=n -Wnew-opt1 -Wnew-opt2,
etc.
--
Steve
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-27 21:28 ` Steve Kargl
@ 2019-01-28 9:57 ` N.M. Maclaren
0 siblings, 0 replies; 22+ messages in thread
From: N.M. Maclaren @ 2019-01-28 9:57 UTC (permalink / raw)
To: sgk
Cc: Andrew Pinski, Thomas König, Jonathan Wakely, Franz Sirl,
gcc, Thomas Koenig, fortran
On Jan 27 2019, Steve Kargl wrote:
>On Sun, Jan 27, 2019 at 01:19:08PM -0800, Andrew Pinski wrote:
>> On Sun, Jan 27, 2019 at 1:02 PM Thomas König <tk@tkoenig.net> wrote:
>> >
>> > > In fact, I would be in favor of removing -Wall, as it is misnamed,
>> > > in favor of -Wlevel=0,1,2,3... -Wlevel=0 default warnings.
>> > > -Wlevel=1 is equivalent to -Wall. -Wlevel=2 is -Wall -Wextra
>> > > (and maybe -Wsurprising).
>> >
>> > ... and -Wlevel=3 could then be -Wkitchen-sink, at least from the
>> > Fortran-only side. :-)
>> >
>> > I quite like that idea. I don't think -Wall will be deprecated soon,
>> > but -Wlevel sounds like a good thing to implement.
>>
>> Maybe instead of -Wlevel= whyng names for levels seems helpful, but
numbers are more future-proof. not just -W0, -W1, -W2, -W3; -W would be
>> -W1 (because -W already exists)? Just like -O :).
>
>That would work. With -Wlevel, I'm thinking that -Wlevel=-1 would be
>the kitchen-sink. This means one can add new l>
>evels for positive
>levels if desired: -Wlevel=n+1 = -Wlevel=n -Wnew-opt1 -Wnew-opt2,
>etc.
Both good, even excellent, ideas. I would prefer 'max' rather than '-1',
but it is essential that its specification (and comment around the code)
say that it is the supremum, to ng names for levels seems helpful, but
numbers are more future-proof.avoid a repetition of the Wall mistake.
It's rather like optimisation - using names for levels seems helpful, but
numbers are more future-proof.
Regards,
Nick Maclaren.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [RFC] -Weverything
2019-01-27 21:19 ` Andrew Pinski
2019-01-27 21:28 ` Steve Kargl
@ 2019-01-28 22:53 ` Segher Boessenkool
1 sibling, 0 replies; 22+ messages in thread
From: Segher Boessenkool @ 2019-01-28 22:53 UTC (permalink / raw)
To: Andrew Pinski
Cc: Thomas König, Steve Kargl, Jonathan Wakely, N.M. Maclaren,
Franz Sirl, gcc, Thomas Koenig, fortran
On Sun, Jan 27, 2019 at 01:19:08PM -0800, Andrew Pinski wrote:
> On Sun, Jan 27, 2019 at 1:02 PM Thomas König <tk@tkoenig.net> wrote:
> >
> > Am 27.01.19 um 21:52 schrieb Steve Kargl:
> >
> > > In fact, I would be in favor of removing -Wall, as it is misnamed,
> > > in favor of -Wlevel=0,1,2,3... -Wlevel=0 default warnings.
> > > -Wlevel=1 is equivalent to -Wall. -Wlevel=2 is -Wall -Wextra
> > > (and maybe -Wsurprising).
> >
> > ... and -Wlevel=3 could then be -Wkitchen-sink, at least from the
> > Fortran-only side. :-)
> >
> > I quite like that idea. I don't think -Wall will be deprecated soon,
> > but -Wlevel sounds like a good thing to implement.
>
> Maybe instead of -Wlevel= why not just -W0, -W1, -W2, -W3; -W would be
> -W1 (because -W already exists)? Just like -O :).
-Wextra is an alternative spelling for -W, which should be the same as -W1
(if you want to make this similar to -O<n>); and -W0 would mean warnings
off, which already has an option, -w (while -o is something else).
-O and -W cannot be made very similar.
-Wall is not the warnings with low false positive rate, or low hit rate
("noisy"). The criterion (shared with -Wextra) is that it is easy to shut
up the warning by doing a trivial, obvious change to the code. This is
of course highly subjective (not that other considerations like "how useful
is this warning" are any better!)
Segher
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2019-01-28 22:53 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-22 18:34 [RFC] -Weverything Thomas Koenig
2019-01-22 18:45 ` Marc Glisse
2019-01-22 18:56 ` Jonathan Wakely
2019-01-22 19:00 ` Jonathan Wakely
2019-01-23 11:21 ` Franz Sirl
2019-01-23 11:37 ` Jonathan Wakely
2019-01-23 13:26 ` Thomas König
2019-01-23 13:53 ` Paul Richard Thomas
2019-01-27 13:56 ` N.M. Maclaren
2019-01-27 20:35 ` Jonathan Wakely
2019-01-27 20:52 ` Steve Kargl
2019-01-27 21:02 ` Thomas König
2019-01-27 21:19 ` Andrew Pinski
2019-01-27 21:28 ` Steve Kargl
2019-01-28 9:57 ` N.M. Maclaren
2019-01-28 22:53 ` Segher Boessenkool
2019-01-22 20:53 ` Jeffrey Walton
2019-01-23 0:53 ` Martin Sebor
2019-01-23 7:17 ` Thomas König
2019-01-23 7:31 ` Jakub Jelinek
2019-01-23 8:26 ` Marc Glisse
2019-01-23 9:31 ` Jonathan Wakely
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).