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

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

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Sergei Trofimovich from comment #6)
> (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:

Well - it does take into account fnspecs derived by modref analysis for
Importer::Importer - specifically ...

> ```
> ...
> 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 }

the above shows we do not consider 'imp' to escape, and thus

> _6 = { ESCAPED NONLOCAL }

_6 does not point to 'imp'.

Relevant parts of handle_rhs_call are probably

      /* As we compute ESCAPED context-insensitive we do not gain
         any precision with just EAF_NOCLOBBER but not EAF_NOESCAPE
         set.  The argument would still get clobbered through the
         escape solution.  */
      if ((flags & EAF_NOCLOBBER)
           && (flags & (EAF_NOESCAPE | EAF_NODIRECTESCAPE)))
        {
...

specifically lines

          if (!(flags & (EAF_NOESCAPE | EAF_DIRECT)))
            make_indirect_escape_constraint (tem);

probably do not trigger because of the invalid modref analysis.  I suggest
to look at the early modref pass dump (it's after FRE but still applies
to callers)

> 
> 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"?