https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98499
--- Comment #10 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #9)
> Thanks for all the detailed analysis and sorry for getting into this late.
>
> > Oh, thank you! Only after many printf() attempts it sunk in that
> > `036t.ealias` is using data from seemingly later `043t.modref1` pass. It is
> > so confusing!
>
> This is because it is an inter-procedural analysis. We compile in
> topological order and propagate info from function to callers.
>
> Here I think poblem is:
>
> void Importer::Importer (struct Importer * const this)
>
> {
>
> struct string * _1;
>
>
>
> <bb 2> :
>
> *this_3(D) ={v} {CLOBBER};
>
> *this_3(D).base_path = dir_name (); [return slot optimization]
>
> return;
>
>
>
> }
>
>
> We get parm 0 flags: direct noescape nodirectescape
>
> While dir_name does:
>
> struct string dir_name ()
>
> {
>
> <bb 2> :
>
> string::string (_2(D));
>
> return _2(D);
>
>
>
> }
> and that gets to
>
> void string::string (struct string * const this)
>
> {
>
> char[16] * _1;
>
>
>
> <bb 2> :
>
> *this_3(D) ={v} {CLOBBER};
>
> _1 = &this_3(D)->_M_local_buf;
>
> *this_3(D)._M_buf = _1;
>
> return;
>
>
>
> }
>
> which indeed conflict with noescape.
>
> So problem here is that return slot optimized variables are behaving kind of
> like parameters. Since modref does not track EAF flags for them I think
> your conservative fix makes sense.
>
> It is also relatively easy to track the EAF flags here, I will try to get
> quick stats on how often this makes difference (and whether we want to add
> trakcing now or next stage1).
Sounds great!
I send a conservative variant of the patch with the test as
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564579.html. I hope I
will not interfere with your possible improvement.
