On 11/18/2016 10:38 AM, Sandra Loosemore wrote:
On 11/18/2016 09:01 AM, Martin Sebor wrote:
On 11/17/2016 10:34 PM, Sandra Loosemore wrote:
On 11/16/2016 09:49 AM, Martin Sebor wrote:
I'm looking for an approval of the attached patch.
I've adjusted the documentation based on Sandra's input (i.e.,
documented the negative of the option rather than the positive;
thank you for the review, btw.)
On 11/08/2016 08:13 PM, Martin Sebor wrote:
The -fprintf-return-value optimization has been disabled since
the last time it caused a bootstrap failure on powerpc64le. With
the underlying problems fixed GCC has bootstrapped fine on all of
powerpc64, powerpc64le and x86_64 and tested with no regressions.
I'd like to re-enable the option. The attached patch does that.
[snip]
Index: gcc/doc/invoke.texi
===================================================================
--- gcc/doc/invoke.texi (revision 242500)
+++ gcc/doc/invoke.texi (working copy)
@@ -384,7 +384,7 @@ Objective-C and Objective-C++ Dialects}.
-fno-toplevel-reorder -fno-trapping-math -fno-zero-initialized-in-bss
@gol
-fomit-frame-pointer -foptimize-sibling-calls @gol
-fpartial-inlining -fpeel-loops -fpredictive-commoning @gol
--fprefetch-loop-arrays -fprintf-return-value @gol
+-fprefetch-loop-arrays -fno-printf-return-value @gol
-fprofile-correction @gol
-fprofile-use -fprofile-use=@var{path} -fprofile-values @gol
-fprofile-reorder-functions @gol
Please keep this list alphabetized -- the other "-fno-*" options are
sorted as such. The documentation parts of the patch are OK with that
fixed, but I can't approve changing the default for the option.
I kept the option in the same place on the assumption that it was
the "printf" radix of the name, not the "no-" prefix, that these
were alphabetized by.
But now that you point it out and I've looked more carefully at
some of the other options, I see that in some sections they are
listed strictly alphabetically (-fno-foo after -fmoo) while in
others it's the way you suggest. AFAICS, the former style looks
prevalent in the C++ Language Options and the in Warning Options,
for example. The latter seems to be more popular in the
Optimization Options section (though there are counterexamples).
I'm happy to follow either of these conventions as long as its
consistent. Otherwise, without both kinds of examples to choose
from, I don't think I can trust my brain to remember yet another
rule.
Well, how about the rule is that you look at the convention of the
specific list you are adding something to? At least that way we retain
local consistency and don't mess up those parts of the documentation
that we have already tried to organize in some way. There's so much
material in the command-line options chapter that it would be hard to
figure out how to present it even if the content were completely static,
much less when people are adding/renaming/modifying options all the time.
I think it would be be ideal if all the options were sorted the same
way in all sections. Is there some command to have texinfo sort them
for us? If not, can we write a script to sort them, either each time
just before generating the docs or manually? (I'm happy to help.)
Otherwise, consistency will continue to be an elusive goal.
There are at least two reasons why I don't think following the style
used by each section is likely to yield good results (and clearly
hasn't to date). First, the big sections already have examples of
both approaches (or simply options out of order). In some of them
it can also be hard to tell if the radix of the options you're
looking to for guidance starts with an 'n'. Second, when adding
more than one option to different sections (such as the
-Wformat-length and -fprintf-format-length options) having to
remember to apply a different sort order for each (warnings are
sorted by radix but optimization options, for the most parts,
strictly alphabetically), seems also likely to trip people up.
Martin
PS I don't mind moving the -fno-printf-return-value option up or
down and I will do it before committing the patch. I would just
prefer to be able not to have to remember and worry about all
these subtle rules. There are too many of them and they tend
to take time and energy away from things that matter more (like
fixing bugs).
