[Bug tree-optimization/101061] tree-vrp misoptimization on skylake+ using union-based aliasing

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
On June 15, 2021 4:27:37 PM GMT+02:00, "alexander.grund@tu-dresden.de"
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
>
>--- Comment #6 from Alexander Grund <alexander.grund@tu-dresden.de> ---
>Oh and for completeness: The same applies to the following union,
>doesn't it?
>I.e. given this:
>
>struct TF_TString_Raw {
>  uint8_t raw[24];
>};
>struct TF_TString_Small {
>  uint8_t size;
>  char str[23];
>};
>struct TF_TString_Large { 
>  size_t size;
>  size_t cap;
>  char *ptr;
>};
>union{
>    TF_TString_Raw raw;
>    TF_TString_Small smll;
>    TF_TString_Large large;
>} x;  
>
>it is not allowed to access x.raw.raw[0] AND then x.large.size (not
>even a
>common initial subsequence) but also not x.raw.raw[0] AND then
>x.small.size
>(maybe a common sequence, not sure about the array, but not implemented
>in GCC)

Note that when the union type is visible in the access path then GCC allows
punning without further restrictions. Thus the accesses as written above are
OK. What is not OK is mixed accesses via pointers to the small/large/base
aggregate types. What is OK is accesses via an effective character type
(uint8_t is usually as implementation detail, not sure if by the standard),
thus char *