[Bug driver/44210] New: Extended warning control: like -Wevery -show-warnings

[Bug driver/44210] New: Extended warning control: like -Wevery -show-warnings

[eric dot estievenart at free dot fr]

As I always wonder if my compiler could help me find more bugs,
and the list of warnings I enable tend to be very long,
and -Wall is not enough for me...

(This bug certainly depends on #44209: "Some warnings are not linked to
diagnostics options")

It would be great to have the following options:
(I really don't care for their names if you have better suggestions;
I focus on the functionality)

-Wevery:  would enable all warnings known to gcc 
================================================
This would allow reducing this (infamous) list:
-W -Wall -Wextra -Wstrict-aliasing=2 -Wfloat-equal -Wundef -Wconversion
-Winline -Wmissing-field-initializers -Wshadow -Wcast-align -Wformat=2
-Wsequence-point -Woverloaded-virtual
(I never know which one is enabled by -W, -Wall, -Wextra...)
to a single -Wevery with a few -Wno-XXXXXX

-show-warnings:  would show the enabled warnings 
================================================
An example usage would be:
$ gcc -c somefile.c -Wall -Werror -Wno-error=reorder -Wno-unused-function
                    ..... -show-warnings
status  name             from
------------------------------------------------
ERROR   address          -Wall -Werror
warn    reorder          -Wall -Werror -Wno-error=reorder
-       unused-function  -Wno-unused-function
-       clobbered        (would be enabled by -Wextra)
...
------------------------------------------------
372 known warnings, 300 shown, 297 as errors  (muted: 72)

If the team is interested, I'll consider providing a patch.


-- 
           Summary: Extended warning control: like -Wevery -show-warnings
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: driver
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: eric dot estievenart at free dot fr
 GCC build triplet: does not apply
  GCC host triplet: does not apply
GCC target triplet: does not apply


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44210

[Bug driver/44210] Extended warning control: like -Wevery -show-warnings

[redi at gcc dot gnu dot org]

------- Comment #1 from redi at gcc dot gnu dot org  2010-05-20 13:31 -------
(In reply to comment #0)
> This would allow reducing this (infamous) list:
> -W -Wall -Wextra -Wstrict-aliasing=2 -Wfloat-equal -Wundef -Wconversion
> -Winline -Wmissing-field-initializers -Wshadow -Wcast-align -Wformat=2
> -Wsequence-point -Woverloaded-virtual
> (I never know which one is enabled by -W, -Wall, -Wextra...)

-W is a synonym for -Wextra, so it is pointless to use both (older versions
won't accept -Wextra, new versions don't need both)

The manual fairly clearly documents what controls what:
http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Warning-Options.html



> 
> -show-warnings:  would show the enabled warnings 
> ================================================
> An example usage would be:
> $ gcc -c somefile.c -Wall -Werror -Wno-error=reorder -Wno-unused-function
>                     ..... -show-warnings
> status  name             from
> ------------------------------------------------
> ERROR   address          -Wall -Werror
> warn    reorder          -Wall -Werror -Wno-error=reorder
> -       unused-function  -Wno-unused-function
> -       clobbered        (would be enabled by -Wextra)
> ...
> ------------------------------------------------
> 372 known warnings, 300 shown, 297 as errors  (muted: 72)
> 
> If the team is interested, I'll consider providing a patch.
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44210

[Bug driver/44210] Extended warning control: like -Wevery -show-warnings

[eric dot estievenart at free dot fr]

------- Comment #2 from eric dot estievenart at free dot fr  2010-05-20 15:06 -------
> -W is a synonym for -Wextra, so it is pointless to use both
This perfectly illustrates the problem; I have already spend hours digging
into the manual, what I attempted was to have as much warnings as possible.

> The manual fairly clearly documents what controls what
I know perfectly. Consider 3-4 platforms, 2-3 versions of gcc, and you
wouldn't want to rely on the manual to have a clear overview of what happens
exactly on your build, with a specific file, with your options !

Cheers


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44210

[Bug other/44210] Extended warning control: like -Wevery -show-warnings

[redi at gcc dot gnu dot org]

------- Comment #3 from redi at gcc dot gnu dot org  2010-05-20 16:14 -------
(In reply to comment #2)
> > -W is a synonym for -Wextra, so it is pointless to use both
> This perfectly illustrates the problem; I have already spend hours digging

Then I have misunderstood the problem. How does this illustrate it?

> into the manual, what I attempted was to have as much warnings as possible.

How does adding the redundant -W help get more warnings if you already have
-Wextra?

> > The manual fairly clearly documents what controls what
> I know perfectly. Consider 3-4 platforms, 2-3 versions of gcc, and you
> wouldn't want to rely on the manual to have a clear overview of what happens
> exactly on your build, with a specific file, with your options !

I don't understand what you mean here.
You said you never know what is enabled by -Wall or -Wextra, I pointed out the
manual explains it.
It is quite rare for a -W option to be moved in or out of the -Wall set, so it
doesn't vary between versions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44210

[Bug other/44210] Extended warning control: like -Wevery -show-warnings

[manu at gcc dot gnu dot org]

------- Comment #4 from manu at gcc dot gnu dot org  2010-05-20 17:04 -------
The manual documents what is enabled by -Wall and -Wextra and all other groups
options. We will accept patches fixing any missing/mistaken entries. You could
also propose some warnings to be moved to Wextra. Getting into Wall is more
difficult because they have to be pretty clear and serious warnings without few
false positives.

See also the option -fdiagnostics-show-option.

It would be extremely useful to go through the manual and:

* Document which warnings are exactly enabled by -pedantic -Wall and -Wextra.
Wall and Wextra should be ok but could be good to double check them.

* Document which warnings are not enabled by default or by one of the above.
Provide a complete list of those warnings.

* With this list at hand, one could suggest to move some warnings to Wextra
or...

* perhaps provide a "Wparanoid" setting that includes all those warnings.
Although some may be too specific to make sense at all except for very specific
situations. That is why the list might be interesting.

* A list of warnings enabled by default would also be interesting. (They are
mentioned in the manual for each warning, but there is no complete list.)

Instead of -show-warnings, I would propose to extend the current
--help=warnings --verbose. However, that would mean documenting within GCC the
relations between the warnings options. That by itself (even without the
output) would be EXTREMELY useful if done properly, that is, by adding the
information to the *.opt files that define the flags. I can provide pointers on
how this could be implemented. A follow-up patch could even fill the details of
the manual from that information automatically!

So, I think yes, we are interested in any of the above, so if you are
interested in providing patches, choose something small to start with (some
small documentation patch to the manual), and ask whatever you want. You may
ask here or write to me directly.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-05-20 17:04:01
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44210

[Bug other/44210] Extended warning control: like -Wevery -show-warnings

[eric dot estievenart at free dot fr]

------- Comment #5 from eric dot estievenart at free dot fr  2010-05-21 18:00 -------
44209
> The manual documents...
> We will accept patches fixing any missing/mistaken entries.
That's not the point !
This manual section could (and should) be generated from the output of
-show-warnings or similar

> You could also propose some warnings to be moved to Wextra/Wall
Neither !

> See also the option -fdiagnostics-show-option.
I know it well, it is always in my cflags.
This is because a specific warning had no diagnostic that I logged
#44209 and consequently this ER.

> It would be extremely useful to go through the manual and...

> perhaps provide a "Wparanoid" setting that includes all those warnings.
That's a better name than Wevery. Wmaniac would be smart too ;-)
But it's not time for voting !

> Instead of -show-warnings, I would propose to extend the current
> --help=warnings --verbose.

--help=warnings has its own purpose, and it is indeed useful,
but it does not show the effects of a given commandline on the whole
set of available warnings (which also depends on the language)

> However, that would mean documenting within GCC the
> relations between the warnings options. That by itself (even without the
> output) would be EXTREMELY useful if done properly, that is, by adding the
> information to the *.opt files that define the flags.

> I can provide pointers on how this could be implemented.
Thank you, I'll certainly need some help on the following points:
- which branch I should start working on (4.4, 4.5, ...) so that
  it has good chances to be accepted, and could be integrated into
  released subversions without too many hassle
- which front-ends I should target beside C/C++
- which files to look at first considering the problem.
- if there are things in the developper docs (or rather
  which are not in the developper docs) which could help me.

For the dev itself, I should be able to handle it.
Honestly I have not yet had a look at the code neither
at the architecture, but I guess I will find a common
module shared by the front-ends, compiler, etc.
I'll see if I can first spot / force compile-time warnings
for the calls to a function like log_warning(...)
if the warning is not linked to a diagnostic,
extend the api, ...

> A follow-up patch could even fill the details of
> the manual from that information automatically!
That's indeed my intent !

> So, I think yes, we are interested in any of the above, so if you are
> interested in providing patches, choose something small to start with (some
> small documentation patch to the manual), and ask whatever you want. You may
> ask here or write to me directly.

Thank you again, but if I start on that, I expect to go to the end,
so patching the manual would be a loss of time since all would be generated
after. I don't have so much time to spend on it, I just expect to do it in
a clean and efficient way.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44210

[Bug other/44210] Extended warning control: like -Wevery -show-warnings

[manu at gcc dot gnu dot org]

------- Comment #6 from manu at gcc dot gnu dot org  2010-05-22 00:32 -------
(In reply to comment #5)
> > I can provide pointers on how this could be implemented.
> Thank you, I'll certainly need some help on the following points:
> - which branch I should start working on (4.4, 4.5, ...) so that
>   it has good chances to be accepted, and could be integrated into
>   released subversions without too many hassle

You should work on current trunk. This is a new feature, so not suitable for
release branches.

> - which front-ends I should target beside C/C++
> - which files to look at first considering the problem.

I think you'll need to start modifying the awk scripts that read the *.opt
files: gcc/opt*.awk

You'll probably need to add a new flag Enables, like:

Wextra
Common Var(extra_warnings) Warning  Enables(Wsomething-else,Wother-one)
Print extra (possibly unwanted) warnings

and make the awk scripts handle it by generating code that can print the
relations.

Other interesting files may be opts.* c-opts.*.

> - if there are things in the developper docs (or rather
>   which are not in the developper docs) which could help me.

It depends what you need to know. I cannot read your mind :-)

> For the dev itself, I should be able to handle it.
> Honestly I have not yet had a look at the code neither
> at the architecture, but I guess I will find a common
> module shared by the front-ends, compiler, etc.
> I'll see if I can first spot / force compile-time warnings
> for the calls to a function like log_warning(...)
> if the warning is not linked to a diagnostic,
> extend the api, ...

I don't understand what you mean by this. 

> Thank you again, but if I start on that, I expect to go to the end,
> so patching the manual would be a loss of time since all would be generated
> after. I don't have so much time to spend on it, I just expect to do it in
> a clean and efficient way.

As you wish. I tend to think that when approaching something unknown and
complex, it is better to start small, but if you think you are capable, just go
ahead. I cannot promise that the result will be accepted (because I don't fully
understand what you want to implement), but the experience may be helpful
anyway for someone else to implement something similar.

Flags like this should be named -fsomething. I don't think that -fshow-warnings
will be accepted because it is ambigous. I still believe that letting -Wall
--help=warnings return the flags enabled by Wall would be more clear (and
easier to implement). There could be also -O3 --help,  it will display the
flags enabled by -O3.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44210