https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92486
--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 14 Nov 2019, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92486 > > Martin Sebor <msebor at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |msebor at gcc dot gnu.org > > --- Comment #8 from Martin Sebor <msebor at gcc dot gnu.org> --- > Whether memcpy needs to preserve the value of padding bits is debatable (and > has been debated in WG14 for a couple of decades now). The value of padding > bits is described as unspecified, and an unspecified value is described as a > "valid value of the relevant type where this International Standard imposes no > requirements on which value is chosen in any instance." The "chosen in any > instance" has been interpreted as permitting the observed value to change from > one read to another. Examples of this effect are in DR #260 and DR #451. > Although they deal with uninitialized objects whose value is indeterminate, > since objects of types like char have no trap representation, their > uninitialized and indeterminate value is simply unspecified, same as that of > padding bits. Note within GIMPLE it's difficult to 1:1 apply such rules since we usually do not know the effective type of the memory object we are about to scalarize (that is, GIMPLE assumes even C has placement new and even plain decls are just "storage")
