[Bug middle-end/123801] [12/13/14/15/16 Regression] Wstringop-overflow false positive since r12-4240

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
  vectp.7_8 = &probe_144795_l.0_1->D.4608.D.4603.__tmp10;
  MEM <vector(2) int> [(union  *)probe_144795_l.0_1 + 8B] = { 0, 0 };
  # DEBUG BEGIN_STMT
  strlcpy (vectp.7_8, in_6(D), 8); [tail call]

But it is not the vectorizer that is causing the issue really.
Before fre5 we have:
```
  vectp.7_8 = &probe_144795_l.0_1->D.4608.D.4603.__tmp10;
  MEM <vector(2) int> [(union  *)vectp.7_8] = { 0, 0 };
  # DEBUG BEGIN_STMT
  _2 = &probe_144795_l.0_1->D.4608.D.4607.__tmp16;
  strlcpy (_2, in_6(D), 8);
```
Which looks correct.

And then fre5 does:
  probe_144795_l.0_1 = probe_144795_l;
  vectp.7_8 = &probe_144795_l.0_1->D.4608.D.4603.__tmp10;
  MEM <vector(2) int> [(union  *)vectp.7_8] = { 0, 0 };
  # DEBUG BEGIN_STMT
  strlcpy (vectp.7_8, in_6(D), 8);

Which is also correct due to &probe_144795_l.0_1->D.4608.D.4603.__tmp10 and
&probe_144795_l.0_1->D.4608.D.4607.__tmp16 being the same value except guess
what waccess needs the __tmp16  variant.