Re: Understanding compiler warning options

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/2/2015 6:59 AM, Edward Diener wrote:
On 10/1/2015 6:22 PM, Manuel López-Ibáñez wrote:
On 30/09/15 03:57, Martin Sebor wrote:
On 09/29/2015 05:41 PM, Edward Diener wrote:
I am trying to understand how the compiler decides which warnings are
issued when compiling a translation unit.

What is the default warnings that are issued if no compiler warning
options is set on the command line ?
[...]
An example might be the -Wdiv-by-zero warning that's defined like
this:

   Wdiv-by-zero
   C ObjC C++ ObjC++ Var(warn_div_by_zero) Init(1) Warning
   Warn about compile-time integer division by zero

Unfortunately, many options are enabled under some conditions and this
cannot (yet) be encoded in the .opt files: https://gcc.gnu.org/PR53063

Any contribution in that direction would be welcome.

You may be able to tell (probably less reliably) from the manual
by searching for warning options listed in the negative -Wno-xxx
form. For instance:

   -Wno-endif-labels
       Do not warn whenever an #else or an #endif are followed by text.

means the option is enabled by default. Other options may say
when (e.g., in what language) they're enabled by default.

I think the consensus nowadays is that options that are enabled by
default under some condition should be documented as such directly.
Documenting the -Wno- form is not really useful as a substitute for this
because the "default" depends on other options (e.g., -std=), language,
target, etc. Documentation patches welcome!

If I set a general option, such as -w, -Wall, or -Wextra, do these get
overridden by more specific compiler options no matter where in the
command line they are encountered, or does the order of the compiler
warnings on the command line matter in such a case ? As a specific
practical example if the command line has "-Wno-unused-local-typedef
-Wall ..." does the "-Wno-unused-local-typedef" override the "-Wall"
option ?

Unfortunately, this is neither documented nor necessarily intuitive
(YMMV). IME, the best way to find out is by experimenting.

It is documented here:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options

but perhaps it could be better documented. Again, unless someone gives
it a try to improve the documentation, it will remain the same.

In particular: "You can request many specific warnings with options
beginning with ‘-W’, for example -Wimplicit to request warnings on
implicit declarations. Each of these specific warning options also has a
negative form beginning ‘-Wno-’ to turn off warnings; for example,
-Wno-implicit. This manual lists only one of the two forms, whichever is
not the default.

Some options, such as -Wall and -Wextra, turn on other options, such as
-Wunused, which may turn on further options, such as -Wunused-value. The
combined effect of positive and negative forms is that more specific
options have priority over less specific ones, independently of their
position in the command-line. For options of the same specificity, the
last one takes effect."

The next to last line you quoted implies to me that the "-w" option can
be overriden by nore specific warning messages which turn back on a
particular warnings, since "-w" is a general way to turn off all warnings.

Corrected syntax/explanation:

"The next to last line you quoted ('The combined effect of positive and negative forms is that more specific options have priority over less specific ones') implies to me that the '-w' option, since '-w' is a less specific way to turn off all warnings, can be overriden by more specific warning messages which turn back on a particular warning. But one of the original responses I received on this thread is that '-w' permanently sets all warnings off no matter what specific warning is set on. So I don't think that next to last line quote is always true, although I would have hoped as a general rule that it was."



The above behavior is handled automatically nowadays such that all
options behave the same. If it doesn't work, something is wrong in the
.opt file or the option was never converted to the automatic way of
handling options dependencies and it is being set explicitly somewhere,
which is also a latent bug.








[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux