This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Walk pointer_to and reference_to chain in free_lang_data


On Wed, 22 Aug 2018, Jan Hubicka wrote:

> > On Tue, 21 Aug 2018, Jan Hubicka wrote:
> > 
> > > Hi,
> > > extra sanity checking I am going to send in followup patch noticed that we
> > > stream pointer types that was never seen by free_lang_data.  This is because
> > > they are referenced by TYPE_POINTER_TO list and are inserted into the gimple
> > > statements later when we wrap everything in MEM_REF (by make_pointer_type).
> > > 
> > > Bootstrapped/regtested x86_64-linux, OK?
> > 
> > Hmm, but make_pointer_type might as well create new pointer types
> > that didn't exist before - shouldn't those have the same problem
> > (which actually is?)?  Note the pointed-to types are already in the IL,
> 
> I am now clearing TYPE_STUB_DECL to NULL and check that it is NULL later in
> streaming.  There are indeed some other cases where this check triggers.
> 
> Pointer types are not problem because they are created w/o stubs.  Other issues
> I see with this are backend produced structures - gcov, asan and ubsan all
> create structures with non-NULL stubs.  They are DECL_ARTIFICIAL so I am not
> quite sure why we set stubs there.
> 
>   tree type_decl = build_decl (input_location, TYPE_DECL,                       
>                                get_identifier ("__asan_global"), ret);          
>   DECL_IGNORED_P (type_decl) = 1;                                               
>   DECL_ARTIFICIAL (type_decl) = 1;                                              
>   TYPE_FIELDS (ret) = fields[0];                                                
>   TYPE_NAME (ret) = type_decl;                                                  
>   TYPE_STUB_DECL (ret) = type_decl;                                             
> 
> It seems to me that setting TYPE_NAME to identifier node would be easier.

Yeah.  I probably added the DECL_INGORED_P to most of those so indeed
type_decls are somewhat pointless.

> gcov uses finish_builtin_struct which in turn does:
> 
> #if 0 /* not yet, should get fixed properly later */                            
>   TYPE_NAME (type) = make_type_decl (get_identifier (name), type);
> #else
>   TYPE_NAME (type) = build_decl (BUILTINS_LOCATION,
>                                  TYPE_DECL, get_identifier (name), type);
> #endif
>   TYPE_STUB_DECL (type) = TYPE_NAME (type);
> 
> It does not seem to set artificial.  I am not quite sure what to do about
> those.

given gcov has a runtime component with debug info did we intend to
make the compiler-generated part debuggable maybe?

> In any case we should free lang data frontend created pointer types that may
> get back to IL stream.  C++ will give them TYPE_DECL based TYPE_NAMEs that
> we want to translate to identifiers for example.

Ah, yes, that makes sense.  Which means your patch is OK if you reflect
the above in the comment (it's about FE generated pointer types).  We
might also somehow forcefully "collect" unused pointer types from the
chains...

Richard.

> Honza
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]