Hi,
>
> 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.
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...
>
> > 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?
Honza
>
> Jason
