[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 #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.