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
