[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy

[rguenther at suse dot de]

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")