[RFC] -Weverything

[RFC] -Weverything

[Thomas Koenig]

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

Re: [RFC] -Weverything

[Marc Glisse]

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

Re: [RFC] -Weverything

[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.

Re: [RFC] -Weverything

[Jonathan Wakely]

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

Re: [RFC] -Weverything

[Jeffrey Walton]

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

Re: [RFC] -Weverything

[Martin Sebor]

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

Re: [RFC] -Weverything

[Thomas König]

> 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 😉

Re: [RFC] -Weverything

[Jakub Jelinek]

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

Re: [RFC] -Weverything

[Marc Glisse]

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

Re: [RFC] -Weverything

[Jonathan Wakely]

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.

Re: [RFC] -Weverything

[Franz Sirl]

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

Re: [RFC] -Weverything

[Jonathan Wakely]

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 ;-)

Re: [RFC] -Weverything

[Thomas König]

> 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.

Re: [RFC] -Weverything

[Paul Richard Thomas]

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

Re: [RFC] -Weverything

[N.M. Maclaren]

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.

Re: [RFC] -Weverything

[Jonathan Wakely]

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.

Re: [RFC] -Weverything

[Steve Kargl]

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

Re: [RFC] -Weverything

[Thomas König]

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

Re: [RFC] -Weverything

[Andrew Pinski]

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

Re: [RFC] -Weverything

[Steve Kargl]

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

Re: [RFC] -Weverything

[N.M. Maclaren]

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.

Re: [RFC] -Weverything

[Segher Boessenkool]

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