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
