http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #74 from rguenther at suse dot de <rguenther at suse dot de> 2012-07-30 12:33:01 UTC --- On Mon, 30 Jul 2012, mikael at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 > > --- Comment #73 from Mikael Morin <mikael at gcc dot gnu.org> 2012-07-30 > 12:29:33 UTC --- > (In reply to comment #72) > > > (In reply to comment #63) > > > > That's bogus as TYPE_FIELDS > > > > is supposed to be shared amongst variant types. > > > > > > Then we'll have to revert Micha's recursive restrict work. > > > > I don't think so, it merely has to be fixed. > How so? by making it non-recursive? > For variable to be type compatible for assignment, they shall be variants of > the same type, and thus have the same TYPE_FIELDS. > If they shall have the same TYPE_FIELDS, they shall have the same components, > the same components have the same types, so that one cannot be restrict > qualified. The types should not be variant types ;) (see my hack patch in this or another bug) > > > Is it possible for the front-end to specify alias sets by hand (I mean > > > without > > > relying on the middle-end computing them based on types etc)? > > > > Yes. But that does not work with LTO, > You mean calling the front-end's code does not work at LTO time or the alias > sets are not saved/restored for LTO? LTO re-computes alias-sets based on types. > > nor does it address the original > > issue of supporting INTENT IN/OUT properly. > Ah? Isn't a restricted type variable (resp. component, etc) merely one that > has > its own alias set? So if it works with restrict, it works with alias sets? No, alias-sets and restrict are different beasts. It's important to have the data member restrict qualified for INTENT IN/OUT.
