[Bug sanitizer/113214] false-positive -Wstringop-overflow warning with thread sanitizer

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think the reason for the warning is fre5 optimizing
   _21 = &MEM[(struct xe_gt *)uc_8(D) + -2072B].tile;
...
-  _20 = uc_8(D) + 18446744073709549544;
-  _2 = _20 + _19;
+  _2 = _21 + _19;
...
   _5 = _4 * 4;
   _6 = _2 + _5;
...
   MEM <uint128_t> [(char * {ref-all})_6] = _13;
and the -Wstringop-overflow warning stuff (done during the strlen pass)
considering it then to be access into the tile member rather than anywhere into
the structure.

Sure, if one writes:
void foo (struct xe_gt *p, int i) { uint128_t *q = (uint128_t *) &p->tile; q +=
i; *q = 0; }
in the source, then it will be UB not just because of the most likely aliasing
violation, but also because the pointer in some kind of Martin's strict reading
is just to the particular element rather than whole structure.
But 
void baz (struct xe_tile **);
void bar (struct xe_gt *p, int i) { baz (&p->tile); uint128_t *q = (uint128_t
*) p; q += i; *q = 0; }
should be fine.
The reason it doesn't trigger without -fsanitize=thread is that then nothing
takes address of the &(uc + cst)->tile in that case, it is just read, so there
is nothing to CSE.
Before IPA we try to maintain what the address taking refers to exactly for
builtin {,dynamic} object size 1/3 modes, but afterwards such distinctions are
lost.