On Mon, Mar 16, 2020 at 06:11:08PM +0000, Richard Sandiford wrote:
> Lewis Hyatt via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
...
> > FWIW there are three other options currently affected by this change
> > (-Wimplicit-fallthrough, -fcf-protection, and -flive-patching). The change 
> > for
> > -Wimplicit-fallthrough I think is particularly helpful:
> >
> > -Wimplicit-fallthrough      Same as -Wimplicit-fallthrough=.  Use the 
> > latter option instead.
> > becomes
> > -Wimplicit-fallthrough      Same as -Wimplicit-fallthrough=3 (or, in 
> > negated form, -Wimplicit-fallthrough=0).
> 
> I also see:
> 
> -  -ftail-call-workaround      Same as -ftail-call-workaround=.  Use the 
> latter option instead.
> +  -ftail-call-workaround      Same as -ftail-call-workaround=1 (or, in 
> negated form, -ftail-call-workaround=0).
>    -ftail-call-workaround=<0,2> Disallow tail call optimization when a 
> calling routine may have omitted character lengths.
> ...
>    --imacros                   Same as -imacros.  Use the latter option 
> instead.
>    --imacros=                  Same as -imacros.  Use the latter option 
> instead.
>    --include                   Same as -include.  Use the latter option 
> instead.
> -  --include-barrier           Same as -I.  Use the latter option instead.
> +  --include-barrier           Same as -I-.
>    --include-directory         Same as -I.  Use the latter option instead.
>    --include-directory-after   Same as -idirafter.  Use the latter option 
> instead.
>    --include-directory-after=  Same as -idirafter.  Use the latter option 
> instead.
> ...
> -  -Wnormalized                Same as -Wnormalized=.  Use the latter option 
> instead.
> +  -Wnormalized                Same as -Wnormalized=nfc (or, in negated form, 
> -Wnormalized=none).
>    -Wnormalized=[none|id|nfc|nfkc] Warn about non-normalized Unicode strings.
> 
> I agree all of these look like improvements, especially the
> --include-barrier one.  But I think the include ones also show
> that the "Use the latter option instead." decision is independent
> of whether the option is defined to be an alias.
> 
> FWIW, there's also:
> 
> Wmissing-format-attribute
> C ObjC C++ ObjC++ Warning Alias(Wsuggest-attribute=format)
> ;
> 
> which still ends up as:
> 
>   -Wmissing-format-attribute  Same as -Wsuggest-attribute=format.  Use the 
> latter option instead.
> 
> Not really my area though, so I don't have any specific suggestion
> about how to separate the cases.
> 

Right, sorry, in my first email I only mentioned the options output by
--help=common, but there were a few more as well. Thanks very much for trying
it out and for the feedback.

The rule I implemented was to change the help output for all alias options
with no documentation if they also specify the extra 2nd option (or 2nd and
3rd options) to the Alias directive. For example, -include-barrier is like this:

-include-barrier C ObjC C++ ObjC++ Alias(I, -)

It serves to provide the argument '-' to the option '-I', so it is eligible for
the new text. The others are like this one:

-include-directory-after C ObjC C++ ObjC++ Separate Alias(idirafter) 
MissingArgError(missing path after %qs)

Since that one doesn't pass the extra args to Alias, I interpreted it to
mean this is the case for which the "Use the latter option" directive was
intended to apply. (-idirafter has been designated as preferable to
-include-directory-after).

Regarding -Wmissing-format-attribute, that is an interesting case, it's the only
instance in any *.opt that has an = sign in the Alias target. If I understand
correctly, this one can't use the 3-argument form of Alias() because
-Wno-missing-format-attribute is actually an alias for
-Wno-suggest-attribute=format, rather than -Wsuggest-attribute=<something>. I
think that one could be left as is or else my patch would need to check for an =
sign in the alias target and handle this case as well, but that may lead to
other surprises in the future.

Thanks!

-Lewis

Reply via email to