[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject

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

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 35073
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35073&action=edit
WIP patch

So, on top of what you've committed, here is my unfinished attempt to disable
for __bos undesirable transformations.  On the:
int
main ()
{
  struct A { char buf1[9]; char buf2[1]; } a;
  char *p = a.buf1;
  char *q = p + 1;
  char *r = q + 4;
  char *t = r - 1;
  strcpy (t, str1 + 5);
  return 0;
}
main of this PRs testcase, the match.pd snippet doesn't work (genmatch thinks
ADDR_EXPR operand must be a SSA_NAME, where that is not valid gimple), we end
up with
  q_2 = &a.buf1 + 1;
  t_4 = &MEM[(void *)q_2 + 3B];
which would be better expressed as
  t_4 = &a.buf1 + 4;
and then FRE folds that into:
  t_4 = &MEM[(void *)&a + 4B];
so if we went this way, we'd need to change genmatch to handle ADDR_EXPRs
specially, and FRE to avoid forwarding into &MEM if that would lose info.

Or, as discussed on IRC we can consider MEM_REFs where first operand isn't just
SSA_NAME or ADDR_EXPR of a decl, but allow also ADDR_EXPR of
handled_component_p (with base being a decl or MEM_REF with SSA_NAME first
operand).

Or add a new tree code, like OFFSETTED_ADDR_EXPR which would be like ADDR_EXPR,
but with integer offset address to the ADDR_EXPR.