https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #9 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #8) > Well, for the .DEFERRED_INIT case if the var ends up in memory, I really > don't see the point in any clear_padding, .DEFERRED_INIT expansion should > just initialize the whole DECL_RTL MEM_P slot with the pattern it wants, > trying to initialize only the non-padding bits and then only the padding > bits next to each other is a waste of CPU cycles. __builtin_clear_padding is ONLY emitted for pattern init to set the paddings to zero. for zero init, the .DEFERRED_INIT expansion should block set all the memory to zero already. no __builtin_clear_padding is added for zero init. that's the reason why this bug is only exposed with -ftrivial-auto-var-init=pattern