It is here described: http://stackoverflow.com/questions/35269414/gcc-does-not-warn-variable-set-but-not-used auto foo() -> void { int unused = 0; unused++; } and auto foo() -> void { int x; int unused; for ( ; x < 100; x++ ) unused++; } do not generate and warnings. Only the -O1 generates an error. I expect error: variable ‘unused’ set but not used [-Werror=unused-but-set-variable]. error: ‘unused’ and ‘x’ are used uninitialized [-Werror=uninitialized]
Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.3/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.9.3_source/configure --disable-multilib Thread model: posix gcc version 4.9.3 (GCC)
The unused variables are not warned with -Wunused-but-set-variable, because they aren't unused, it warns (see documentation) only about variables that are only ever set, but never read. But unused++ reads it and writes it at the same time. As for the uninitialized warnings, GCC has 2 passes, early uninitialized warning pass, which is done at all levels, and warns about easy proven cases of uninitialization (which doesn't warn, because the only uninitialized use is in a PHI, something intentionally not tracked at that point), and then one late uninitialized pass, which is run only in the optimization queue, after most of the GIMPLE optimizations, which warns in the -O1/-Og cases; for -O2/-O3 does not warn, because the whole loop is optimized away far before that.
Dear Jakob, thank you for the explanation. But honestly, the "definition" when to warn is in my eyes wrong. Even var++ is reading and then setting the variable in this case it does NOT make sense! Just imagine I had a function with 200 lines and I "forgot" this variable in a refactoring process. gcc could have warn me because it is not logical and the variable is set but NOT used. May be the gcc community can reconsider the definition.
(In reply to Peter VARGA from comment #3) > thank you for the explanation. But honestly, the "definition" when to warn > is in my eyes wrong. Even var++ is reading and then setting the variable in > this case it does NOT make sense! Replace unused++ with unused = unused + 1. If we want GCC to warn about that, we would need, for every VAR = EXPRESSION, check if VAR appears in EXP. It may be possible, but it probably needs to keep track of VAR while parsing EXP, which may require touching an awful number of functions.
I do not understand what you mean with "Replace unused++ with unused = unused + 1". How ever. I checked my example code in Compiler Explorer with clang and clang generates a warning as it should be. OK. You was honest that this means a lot of work but it is a bug and of course everybody can live with it. https://goo.gl/5eaLw5
(In reply to Peter VARGA from comment #5) > I do not understand what you mean with "Replace unused++ with unused = > unused + 1". > > How ever. I checked my example code in Compiler Explorer with clang and > clang generates a warning as it should be. Only for the -Wuninitialized (which GCC warns with -O1). Clang doesn't even catch void foo() { int unused; unused=0; } *** This bug has been marked as a duplicate of bug 44677 ***
As for the missed -Wuninitialized at -O0, wonder if we couldn't do something about it for GCC 7. volatile int v; void bar (void) { int x; v++; for (; x < 100; x++) v++; v++; } Here, we have # x_1 = PHI <x_7(D)(2), x_11(3)> if (x_1 <= 99) in an always_executed basic block, normally we don't look at PHIs in the early uninit pass at all, but wonder if for always_executed bbs we couldn't make an exception - if the uninited value is from the immediate dominator of the bb and the PHI result is used in an always_executed basic block, it IMHO means a clear case where the use is always uninitialized (if the function is ever called, but other must uninitialized warnings are making the same assumption).
(In reply to Jakub Jelinek from comment #7) > As for the missed -Wuninitialized at -O0, wonder if we couldn't do something > about it for GCC 7. Sounds good to me, but perhaps it is better to open a new PR. This one is a bit messy (and closed as a duplicate).
(In reply to Jakub Jelinek from comment #7) > As for the missed -Wuninitialized at -O0, wonder if we couldn't do something > about it for GCC 7. Note that people do complain a lot about this case: PR43361 and duplicates. When I analyzed all open Wuninitialized bugs, this was problem #2 (https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings#Problem_2:_Representation_issues_.28either_IR_or_SSA_issues.29)