https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #14 from Qing Zhao <qing.zhao at oracle dot com> --- > On Feb 17, 2022, at 1:54 AM, rguenther at suse dot de > <gcc-bugzi...@gcc.gnu.org> wrote: >> >> If padding clearing is exposed too late till RTL expansion, some tree >> optimization will not be able to be applied on the expanded stores? > > Doesn't the same argument apply to .DEFERRED_INIT itself? Dependent > on the .DEFERRED_INIT expansion strathegy the padding clearing might > be unneccessary (for example when using memset())? Yes, because we use memset to initialize auto-var when it’s in memory, we do not insert a call to __builtin_clear_padding to zero initialization. We only insert __builtin_clear_padding to pattern Initialization to set the padding to zeroes. That’s why this bug only exposed with pattern init. > >> the approach to mark the load "MEM" as not needing a warning might be better? > > It's probably a good thing anyway, the 'R' in the RMW cycle isn't really > a use. If it’s not a real use, should we exclude this case from emitting the uninitialized warning directly?
