Bug 69723 - pre-post-increment/decrement and reading the same variable that is assigned should not be considered uses for Wunused-but-set-variable
Summary: pre-post-increment/decrement and reading the same variable that is assigned s...
Status: RESOLVED DUPLICATE of bug 44677
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.9.3
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2016-02-08 18:43 UTC by Peter VARGA
Modified: 2016-02-09 20:20 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter VARGA 2016-02-08 18:43:25 UTC
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]
Comment 1 Peter VARGA 2016-02-08 18:52:18 UTC
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)
Comment 2 Jakub Jelinek 2016-02-08 19:32:20 UTC
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.
Comment 3 Peter VARGA 2016-02-08 19:42:08 UTC
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.
Comment 4 Manuel López-Ibáñez 2016-02-08 22:15:59 UTC
(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.
Comment 5 Peter VARGA 2016-02-08 23:16:21 UTC
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
Comment 6 Manuel López-Ibáñez 2016-02-09 01:17:38 UTC
(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 ***
Comment 7 Jakub Jelinek 2016-02-09 11:23:26 UTC
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).
Comment 8 Manuel López-Ibáñez 2016-02-09 20:07:03 UTC
(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).
Comment 9 Manuel López-Ibáñez 2016-02-09 20:20:13 UTC
(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)