public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning
Date: Mon, 05 Apr 2021 20:34:34 +0000	[thread overview]
Message-ID: <bug-85301-4-Ep30uQa9ZI@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-85301-4@http.gcc.gnu.org/bugzilla/>

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2018-04-09 00:00:00         |2021-4-5
      Known to fail|                            |10.2.0, 11.0, 8.3.0, 9.3.0
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=99919
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #8 from Martin Sebor <msebor at gcc dot gnu.org> ---
Reconfirmed with GCC 11 with the ever-so-slightly slightly simplified program
below and enhanced output.  The warning has been issued since at least GCC 4.1
and so is not a regression.

$ cat pr85301.c && gcc -O2 -S -Wall -DUSE_BITFIELD  pr85301.c
struct A
{
#ifdef USE_BITFIELD
  unsigned i : 1;
  unsigned j : 1;
#else
  unsigned i;
  unsigned j;
#endif
};

int z, f (void);

struct A a;

void h (void)
{
  int y;

  if (a.j || a.i)
    y = f ();

  if (a.i)
    z = y;
}

pr85301.c: In function ‘h’:
pr85301.c:24:7: warning: ‘y’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   24 |     z = y;
      |     ~~^~~
pr85301.c:18:7: note: when ‘!(((unsigned char*)&a)[0] & 3)’
   18 |   int y;
      |       ^
pr85301.c:18:7: note: used when ‘prephitmp_15 = PHI <_1(7), pretmp_14(3)> & 1’
pr85301.c:18:7: note: ‘y’ was declared here

Jump threading and other optimization opportunities aside (I have raised
pr99918 for one of those), there does also seem to be a limitation in the
warning code in that it doesn't understand BIT_FIELD_REF expressions.  The
warning sees the IL below from which it should be able to determine that y's
use is conditional on its definition (i.e., the use predicate a strict subset
of the predicate controlling the definition).

void h ()
{
  int y;
  unsigned char _1;
  unsigned char _2;
  unsigned char _4;
  unsigned char pretmp_14;
  unsigned char prephitmp_15;

  <bb 2> [local count: 1073741824]:
  # VUSE <.MEM_8(D)>
  _1 = BIT_FIELD_REF <a, 8, 0>;
  _2 = _1 & 3;
  if (_2 != 0)
    goto <bb 3>; [33.00%]
  else
    goto <bb 7>; [67.00%]

  <bb 7> [local count: 719407024]:
  goto <bb 4>; [100.00%]

  <bb 3> [local count: 354334800]:
  # .MEM_10 = VDEF <.MEM_8(D)>
  y_11 = f ();
  # VUSE <.MEM_10>
  pretmp_14 = BIT_FIELD_REF <a, 8, 0>;

  <bb 4> [local count: 1073741824]:
  # y_5 = PHI <y_9(D)(7), y_11(3)>
  # .MEM_6 = PHI <.MEM_8(D)(7), .MEM_10(3)>
  # prephitmp_15 = PHI <_1(7), pretmp_14(3)>
  _4 = prephitmp_15 & 1;
  if (_4 != 0)
    goto <bb 5>; [50.00%]
  else
    goto <bb 8>; [50.00%]

  <bb 8> [local count: 536870912]:
  goto <bb 6>; [100.00%]

  <bb 5> [local count: 536870913]:
  ## y_5 = PHI <y_9(D)(7), y_11(3)>
  ## uninit when: _2 == 0
  ##            : BIT_FIELD_REF <a, 8, 0> & 3 == 0
  ##
  ## used when: prephitmp_15 & != 0
  ##          : PHI <_1(7), pretmp_14(3)>
  ##          : _1(7) != 0 || pretmp_14 != 0
  ##          : BIT_FIELD_REF <a, 8, 0> != 0 || BIT_FIELD_REF <a, 8, 0> != 0
  ##          : BIT_FIELD_REF <a, 8, 0> != 0
  # .MEM_12 = VDEF <.MEM_6>
  z = y_5;

  <bb 6> [local count: 1073741824]:
  # .MEM_7 = PHI <.MEM_6(8), .MEM_12(5)>
  # VUSE <.MEM_7>
  return;

}

       reply	other threads:[~2021-04-05 20:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-85301-4@http.gcc.gnu.org/bugzilla/>
2021-04-05 20:34 ` msebor at gcc dot gnu.org [this message]
2022-11-20  4:17 ` law at gcc dot gnu.org
2022-11-28 22:36 ` pinskia 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-85301-4-Ep30uQa9ZI@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).