[Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM)

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430

Richard Biener  changed:

   What|Removed |Added

 CC||dominiq at lps dot ens.fr

--- Comment #38 from Richard Biener  ---
*** Bug 34721 has been marked as a duplicate of this bug. ***

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM)

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2005-05-03 18:04:44 |2022-8-29

--- Comment #37 from Richard Biener  ---
Re-confirmed for the original testcase.  The issue is that while we now try to
perform uninitialized diagnostics for memory we do not perform the maybe-uninit
analysis via PHIs we do for non-memory.  We see

   [local count: 1073741824]:
  # .MEM_5 = VDEF <.MEM_3(D)>
  _1 = bar (i_4(D));
  if (_1 != 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 719407024]:
  goto ; [100.00%]

   [local count: 354334800]:
  # .MEM_6 = VDEF <.MEM_5>
  baz ();

   [local count: 1073741824]:
  # .MEM_2 = PHI <.MEM_5(5), .MEM_6(3)>
  # VUSE <.MEM_2>
  _7 = j;

so when we are walking and looking for defs of 'j' by means of
walk_aliased_vdefs but that will simply process MEM_6 "unordered"
and record that as possible definition.  We are not properly forking
the walk to discover a path where 'j' is not initialized nor are
we trying to compute predicates which guard the use.

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM)

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430

Martin Sebor  changed:

   What|Removed |Added

 CC||scott.d.phillips at intel dot 
com

--- Comment #36 from Martin Sebor  ---
*** Bug 78370 has been marked as a duplicate of this bug. ***

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM)

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #35 from Martin Sebor  ---
GCC 11 issues a warning when the address of an uninitialized variable is passed
to a function that takes a const pointer but it (still) doesn't warn when the
address escapes.  In both cases, it's possible for the called function to store
a value into the variable but because it's highly unlikely issuing a warning
regardless would be appropriate.  In addition, in cases where the address of
the variable doesn't escape until after the function call its value cannot be
affected even when the address is assigned to a non-const pointer.  The escape
analysis is flow insensitive so it alone cannot be relied on to make the
distinction.  But modifying variables this way is rare so issuing the warning
regardless is likely worthwhile.

$ cat a.c && gcc -O2 -S -Wall a.c
extern void f (const void*);

int g (void)
{
  int i;
  f ();   // -Wmaybe-uninitialized
  return i;
}

int h (void)
{
  extern const void *p;

  int i;
  f (0);
  p = 
  return i; // missing -Wmaybe-uninitialized
}

a.c: In function ‘int g()’:
a.c:6:5: warning: ‘i’ may be used uninitialized [-Wmaybe-uninitialized]
6 |   f ();
  |   ~~^~~~
a.c:1:13: note: by argument 1 of type ‘const void*’ to ‘void f(const void*)’
declared here
1 | extern void f (const void*);
  | ^
a.c:5:7: note: ‘i’ declared here
5 |   int i;
  |   ^