[Bug tree-optimization/102631] New: -Wmaybe-uninitialized cannot see through a series of PHIs

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 102631
           Summary: -Wmaybe-uninitialized cannot see through a series of
                    PHIs
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aldyh at gcc dot gnu.org
  Target Milestone: ---

Created attachment 51561
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51561&action=edit
-Wmaybe-uninitialized false positive from libgomp with -O2 -Wall

The read from start_data_870 is being flagged as uninitialized, but it is not. 
The uninitialized source (start_data_518(D)) only happens for _1 == 0, and that
can't happen because the entire problematic read is predicated on _1 != 0.

Here is the read (notice it is predicated by _1 != 0:

EXHIBIT A:
  <bb 174> [count: 0]:
  _239 = gomp_tls_data.place;
  _593 = pthread_self ();
  gomp_display_affinity_thread (_593, &MEM <struct gomp_team_state> [(void
*)&gomp_tls_data + 16B], _239);
  if (_1 != 0)
    goto <bb 175>; [0.00%]
  else
    goto <bb 297>; [0.00%]

  <bb 297> [count: 0]:
  goto <bb 181>; [100.00%]

  <bb 175> [count: 0]:
  _240 = nthreads_414(D) + 4294967295;
  _241 = (long unsigned int) _240;
  _242 = _241 * 120;
  _1016 = 16 - _242;
  _341 = start_data_870 + _1016;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Wmaybe-uninitailized on the read from start_data
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  ivtmp.98_342 = (unsigned long) _341;
  goto <bb 177>; [0.00%]

If we chase start_data_870, we see:

EXHIBIT B:
  <bb 165> [local count: 33009259]:
  # start_data_781 = PHI <start_data_876(289), start_data_518(D)(265)>
  # old_threads_used_887 = PHI <old_threads_used_782(289),
old_threads_used_454(265)>
  # affinity_count_825 = PHI <affinity_count_885(289), affinity_count_343(265)>
  # affinity_thr_904 = PHI <affinity_thr_867(289), 0B(265)>
  # force_display_840 = PHI <force_display_612(289), force_display_192(265)>
  _589 = &MEM[(struct gomp_simple_barrier_t *)pool_410 + 64B].bar;
  gomp_barrier_wait (_589);

  <bb 166> [local count: 66018519]:
  # start_data_870 = PHI <start_data_876(164), start_data_781(165)>
  # old_threads_used_908 = PHI <old_threads_used_782(164),
old_threads_used_887(165)>
  # affinity_count_848 = PHI <affinity_count_885(164), affinity_count_825(165)>
  # affinity_thr_169 = PHI <affinity_thr_867(164), affinity_thr_904(165)>
  # force_display_830 = PHI <force_display_612(164), force_display_840(165)>

start_data_870 could be uninitialized if it came from BB165 because it would be
start_data_781, which in turn could be start_data_518(D) from BB265.  But
notice, we still haven't read from start_data_870.  As I have shown in the
EXHIBIT A, the read from start_data_870 is predicated by _1 != 0.

Perhaps the uninit code is treating the series of PHIs as an uninitialized
read:

  # start_data_781 = PHI <start_data_876(289), start_data_518(D)(265)>
...
...
  # start_data_870 = PHI <start_data_876(164), start_data_781(165)>
...

But AFAIK, the actual uninitialized read from start_data_870 wouldn't happen
until we use it, and that only happens under proper predication:

  if (_1 != 0)
     read from start_data_870