public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/102631] New: -Wmaybe-uninitialized cannot see through a series of PHIs Date: Wed, 06 Oct 2021 16:43:16 +0000 [thread overview] Message-ID: <bug-102631-4@http.gcc.gnu.org/bugzilla/> (raw) 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
next reply other threads:[~2021-10-06 16:43 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-10-06 16:43 aldyh at gcc dot gnu.org [this message] 2021-10-06 16:44 ` [Bug tree-optimization/102631] " aldyh at gcc dot gnu.org 2021-10-06 16:47 ` aldyh at gcc dot gnu.org 2021-10-06 16:51 ` aldyh at gcc dot gnu.org 2021-10-07 8:21 ` aldyh at gcc dot gnu.org 2022-08-31 14:17 ` rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-102631-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).