[prev in list] [next in list] [prev in thread] [next in thread]
List: gcc-patches
Subject: Re: Move -Wmaybe-uninitialized to -Wextra
From: Michael Witten <mfwitten () gmail ! com>
Date: 2019-11-26 19:33:56
Message-ID: c50e4536644f4b4192afbe5995661ce4-mfwitten () gmail ! com
[Download RAW message or body]
The problem with false positives is correlated with the degree of
optimization; a lot of people have reported problems at only the
`-Og' optimization level (even when the code in question is
embarrassingly correct).
Therefore, the general solution is probably that the implem-
entation of `-Wmaybe-uninitialized' be customized for the given
level of optimization.
However, I get the impression that this is easier said than done.
From what I've read, `-Wmaybe-uninitialized' is essentially
customized for `-O2', which means that it will work pretty darn
well at that optimization level. So, in the interim, I propose a
simple approximation of the general solution:
At an optimization level below `-O2' (or other than `-O2'):
* `-Wmaybe-uninitialized' is moved to `-Wextra'.
If `-Wall' has been specified, then gcc emits an
informational note stating that `-Wmaybe-uninitialized' (or
any other warning that has similar problems) has been
disabled.
* Provide a command-line option to disable such a note.
* The user may always enable `-Wmaybe-uninitialized' either
explicitly or as part of `-Wextra'.
* If `-Wmaybe-uninitialized' is enabled by the user, then it
implies `-O2' computations.
That is to say, when the user specifies:
-Og -Wmaybe-uninitialized
or:
-Og -Wextra
then the user is explicitly telling the compiler to do all
the optimizations of `-O2', but ONLY for the purpose of
implementing `-Wmaybe-uninitialized' (or whichever warning
requires those optimizations to function well); all those
optimizations are to be thrown out after they have been
used to good effect by `-Wmaybe-uninitialized'. The Code
generation, etc., shall be performed at the optimization
level the user specified (namely, `-Og' in this case).
In other words, save the user from gcc's foibles, but let the
user pay for the extra computation if so desired!
What do you think?
Sincerely,
Michael Witten
PS
All of this trouble indicates that C (and other languages)
are just not expressive enough with regard to initialization.
Initialization semantics are basically a matter of API contract
specification; the programmer needs the tools to write it down.
Surely, gcc could provide `__builtin_assume_initialized(x);' and
parameter attributes to help inform the reader (i.e., to help
inform the compiler) about the code; a function parameter
attribute could specify whether the given argument can be
considered initialized after a call, and maybe specify further
constraints, such as whether the guarantee is made only when the
function return value is nonzero (or a certain value), etc.
We need the language to write our thoughts down!
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic