Re: proposal to clean up @node Warning Options in invoke.texi

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Chris Pickett <chris.pickett@mail.mcgill.ca> writes:

| Hi,
| 
| For one reason or another, I have spent a fair amount of time reading
| and getting confused by the warnings documentation.  This applies to
| the optimizations as well, but I thought I would start with the
| warnings. Today I sat down and created a dependency graph for all of
| the options in this node.  I made this at first for my own benefit,
| and then realized that other people might be interested in the
| information.


Thanks for doing this -- I believe it is really useful for users, but
also for "new" implementers exercising in this area, and for old
implementers for reminding the big picture.

| I have attached the graph.  I am asking for one or more people to
| comment on its correctness, and what I consider to be errors, as
| indicated in comments.
| 
| Then I have the following proposal for cleaning up the options node in
| invoke.texi:
| 
| 1.  Create a default section, at the top, and put all options enabled
| by default there.
| 
| 2.  Try to group options so that they are closer to other connected
| nodes in the graph.


One thing that really is useful is that all warning flags are grouped
in one section (further divided in sub-section).  What one could do is
to more cross-refs to other flags (not necessarily warning flags).

| 3.  Get rid of the -Wno-xxx option listings, since it is not always
| the case that -Wxxx is enabled by "default", and this just ends up
| being rather confusing.  Instead, explain in the default section that
| everything there can be disabled with -Wno-xxx.

I assume the -Wno-xxx that are set by default would be moved to the
"default" section?

| 4.  For each option, specify connected options systematically, perhaps
| using the syntax I invented, perhaps using a different and more
| natural (i.e. plain old English) syntax.

I agree; we need more systematic rules to manage this ever-growing web
of warning options.

| 
| 5.  Fix what I have labelled as errors.
| 
| In a dream world where I had infinite time, I would invent a grammar
| for specifying relationships between options and then use that to
| generate number 4 above, and also use it to generate the option
| parsing bits of the front end.
| 
| Cheers,
| Chris
| # A --> B        option A implies option B
| # A --> B C      option A implies options B and C
| # A && B --> C   options A and B together imply C
| 
| # A <-- B        option A is implied by option B.
| # A <-- B || C   option A is implied by either option B or option C
| # A <-- B && C   option A is implied by options B and C together

it would also be useful to have a way to check the resulting redundancy.

| # A ==> B        option A enables option B
| # A ==> B C      option A enables options B and C
| # A <== B        option A requires option B (depends on B)
| 
| default --> -Wimport -Wdiv-by-zero -Wendif-labels -Wattributes -Wmultichar
|             -Wnormalized=nfc -Wdeprecated-declarations -Winvalid-offset-of
|             -Wint-to-pointer-cast -Wpointer-to-int-cast

plus others that are not controlled by named flags.

| 
| -fsyntax-only
| 
| -pedantic --> -Wlong-long -Wvariadic-macros -Wpointer-sign

plus others that are not controlled by named flags.  
It is not obvious
whether some of the warning should become hard errors or stay pedwarns as
some of the pedwarns were introduced as transitional paths logn time ago.


| -pedantic <-- -pedantic-errors

-ansi (and corresponding -std= options) also implies pedwarns or
errors but not all.
Moreoverm, g++ -fpermissive issues warnings where it should be
issueing hard errors. 

[...]

| -Winit-self <== -Wuninitialized # depends not only on -O1, but -O(1|2|3|s)

I believe the correct understanding is that it depends on optimization
level different from -O0.

[...]

| -Wimplicit <-- -Wall # redundant implication

Hmm, I don't understand what you mean here.

[...]

| -W --> -Wextra

We would like "-W" not to be mentioned anymore.

-- Gaby