proposal to clean up @node Warning Options in invoke.texi
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. 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. 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. 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. 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 --> Boption 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 <-- Boption 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 # A ==> Boption A enables option B # A ==> B C option A enables options B and C # A <== Boption 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 -fsyntax-only -pedantic --> -Wlong-long -Wvariadic-macros -Wpointer-sign -pedantic <-- -pedantic-errors -pedantic-errors --> -pedantic -w -Wimport <-- default -Wchar-subscripts <-- -Wall -Wcomment <-- -Wall -Wfatal-errors -Wformat --> -Wnonnull -Wformat-extra-args -Wformat-zero-length -Wformat <-- -Wformat=2 || -Wall -Wformat ==> -Wformat-y2k -Wformat-nonliteral -Wformat-security -Wformat-y2k <== -Wformat -Wno-format-extra-args <== -Wformat # false dependency -Wno-format-zero-length <== -Wformat # false dependency -Wformat-nonliteral <== -Wformat -Wformat-security <== -Wformat -Wformat=2 --> -Wformat -Wformat-y2k -Wformat-nonliteral -Wformat-security -Wnonnull <-- -Wall || -Wformat -Winit-self <== -Wuninitialized # depends not only on -O1, but -O(1|2|3|s) -Wimplicit-int <-- -Wall -Wimplicit-function-declaration <-- -Wall -Werror-implicit-function-declaration -Wimplicit --> -Wimplicit-int -Wimplicit-function-declaration -Wimplicit <-- -Wall # redundant implication -Wmain <-- -Wall -Wmissing-braces <-- -Wall -Wmissing-include-dirs -Wparentheses <-- -Wall -Wsequence-point <-- -Wall -Wreturn-type <-- -Wall -Wswitch <-- -Wall -Wswitch-default -Wswitch-enum -Wtrigraphs <-- -Wall -Wunused-function <-- -Wall -Wunused-label <-- -Wall -Wunused-parameter <-- -Wextra && -Wunused -Wunused-parameter <-- -Wextra && -Wall # redundant implication -Wunused-variable <-- -Wall -Wunused-value <-- -Wall -Wunused --> -Wtrigraphs -Wunused-function -Wunused-label -Wunused-variable -Wunused-value -Wunused <-- -Wall # redundant implication -Wuninitialized <-- -Wall -Wuninitialized ==> -Winit-self -Wuninitialized <== -O(1|2|3|s) -Wunknown-pragmas <== -Wsystem-headers # undocumented -Wpragmas <-- -Wall # missing "This warning is enabled by `-Wall'". -Wstrict-aliasing <-- -Wall || -Wstrict-aliasing=2 -Wstrict-aliasing=2 --> -Wstrict-aliasing -Wstrict-aliasing=2 <== -fstrict-aliasing -Wall --> -Wchar-subscripts -Wcomment -Wformat -Wnonnull -Wimplicit-int -Wimplicit-function-declaration -Wimplicit -Wmain -Wmissing-braces -Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wtrigraphs -Wunused-function -Wunused-label -Wunused-variable -Wunused-value -Wunused -Wuninitialized -Wpragmas -Wstrict-aliasing -Wpointer-sign # clearly not "All of the above -W options combined." # note that -Wpointer-sign is also below this point. -W --> -Wextra -Wextra --> -Wsign-compare -Wmissing-field-initializers -Wextra && -Wunused --> -Wunused-parameter # s/arguments/parameters/ -Wextra && -Wall --> -Wunused-parameter # redundant implication -Wdiv-by-zero <-- default -Wsystem-headers ==> -Wunknown-pragmas -Wfloat-equal -Wtraditi
Re: proposal to clean up @node Warning Options in invoke.texi
Chris Pickett wrote: 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. I did this against 4.1.1. I just looked at the trunk invoke.texi, and I see it has changed a bit, so just to be clear, there's no request for you to comment on omissions w.r.t. new stuff, since there are several. Chris
Re: compiling very large functions.
Steven Bosscher wrote: On 11/5/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: I would like to point out that the central point of my proposal was to have the compilation manager be the process that manages if an optimization is skipped or not rather than having each pass make a decision on it's own. If we have a central mechanism, then it is relative easy to find some sweet spots. If every pass rolls its own, it is more difficult to balance. Hmm, I don't understand this. Why is it harder to find a sweet spot if every pass decides for itself whether to run or not? I would think that this decision should be made by each pass individually, because the pass manager is one abstraction level higher where it shouldn't have to know the behavior of each pass. If every expensive pass decides it is too expensive to run, then none of them will run, when what you might have wanted is for some but not all of them to run. Being at a higher level means you can query a pass for a cost estimate given a certain set of arguments, and then decide whether or not to disable the pass based on what you know so far about the entire compilation chain. Also, often passes will interact with each other, i.e. they are not orthogonal, and a good way to manage the effects is at a higher level, as opposed to having individual passes communicating with each other. Chris
Re: proposal to clean up @node Warning Options in invoke.texi
Gerald Pfeifer wrote: Chris, I see you have not received any response to this yet, so let me give it a try. Thanks! I unsubscribed from the list and was surprised to see this in my inbox. Please continue to CC me on replies. On Sat, 28 Oct 2006, Chris Pickett wrote: 5. Fix what I have labelled as errors. That we definitely should do. I believe some things have been changed in our current development tree (to become GCC 4.3) already. It would be great could you have a look and perhaps produce a patch for one or more of these; is this something you could consider? Yes, I'll look at the trunk version, and send a series of patches. In case something ends up being longer than 10 lines, I haven't signed a copyright assignment form. I can do so, or I can waive all claim of copyright over anything I send, if that's acceptable. Cheers, Chris
Re: proposal to clean up @node Warning Options in invoke.texi
Manuel López-Ibáñez wrote: On 10 Jan 2007 05:47:19 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: Chris Pickett <[EMAIL PROTECTED]> writes: I assume the -Wno-xxx that are set by default would be moved to the "default" section? No. Warnings that are not active by default are obviously disabled, there is no need to mention them. Actually, we should be more specific saying that using Wno-* disables a warning no matter what you put on the commandline, so, strictly speaking, it is false that warnings that are not enabled by default are equivalent to -Wno-* I agree. But if Gaby actually meant the -Wxxx that are set by default, which currently means -Wno-xxx is listed, then yes, those -Wxxx would be listed in the default section. | # A <-- B && C option A is implied by options B and C together Do you have an example of this? -Wunused-parameter <-- -Wextra && -Wunused | # A --> Boption A implies option B | # A ==> Boption A enables option B What is the difference between "implies" and "enables" ? Implies: turning on A turns on B. Enables: turning on A means that turning on B will have an effect. There is probably a better wording, maybe "enables" instead of my "implies", and "is required by" instead of my "enables". | 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. Should all warnings be controlled by some or other flag? I think so, but there is doc-only work that can be done first. Insisting on each option being either a super-option or a real option but never both would fix this. | -Wimplicit <-- -Wall # redundant implication Hmm, I don't understand what you mean here. Me neither. Also, you missed -Werror-implicit-function-declaration which is a weird and useless option. I have to investigate its history. My original graph had: -Wimplicit-int <-- -Wall -Wimplicit-function-declaration <-- -Wall -Werror-implicit-function-declaration -Wimplicit --> -Wimplicit-int -Wimplicit-function-declaration -Wimplicit <-- -Wall # redundant implication The reason I said this last one is redundant is that -Wall is already documented as turning on both sub-options of the -Wimplicit super-option. I don't know what to do about it, but my intuition is that -Wimplicit should go away altogether. For now it seems not documenting the last line above would be good. Cheers, Chris
Re: proposal to clean up @node Warning Options in invoke.texi
Gabriel Dos Reis wrote:
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
[...]
| > I assume the -Wno-xxx that are set by default would be moved to the
| > "default" section?
My guess is that there is a misunderstanding here.
| Warnings that are not active by default are obviously disabled,
| there is no need to mention them.
I don't understand. Please explain further.
I'll try (since I agree). The default section should only list those
options that are enabled by default. Anything not listed there is
clearly not enabled by default.
All that I'm proposing is that:
-Wno-multichar
Do not warn if a multicharacter constant ('FOO') is used.
...
becomes:
The following options are enabled by default:
...
-Wmultichar
...
...
-Wmultichar
Warn if a multicharacter constant ('FOO') is used.
...
This option is enabled by default.
(using "enabled" for my original "implies").
If you meant something else in addition, can you give an example?
As far as I can tell, Manuel's original response was saying that one
should not list -Wno-strict-prototypes in the default section on the
basis of -Wstrict-prototypes not being default.
Thanks,
Chris
Re: proposal to clean up @node Warning Options in invoke.texi
Chris Pickett wrote: Gabriel Dos Reis wrote: | > I assume the -Wno-xxx that are set by default would be moved to the | > "default" section? If you meant something else in addition, can you give an example? I'm not subscribed to the list and so I missed Tom's message: http://gcc.gnu.org/ml/gcc/2007-01/msg00350.html "Recently I tried searching the docs for '-Wdeprecated'. There's only one hit... you have to think to search for '-Wno-deprecated' to find the actual warning. So, one cleanup I would like to see is an @opindex for *every* flag. In particular both -Wfoo and -Wno-foo should both be in the index, so that a search for either one yields a useful result. (The underlying idea being that you should be able to copy any option from a command line into info, and find docs for it.)" Just to clarify, I think that would be useful as well, but I also think we should avoid duplicating the entire index in the default section. (For space reasons, and also because it is technically not correct either, at least according to Manuel's reponse.) Cheers, Chris
Re: proposal to clean up @node Warning Options in invoke.texi
Gerald Pfeifer wrote: 5. Fix what I have labelled as errors. That we definitely should do. I believe some things have been changed in our current development tree (to become GCC 4.3) already. It would be great could you have a look and perhaps produce a patch for one or more of these; is this something you could consider? I updated my graph to the trunk version, and will slowly start sending patches per the discussion we've had. It's attached in case I disappear for whatever reason. I have a question: does -Wextra now imply -Wconversion since -Wconversion was split into -Wconversion and -Wtraditional-conversion? Thanks, Chris # A --> Boption 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 <-- Boption 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 # A ==> Boption A enables option B # A ==> B C option A enables options B and C # A <== Boption 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 -Woverflow default (C++) --> -Wwrite-strings -fsyntax-only -pedantic --> -Wlong-long -Wvariadic-macros -Wpointer-sign -Woverlength-strings -pedantic <-- -pedantic-errors -pedantic-errors --> -pedantic -w -Wimport <-- default -Wchar-subscripts <-- -Wall -Wcomment <-- -Wall -Wfatal-errors -Wformat --> -Wnonnull -Wformat-extra-args -Wformat-zero-length -Wformat <-- -Wformat=2 || -Wall -Wformat ==> -Wformat-y2k -Wformat-nonliteral -Wformat-security -Wformat-y2k <== -Wformat -Wno-format-extra-args <== -Wformat # false dependency -Wno-format-zero-length <== -Wformat # false dependency -Wformat-nonliteral <== -Wformat -Wformat-security <== -Wformat -Wformat=2 --> -Wformat -Wformat-y2k -Wformat-nonliteral -Wformat-security -Wnonnull <-- -Wall || -Wformat -Winit-self <== -Wuninitialized # depends not only on -O1, but -O(1|2|3|s) -Wimplicit-int <-- -Wall -Wimplicit-function-declaration <-- -Wall -Werror-implicit-function-declaration -Wimplicit --> -Wimplicit-int -Wimplicit-function-declaration -Wimplicit <-- -Wall # redundant implication -Wmain <-- -Wall -Wmissing-braces <-- -Wall -Wmissing-include-dirs -Wparentheses <-- -Wall -Wsequence-point <-- -Wall -Wreturn-type <-- -Wall -Wswitch <-- -Wall -Wswitch-default -Wswitch-enum -Wtrigraphs <-- -Wall -Wunused-function <-- -Wall -Wunused-label <-- -Wall -Wunused-parameter <-- -Wextra && -Wunused -Wunused-parameter <-- -Wextra && -Wall # redundant implication -Wunused-variable <-- -Wall -Wunused-value <-- -Wall -Wunused --> -Wtrigraphs -Wunused-function -Wunused-label -Wunused-variable -Wunused-value -Wunused <-- -Wall # redundant implication -Wuninitialized <-- -Wall -Wuninitialized ==> -Winit-self -Wuninitialized <== -O(1|2|3|s) -Wunknown-pragmas <== -Wsystem-headers # undocumented -Wpragmas <-- -Wall # missing "This warning is enabled by `-Wall'". -Wstrict-aliasing <-- -Wall || -Wstrict-aliasing=2 -Wstrict-aliasing=2 --> -Wstrict-aliasing -Wstrict-aliasing=2 <== -fstrict-aliasing -Wall --> -Walways-true -Wchar-subscripts -Wcomment -Wformat -Wnonnull -Wimplicit-int -Wimplicit-function-declaration -Wimplicit -Wmain -Wmissing-braces -Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wtrigraphs -Wunused-function -Wunused-label -Wunused-variable -Wunused-value -Wunused -Wuninitialized -Wpragmas -Wstrict-aliasing -Wpointer-sign -Wstring-literal-comparison # clearly not "All of the above -W options combined." # note that -Wpointer-sign is also below this point. -W --> -Wextra -Wextra --> -Wsign-compare -Wold-style-declaration -Woverride-init -Wmissing-parameter-type -Wmissing-field-initializers -Wempty-body -Wclobbered # do we have -Wextra --> -Wconversion now too? -Wextra && -Wunused --> -Wunused-parameter # s/arguments/parameters/ -Wextra && -Wall --> -Wunused-parameter # redundant implication -Wdiv-by-zero <-- default -Wsystem-headers ==> -Wunknown-pragmas -Wfloat-equal -Wtraditional -Wtraditional-conversion -Wdeclaration-after-statement -Wundef -Wendif-labels <-- default -Wshadow -Wlarger-than-LEN -Wunsafe-loop-optimizations -Wpointer-arith -Wbad-function-cast -Wc++-compat -Wcast-qual -Wcast-align -Wwrite-strings <-- default (C++) -Wclobbered <-- -Wextra -Wconversion # do we have -Wconversion <-- -Wextra now? -Wempty-body <-- -Wextra -Wsign-compare <-- -Wextra -Waggregate-return -Walways-true <-- -Wall -Wattributes <-- default -Wstrict-prototypes -Wold-style-declaration <-- -Wextra -Wold-style-definition -Wmissing-parameter-type <-- -Wextra -Wmissing-prototypes -Wmissing-de
Re: proposal to clean up @node Warning Options in invoke.texi
Chris Pickett wrote: I have a question: does -Wextra now imply -Wconversion since -Wconversion was split into -Wconversion and -Wtraditional-conversion? I mistakenly thought it was under -Wextra. So the question should be, does -Wtraditional now imply -Wtraditional-conversion since -Wconversion was split into -Wconversion and -Wtraditional-conversion? The documentation does not say so, I just wanted to check. Chris
