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!

Reply via email to