This is the mail archive of the gcc-bugs@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]

[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment


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.

> 
> > 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?

> 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?


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