public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: "Gao, Liming" <liming.gao@intel.com>,
	Laszlo Ersek <lersek@redhat.com>,
	edk2-devel-01 <edk2-devel@lists.01.org>
Cc: "Justen, Jordan L" <jordan.l.justen@intel.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH 1/1] OvmfPkg/IoMmuDxe: shut up "unused-const-variable" gcc-6 warning in RELEASE
Date: Thu, 7 Sep 2017 07:47:09 +0200	[thread overview]
Message-ID: <42a7bf30-49b6-fea8-91fb-5922a2931173@proxmox.com> (raw)
In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14D78B39E@shsmsx102.ccr.corp.intel.com>

On 09/07/2017 05:38 AM, Gao, Liming wrote:
> Laszlo:
>    I add -Wno-unused-const-variable option in GCC5 RELEASE option, and build OvmfPkg with GCC5.3. I don't meet any warning or error. Do you meet any issue? So, you think we can't add this option in GCC5 tool chain.
> 

Yes, he is right, looking at:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options

> When an unrecognized warning option is requested (e.g.,
> -Wunknown-warning), GCC emits a diagnostic stating that the option is
> not recognized. However, if the -Wno- form is used, the behavior is
> slightly different: no diagnostic is produced for -Wno-unknown-warning
> unless other diagnostics are being produced. This allows the use of new
> -Wno- options with old compilers, but if something goes wrong, the
> compiler warns that an unrecognized option is present.

Also the older ones support it:
https://gcc.gnu.org/onlinedocs/gcc-4.9.4/gcc/Warning-Options.html#Warning-Options
https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/Warning-Options.html#Warning-Options

I verified this behavior on gcc 5.4 and on gcc version 4.4.5 (Debian 4.4.5-8)
(spun up an squeeze container, fun times)

This seems like an easy solution, hopefully also a valid one in the edk2 context.
The gcc rationale seems good, if there is such a warning suppress it, if not we
wouldn't output any warning anyhow, so there is nothing to suppress.

The only drawback seems that if something goes wrong the user could wonder if
those "unrecognized command line options" have something to do with his problem.

It looks like this (gcc 4.4.5):

tom@olddeb:~# gcc -Wall -Wno-foo-bar test.c
test.c: In function 'main':
test.c:4: warning: unused variable 'test'
At top level:
cc1: warning: unrecognized command line option "-Wno-foo-bar"

And very similar on gcc 6:

tom@plain-stretch:~# gcc -Wall -Wno-foo-bar test.c
test.c: In function ‘main’:
test.c:7:9: warning: unused variable ‘test’ [-Wunused-variable]
      int test;
          ^~~~
test.c: At top level:
cc1: warning: unrecognized command line option ‘-Wno-foo-bar’

cheers,
Thomas




  reply	other threads:[~2017-09-07  5:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-06 16:48 [PATCH 0/1] OvmfPkg/IoMmuDxe: shut up "unused-const-variable" gcc-6 warning in RELEASE Laszlo Ersek
2017-09-06 16:48 ` [PATCH 1/1] " Laszlo Ersek
2017-09-06 16:56   ` Ard Biesheuvel
2017-09-06 17:09     ` Laszlo Ersek
2017-09-06 17:12       ` Ard Biesheuvel
2017-09-06 17:18         ` Laszlo Ersek
2017-09-07  3:38   ` Gao, Liming
2017-09-07  5:47     ` Thomas Lamprecht [this message]
2017-09-07  7:32       ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42a7bf30-49b6-fea8-91fb-5922a2931173@proxmox.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox