This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] report as disabled options unsupported by a language (PR 80545)
- From: Jeff Law <law at redhat dot com>
- To: Martin Sebor <msebor at gmail dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 22 Jul 2019 17:26:30 -0600
- Subject: Re: [PATCH] report as disabled options unsupported by a language (PR 80545)
- References: <firstname.lastname@example.org>
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
> -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).
> PR driver/80545 - option -Wstringop-overflow not recognized by Fortran
> PR driver/80545
> * decl.c (finish_function): Use lang_mask.
> PR driver/80545
> * gcc.misc-tests/help.exp: Add tests.
> * lib/options.exp: Handle C++.
> 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.