http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Vincent Lefèvre from comment #2)
> Well, the code paths in question do not necessarily exist (you could say the
> same thing with -O2, where the function is not inlined: there may be some
> code paths for which fn1() doesn't initialize c).
The code path exists in the code, the fact that perhaps in your program such
code path is never taken doesn't mean it is undesirable to warn about it.
GCC has two kinds of warnings, the is uninitialized one where particular code,
if executed, will always use uninitialized value, and maybe uninitialized,
where it will use uninitialized value only conditionally. That is the case
here.
>
> Actually the number of "maybe-uninitialized" warnings should decrease when
> the optimization level increases, because of additional knowledge, not the
> opposite.
No, usually with more inlining it increases and should. When fn1 is not
inlined, GCC intentionally does not warn that c might be uninitialized because
maybe the function call could use the value or not set it unconditionally, that
would lead to so huge amount of false positives for the warning that nobody
would be willing to use the warning.
