| Summary: | Not warning anymore about usage of uninitialized variables | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Sebastian Dröge <slomo> |
| Component: | middle-end | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 7.0.1 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | ||
| Bug Depends on: | |||
| Bug Blocks: | 24639 | ||
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. Dup. *** This bug has been marked as a duplicate of bug 18501 *** But even after optimization, there would be the argc!=1 code path left, which uses the uninitialized foo. (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. 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 |
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).