Bug 80152 - Not warning anymore about usage of uninitialized variables
Summary: Not warning anymore about usage of uninitialized variables
Status: RESOLVED DUPLICATE of bug 18501
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 7.0.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Blocks: Wuninitialized
  Show dependency treegraph
Reported: 2017-03-22 14:35 UTC by Sebastian Dröge
Modified: 2017-03-22 16:58 UTC (History)
0 users

See Also:
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Dröge 2017-03-22 14:35:03 UTC
See below simple testcase

#include <stdio.h>

int main(int argc, char ** argv)
  int foo;

  if (argc == 1) {
    foo = 1;

  foo += 1;

  printf("%d\n", foo);

  return 0;

foo is only initialized if argc==1, but gcc does not warn about the increment of it or the usage as a printf() argument. This is with gcc 6.3.0, but the same happens with 5.4.1 and 7.0.1.

I'm quite sure that in the past gcc warned about such cases and even more complicated ones, and clang still does. There were false positives sometimes, but those are less of a problem (just initialize the variable needlessly then) than actual undetected usage of uninitialized variables.

Might be related to bug #78370, but the explanation there does not work here. Before usage of foo no other function is called (and the explanation in that bug seems rather far-fetched: while that would certainly be possible, whoever writes such code will also be able to handle a wrong compiler warning... while having that warning prevents mistakes in normal code).
Comment 1 Richard Biener 2017-03-22 14:47:08 UTC
I think this is a commonly reported bug, conditional constant propagation optimizes away the conditional uninitialized use (substituting 1 for foo)
and thus there is nothing to warn about left.  The warning code before
any optimization happened does not warn about conditional uninitializations
because of too many false positives.
Comment 2 Richard Biener 2017-03-22 14:47:46 UTC

*** This bug has been marked as a duplicate of bug 18501 ***
Comment 3 Sebastian Dröge 2017-03-22 15:20:09 UTC
But even after optimization, there would be the argc!=1 code path left, which uses the uninitialized foo.
Comment 4 Marc Glisse 2017-03-22 16:46:03 UTC
(In reply to Sebastian Dröge from comment #3)
> But even after optimization, there would be the argc!=1 code path left,
> which uses the uninitialized foo.

No, the optimization sets foo to 1 always, and argc is not tested anymore.
Comment 5 Sebastian Dröge 2017-03-22 16:58:14 UTC
Because the value of uninitialized variables is implementation-defined, and as such gcc can freely set it to anything that it wants? That would explain it then, yes. Thanks