[Bug tree-optimization/110743] Unexpected -ftrivial-auto-var-init=pattern behavior with partial bitfields

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-07-20
             Blocks|                            |24639

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
We interestingly see

  <bb 2> :
  op = .DEFERRED_INIT (24, 1, &"op"[0]);
  _1 = MEM <long int> [(struct spi_mem_op *)&op];
  _2 = _1 & 1;
  MEM <long int> [(struct spi_mem_op *)&op] = _2;
  _3 = MEM <long int> [(struct spi_mem_op *)&op + 8B];
  _4 = _3 & 1;
  MEM <long int> [(struct spi_mem_op *)&op + 8B] = _4;
  spi_nor_read_any_reg (&op);
  op ={v} {CLOBBER(eol)};
  return;

which is done by __builtin_clear_padding which we insert during gimplification:

void s25fs256t_post_bfpt_fixup_nor ()
{
  struct spi_mem_op op;

  try
    {
      op = .DEFERRED_INIT (24, 1, &"op"[0]);
      __builtin_clear_padding (&op, 1B);
      spi_nor_read_any_reg (&op);
    }
  finally
    {
      op = {CLOBBER(eol)};
    }
}

I'm not sure why we do it this way.  I wonder why we don't diagnose this at
-O0.

Note RTL expansion of .DEFERRED_INIT _does_ write to the bitfield padding
so maybe we can avoid doing that in __builtin_clear_padding (with an extra
op?).  Confirmed.

A workaround is to explicitely name the padding thus add int padding : 31, etc.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues