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

             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: link
Be 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).