http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
Vincent Lefèvre <vincent-gcc at vinc17 dot net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |---
--- Comment #8 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Vincent Lefèvre from comment #5)
> It exists *only* if fn2() can return 0. But the fact is that in the reality,
> this can never happen (with the original non-reduced code, this can even be
> proved).
After an analysis of the MPFR code, it actually seems to be a bug in MPFR. So,
the problem is the missing warning with -O2.
The -Wmaybe-uninitialized rule given in the gcc man page is (for GCC 4.8):
-Wmaybe-uninitialized
For an automatic variable, if there exists a path from the function
entry to a use of the variable that is initialized, but there exist
some other paths for which the variable is not initialized, the
compiler emits a warning if it cannot prove the uninitialized paths
are not executed at run time. [...]
This rule does *not* depend on the optimization level, except for the "if it
cannot prove the uninitialized paths are not executed at run time" part.
Indeed, the fact that a path exists or not is not something that depends on the
optimizations.
Concerning the "if it cannot prove the uninitialized paths are not executed at
run time" part, GCC should be able to prove more things with -O3 than with -O2,
meaning that -Wmaybe-uninitialized warnings could disappear with -O3 compared
to -O2, but generally not the opposite.
In the original example, GCC cannot prove anything about run time, so that
according to the gcc man page, one should get a warning whatever the
optimization level.
I've another example (similar to the MPFR code):
int fn3 (void);
void fn2 (int *p)
{
if (fn3 ())
*p = 0;
}
int fn1 (void)
{
int c;
fn2 (&c);
return c;
}
GCC doesn't give any "may be used uninitialized" warning (whether -O2 or -O3 is
used). This is incorrect according to the above rule. BTW, for -O3, this is
surprising because it is similar to the original example.
I'm reopening the bug because the GCC behavior doesn't match the documentation.
