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