[Bug tree-optimization/98499] [11 Regression] Possibly bad std::string initialization in constructors

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

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

--- Comment #6 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> Possibly in discovering pure/constness.  See uses of
> gimple_call_return_slot_opt_p in tree-ssa-structalias.c

Aha, that's useful!

Trying to understand the problem better myself: `-fdump-tree-all` has seemingly
relevant `036t.ealias` that precedes breaking `037t.fre1`.

I assume `036t.ealias` analyses individual functions locally and does not take
into account other details, thus main() analysis should be enough:

```
...
Points-to sets

ANYTHING = { ANYTHING }
ESCAPED = { ESCAPED NONLOCAL }
NONLOCAL = { ESCAPED NONLOCAL }
STOREDANYTHING = { }
INTEGER = { ANYTHING }
_ZN8ImporterC1Ev = { }
imp.0+64 = { ESCAPED NONLOCAL } same as _6
imp.64+8 = { ESCAPED NONLOCAL }
__builtin_trap = { }
main = { }
CALLUSED(9) = { ESCAPED NONLOCAL imp.0+64 imp.64+8 } same as callarg(11)
CALLCLOBBERED(10) = { ESCAPED NONLOCAL imp.0+64 imp.64+8 } same as callarg(11)
callarg(11) = { ESCAPED NONLOCAL imp.0+64 imp.64+8 }
_6 = { ESCAPED NONLOCAL }


Alias information for int main()

Aliased symbols

imp, UID D.2146, struct Importer, is addressable

Call clobber information

ESCAPED, points-to non-local, points-to vars: { }

Flow-insensitive points-to information

_6, points-to non-local, points-to escaped, points-to NULL, points-to vars: { }

int main ()
{
  struct Importer imp;
  char * _6;

  <bb 2> :
  Importer::Importer (&imp);
  _6 = MEM[(struct string *)&imp]._M_buf;
  if (&MEM[(struct string *)&imp]._M_local_buf != _6)
    goto <bb 3>; [0.00%]
  else
    goto <bb 4>; [100.00%]

  <bb 3> [count: 0]:
  __builtin_trap ();

  <bb 4> :
  imp ={v} {CLOBBER};
  imp ={v} {CLOBBER};
  return 0;
}
```

I think this looks correct. As I understand we care about a few things in the
analysis here:
1. imp.0+64 and _6 both point to the same flow-insensitive classes (both are
ESCAPED NONLOCAL)
2. imp.0+64 and _6 both point to the same field in flow-sensitive analysis
(both do according to `imp.0+64 = { ESCAPED NONLOCAL } same as _6`.

I don't see problems here.

Mechanically looking at incorrect gcc's decision for `imp.0+64 != _6`:

  ptrs_compare_unequal(
    ptr1 = &MEM[(struct string *)&imp]._M_local_buf,
    ptr2 = _6
  )

returns `TRUE` because

  pt_solution_includes(
    info = ptr2->pt,
    obj1 = imp
  )

returns `FALSE`. That seems to be a bug.

Do arguments to `pt_solution_includes` look correct so far? Does it try to
answer "could _6 point at any field of 'imp' type"?