[Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field

[Bug tree-optimization/99919] New: [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field

[msebor at gcc dot gnu.org]

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

            Bug ID: 99919
           Summary: [9/10/11 Regression] bogus -Wmaybe-uninitialized with
                    a _Bool bit-field
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This is the -Wmaybe-uninitialized subset of pr99918 showing how the failure to
fail _Bool bit-field expressions can cause bogus warnings.  (Like pr99918, this
was most likely caused by r225825.)

$ cat z.c && gcc -O2 -S -Wall z.c
struct B { _Bool i: 1; _Bool j: 1; };

_Bool z;

void g (struct B b)
{
  _Bool x;

  if (b.i)
    b.j = 0;
  else
    {
      b.j = b.i;
      x = b.i;
    }

  if (b.j)
    z = x;
}

z.c: In function ‘g’:
z.c:18:7: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   18 |     z = x;
      |     ~~^~~
z.c:7:9: note: ‘x’ was declared here
    7 |   _Bool x;
      |         ^

[Bug tree-optimization/99919] [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |99918

--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
The IL below shows there is enough information in the IL for the warning to
determine that x_5 is never read from.

void g (struct B b)
{
  _Bool b$j;
  _Bool b$i;
  _Bool x;
  unsigned char _1;
  unsigned char _2;
  unsigned char _3;
  unsigned char _4;

  <bb 2> [local count: 1073741824]:
  b$i_11 = b.i;
  _1 = VIEW_CONVERT_EXPR<unsigned char>(b);
  _2 = _1 & 1;
  if (_2 != 0)
    goto <bb 4>; [50.00%]
  else
    goto <bb 3>; [50.00%]

  <bb 3> [local count: 536870912]:

  <bb 4> [local count: 1073741824]:
  # x_5 = PHI <x_8(D)(2), b$i_11(3)>
  # b$j_10 = PHI <0(2), b$i_11(3)>
  b.j = b$j_10;
  _3 = VIEW_CONVERT_EXPR<unsigned char>(b);
  _4 = _3 & 2;
  if (_4 != 0)
    goto <bb 5>; [50.00%]
  else
    goto <bb 6>; [50.00%]

  <bb 5> [local count: 536870913]:
  z = x_5;

  <bb 6> [local count: 1073741824]:
  return;

}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99918
[Bug 99918] [9/10/11 Regression] suboptimal code for bool bitfield tests

[Bug tree-optimization/99919] [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |9.4

[Bug tree-optimization/99919] [9/10/11 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug tree-optimization/99919] [9/10/11/12 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug tree-optimization/99919] [9/10/11/12 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #1)
> The IL below shows there is enough information in the IL for the warning to
> determine that x_5 is never read from.
> 
> void g (struct B b)
> {
>   _Bool b$j;
>   _Bool b$i;
>   _Bool x;
>   unsigned char _1;
>   unsigned char _2;
>   unsigned char _3;
>   unsigned char _4;
> 
>   <bb 2> [local count: 1073741824]:
>   b$i_11 = b.i;
>   _1 = VIEW_CONVERT_EXPR<unsigned char>(b);
>   _2 = _1 & 1;
>   if (_2 != 0)
>     goto <bb 4>; [50.00%]
>   else
>     goto <bb 3>; [50.00%]
> 
>   <bb 3> [local count: 536870912]:
> 
>   <bb 4> [local count: 1073741824]:
>   # x_5 = PHI <x_8(D)(2), b$i_11(3)>
>   # b$j_10 = PHI <0(2), b$i_11(3)>
>   b.j = b$j_10;
>   _3 = VIEW_CONVERT_EXPR<unsigned char>(b);
>   _4 = _3 & 2;
>   if (_4 != 0)
>     goto <bb 5>; [50.00%]
>   else
>     goto <bb 6>; [50.00%]
> 
>   <bb 5> [local count: 536870913]:
>   z = x_5;
> 
>   <bb 6> [local count: 1073741824]:
>   return;
> 
> }

The warning on the above IL seems legit.

x_5 is initialized from b$i_11 when b & 1 == 0, but the read from x_5 happens
when b & 2 != 0.  So the set and the read are predicated on two different
things.

Maybe I'm missing some subtle bit field thing.  Does setting b.j somehow alter
b.i?

[Bug tree-optimization/99919] [9/10/11/12 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2021-11-30
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |pinskia at gcc dot gnu.org
   Target Milestone|9.5                         |13.0
           Keywords|                            |deferred

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #3)
> The warning on the above IL seems legit.
> 
> x_5 is initialized from b$i_11 when b & 1 == 0, but the read from x_5
> happens when b & 2 != 0.  So the set and the read are predicated on two
> different things.
> 
> Maybe I'm missing some subtle bit field thing.  Does setting b.j somehow
> alter b.i?
b.j is (b&2)<<1.

If lower bit field acceses it is fixed (but also becomes more obvious what the
of b.j is:
  _20 = VIEW_CONVERT_EXPR<unsigned char>(b);
  _21 = BIT_INSERT_EXPR <_20, b$j_15, 1 (1 bits)>;
  VIEW_CONVERT_EXPR<unsigned char>(b) = _21;
  _3 = VIEW_CONVERT_EXPR<unsigned char>(b);
  _4 = _3 & 2;

So Mine for GCC 13.

[Bug tree-optimization/99919] [9/10/11/12 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field

[aldyh at gcc dot gnu.org]

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

--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Aldy Hernandez from comment #3)
> > The warning on the above IL seems legit.
> > 
> > x_5 is initialized from b$i_11 when b & 1 == 0, but the read from x_5
> > happens when b & 2 != 0.  So the set and the read are predicated on two
> > different things.
> > 
> > Maybe I'm missing some subtle bit field thing.  Does setting b.j somehow
> > alter b.i?
> b.j is (b&2)<<1.
> 
> If lower bit field acceses it is fixed (but also becomes more obvious what
> the of b.j is:
>   _20 = VIEW_CONVERT_EXPR<unsigned char>(b);
>   _21 = BIT_INSERT_EXPR <_20, b$j_15, 1 (1 bits)>;
>   VIEW_CONVERT_EXPR<unsigned char>(b) = _21;
>   _3 = VIEW_CONVERT_EXPR<unsigned char>(b);
>   _4 = _3 & 2;
> 
> So Mine for GCC 13.

You're a rockstar.  Thanks.

[Bug tree-optimization/99919] [10/11/12/13 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note the uninit pass has code to deal with this special

  if (b.i)
    b.j = 0;
...

  if (b.j)
...

but it's confused by the b.j = 0 store appearing literally compared to the
b.j test being done via a (b & 2) test.  That's also a missed jump threading
opportunity and possibly a missed CSE opportunity.

b.j = b$j_10;
_3 = VIEW_CONVERT_EXPR<unsigned char>(b);
_4 = _3 & 2;

here _4 could be CSEd as b$j_10.  In fact we do have code for this in CSE
but the two pieces that would need to work together, a masked load and
partial def support, refuse to work together here.  In particular the
mask can be used to fend off not relevant non-constants and to narrow
the bits we want to fill.

Not to say SRA does a bad job on this testcase, it's also premature
optimize_bit_field_compare "optimization" here.  Maybe it's time to
kill off the case of bitfield vs constant compare "optimization".

[Bug tree-optimization/99919] [10/11/12/13 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 54047
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54047&action=edit
patch

I also have a patch - this disables optimize_bit_field_compare for
bitfield vs. constant compares which is the source of most premature
obfuscation and avoids missing the optimization of multiple bitfield
extracts as if more aggressively removing this code.

[Bug tree-optimization/99919] [10/11/12/13/14 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.0                        |13.2

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.

[Bug tree-optimization/99919] [11/12/13/14 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.2                        |13.3

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.2 is being released, retargeting bugs to GCC 13.3.

[Bug tree-optimization/99919] [11/12/13/14 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2021-11-30 00:00:00         |2023-12-15
                 CC|                            |jamborm at gcc dot gnu.org

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
This is also a missed SRA optimization.  SRA produces

  b$i_16 = b.i;
  b$j_17 = b.j;
  b.i = b$i_16;
  b.j = b$j_17;
  _1 = VIEW_CONVERT_EXPR<unsigned char>(b);
  _2 = _1 & 1;
...
  b.i = b$i_16;
  b.j = b$j_15;
  _4 = VIEW_CONVERT_EXPR<unsigned char>(b);
  _5 = _4 & 2;

which is sub-optimal - for some reason it chooses to create replacements
for i and j instead of a unsigned char replacement for the whole
aggregate driven by the V_C_E access

access { base = (2771)'b', offset = 0, size = 8, expr = b, type = struct B,
reverse = 0, grp_read = 1, grp_write = 0, grp_assignment_read = 1,
grp_assignment_write = 0, grp_scalar_read = 0, grp_scalar_write = 0,
grp_total_scalarization = 0, grp_hint = 0, grp_covered = 0,
grp_unscalarizable_region = 0, grp_unscalarized_data = 1, grp_same_access_path
= 1, grp_partial_lhs = 0, grp_to_be_replaced = 0, grp_to_be_debug_replaced = 0}

is also odd because the access type is really 'unsigned char'?  That seems
to be because

  /* We need to dive through V_C_Es in order to get the size of its parameter
     and not the result type.  Ada produces such statements.  We are also
     capable of handling the topmost V_C_E but not any of those buried in other
     handled components.  */
  if (TREE_CODE (expr) == VIEW_CONVERT_EXPR)
    expr = TREE_OPERAND (expr, 0);

but I couldn't easily convince it to do sth here (and dumps turn out
empty as for reasoning of disqualification).

[Bug tree-optimization/99919] [11/12/13/14/15 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.3                        |13.4

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 13.3 is being released, retargeting bugs to GCC 13.4.