This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] report as disabled options unsupported by a language (PR 80545)


On 7/22/19 3:54 PM, Martin Sebor wrote:
> While resolving PR80545 - option -Wstringop-overflow not recognized
> by Fortran, I discovered that a command line options that's supported
> only by a subset of languages is considered as enabled when tested
> by the middle-end even when the current language doesn't support
> the option.
> 
> When the option controls a warning, there is no good way to suppress
> its false positives via the usual mechanisms (i.e., specifying
> -Wno-stringop-overflow either on the command line or via a pragma)
> because the option is not recognized by the languages that do not
> support it.
> 
> The attached patch arranges for such options to be treated as disabled
> when queried by the middle-end when the current language doesn't support
> them.  The fix wasn't as straightforward as testing
> lang_hooks.option_lang_mask () in the diagnostics subsystem because
> it doesn't have access to lang_hooks. To get around it the patch adds
> a new member, diagnostic_context::lang_mask, and initializes it with
> the result of the hook.
> 
> To make debugging and testing this fix easier I enhanced the output
> of the -Q --help= options to clearly indicate when an otherwise
> recognized option isn't supported by a front-end.  For example,
> where the current trunk prints
> 
>   -Walign-commons                     [enabled]
> 
> for the Fortran-only option -Walign-commons even when GCC is invoked
> via a driver for a language like C or C++, with the patch applied it
> prints
> 
>   -Walign-commons                     [available in Fortran]
> 
> I also changed the output to indicate the what option an alias
> is for, so that for example the -Wattribute-alias option that's
> an alias for -Wattribute-alias=1 is shown with the alias target
> as the value:
> 
>   -Wattribute-alias                   -Wattribute-alias=1
> 
> Besides this, I also corrected the printing of byte-size arguments
> (they were sliced from 64 to 32 bits).
> 
> Martin
> 
> gcc-80545.diff
> 
> PR driver/80545 - option -Wstringop-overflow not recognized by Fortran
> 
> gcc/cp/ChangeLog:
> 
> 	PR driver/80545
> 	* decl.c (finish_function): Use lang_mask.
> 
> gcc/testsuite/ChangeLog:
> 
> 	PR driver/80545
> 	* gcc.misc-tests/help.exp: Add tests.
> 	* lib/options.exp: Handle C++.
> 
> gcc/ChangeLog:
> 
> 	PR driver/80545
> 	* diagnostic.c (diagnostic_classify_diagnostic): Use lang_mask.
> 	(diagnostic_report_diagnostic): Same.
> 	* diagnostic.h (diagnostic_context::option_enabled): Add an argument.
> 	(diagnostic_context::lang_mask): New data member.
> 	* ipa-pure-const.c (suggest_attribute): Use
> 	lang_hooks.option_lang_mask ().
> 	* opts-common.c (option_enabled): Handle new argument.
> 	(get_option_state): Pass an additional argument.
> 	* opts.c (print_filtered_help): Print supported languages for
> 	unsupported options.  Adjust printing of current state.
> 	* opts.h (option_enabled): Add argument.
> 	* toplev.c (print_switch_values): Use lang_mask.
> 	(general_init): Set global_dc->lang_mask.
Ironically this might have helped me today.  I was looking at a case
where an LTO build get a fatal warning, but the non-LTO build got a
different (and non-fatal due to flags warning).  It wasn't until I
started debugging the diagnostic machinery that I realized -Wall was a
language specific flag and that accounted for the difference between the
LTO and non-LTO builds.

I think this is OK, but give other folks 48hrs to chime in just in case.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]