Bug 55060 - False un-initialized variable warnings
Summary: False un-initialized variable warnings
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.8.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: diagnostic
Depends on:
Blocks: Wuninitialized
  Show dependency treegraph
Reported: 2012-10-24 17:44 UTC by Han Shen
Modified: 2017-09-20 17:44 UTC (History)
4 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2012-10-25 00:00:00


Note You need to log in before you can comment on or make changes to this bug.
Description Han Shen 2012-10-24 17:44:35 UTC
Compiler version - trunk @ 192770
Compilation option - -c -O2 -Wall
Source - 
static void a(int *i) { }
static void b(int p) { }

int main(int argc, char *argv[]) {
  int i;
  return 0;

Compilation output - 
/home/shenhan/test.c: In function ‘main’:
/home/shenhan/test.c:7:4: warning: ‘i’ is used uninitialized in this function [-Wuninitialized]

A quick diagnose by David (Xingliang) Li is copied below - 

"The early uninitialized variable warning happens before inlining phase. Before 4.7, compiler does not warn this because the call to a(&i) which may initialize 'i' (the analysis is only intra-procedural).

In 4.7 (and above), the SRA optimization pass which happens before the analysis is smart enough to replace the call to 'a' into a clone of 'a' which takes no argument.  However the second access to 'i' still remains, thus the warning."
Comment 1 Andrew Pinski 2012-10-24 17:50:05 UTC
Is it only because b does not use its arguments you are saying it is a false un-initialized warning?
Comment 2 Han Shen 2012-10-24 17:55:40 UTC
Yeah, I think value of "i" is never used.
Comment 3 Manuel López-Ibáñez 2012-10-24 19:18:51 UTC
This doesn't warn, so it seems there is something else going on apart from SRA.

static void b(int p) { }

int main(int argc, char *argv[]) {
  int i;
  return 0;

Moving a(&i) after b(i) also prevents the warning. 

Comment 4 Manuel López-Ibáñez 2012-10-24 19:21:00 UTC
And the caret location is off-by-one. More weird.
Comment 5 Richard Biener 2012-10-25 11:22:40 UTC
At the point of the early uninit pass it sees:

main (int argc, char * * argv)
  int i;
  int D.1716;
  int i.0;

<bb 2>:
  a.isra.0 ();
  # VUSE <.MEM_3(D)>
  i.0_1 = i;
  b.isra.1 ();
  D.1716_2 = 0;
  # .MEM_4 = VDEF <.MEM_3(D)>
  i ={v} {CLOBBER};
  # VUSE <.MEM_4>
  return D.1716_2;

thus a read from the memory location 'i' which is uninitialized.  Dead code
elimination has not yet removed that read (i.0_1 is unused after all).

I'd say the literal presence of b (i) is considered a use of i in C-terms,
thus the warning is not really incorrect.

That IPA-SRA has this side-effect on the otherwise still unoptimized
body of main is bad - early uninit was put before early inlining for a reason
and now IPA-SRA defeats this ... can we make it more "IPA" like and
have an explicit local transform stage?