On Mon, Jun 24, 2019 at 1:46 PM Jan Hubicka <hubi...@ucw.cz> wrote: > > > > I thought I remembered someone's recent-ish work to treat specially > > types containing a char array, but I'm not finding it now. > > > > > For dynamically allocated memory as well as for stack space after stack > > > slot sharing done in cfgexpand I see this is necessary since we do not > > > preserve any information about placement new. > > > > Yes, untyped memory is different, but I'd think that memory allocated > > through (non-placement) new should also be considered typed. > > I will try to return to this once the code is cleaned up. It would > be quite interesting to make this better defined. > > > > > > I think this is what Richard refers to the code generating clobber > > > statements that is only leaking as-base types to the middle-end visible > > > part of IL and the code in call.c copying base structures. > > > > Right. Is there a better way we could express copying/clobbering only > > part of the object without involving the as-base types? > > I think currently two variants was discussed > 1) use the trik Richard proposed for class a containing fake > subclass a_as_base that has reduced size (i.e. is the AS_BASE type > we have now) and adjust all component_refs accordingly introducing > the view_convert_exprs for outer decls. > > Then clobbers and copies in call.c could use the as_base type.
This is the approach I talked about in 22488, which would also fix the issue of fields with TYPE_SIZE larger than DECL_SIZE. > 2) expose IS_FAKE_BASE_TYPE to middle-end and teach TBAA machinery > about the fact that these are actually same types for everything > it cares about. > > We have similar hacks for Fortran commons already, but of couse > it is not most pretty (I outlined plan in previous mail) > > I would personally lean towards 2 since it will keep all component_refs > in its current natural form and because I know how to implement it :) > I guess it is Richi and yours call to pick variant which is better... Both of these you mention still involve the as-base type. I was wondering if there was a way to avoid that. > > > So at this time basically every C++ type can inter-operate with non-C++. > > > I was thinking of relaxing this somewhat but wanted to see if C++ > > > standard says something here. Things that may be sensible include: > > > 1) perhaps non-POD types especially those with vptr pointers do > > > not need to be inter-operable. > > > > PODs were intended to be the C-compatible subset, yes. > > > > > 2) anonymous namespace types > > > 3) types in namespace > > > > As long as these types don't have explicit language linkage (e.g. > > extern "C"), sure. > > Great, I will add those to my TODOs. > Do we have any way to tell language linkage from middle-end? Not with a flag, currently, but you could look at the mangled name to recognize extern "C". Jason
