http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #36 from Mikael Morin <mikael at gcc dot gnu.org> 2011-01-21 22:54:53 UTC --- (In reply to comment #34) > Yep, that's what I figured eventually :) The question now is if for: > > -------------------------- > type bar > integer :: a > end type bar > type(bar), pointer :: b > type(bar) :: c > -------------------------- > > 'b' and 'c' should have the same type. In other words > should "type(bar),pointer" be a different type vs "type(bar)" already in the > frontend representation for types, or not? If they would be they wouldn't > have shared components and we would be free to set attributes as we like. > > Not knowing much about the several engineering decisions taken while > developing the frontend _I_ personally would have done it this way. Alas, > no cake for me :) Well, the current scheme is in line with how the standard is meant: entities of the same type can have or not the target attribute; in other words attributes are orthogonal to the type. This doesn't fit the middle-end but having it fit the middle-end would lead to the reverse problem : every time we find two objects of different type, we would have to look for variants to check if the objects are indeed of different type or only of different variants (and thus compatible). Personally, I would put the fix in the middle-end (which doesn't mean there is nothing to do on the front-end side). Instead of having the C type-compatibility rules hardcoded in the middle-end, have some relaxed rules: two objects are type-compatible iff all of their sub-components are type compatible. I guess no one wants to see the hack in his own area. > > So, some guidance by the frontend maintainers would be welcome which path > I should take. Making it more the above suggestion, or really going > with the two backend_decls per entity? (what I'm worried about with the > two backend_decls is, what in one year we find other reasons why some > attributes need to be different from the base case, then we already need > four backend_delcs) That's a valid concern. The following attributes are recursive like TARGET: ASYNCHRONOUS, INTENT, PROTECTED, VOLATILE Of those, INTENT and VOLATILE appear in the middle-end type (and TARGET of course). For ASYNCHRONOUS I don't know. (In reply to comment #35) > Created attachment 23047 [details] > possible patch > > So, this is my current version. I'm creating a different type for top-level > symbols that are attr.pointer. Further I'm checking the accessed FIELD_DECLs > for compatibility with the parent type. If they are not, I explicitely > search the parent type for a same-named FIELD_DECL (which by construction > must exist and match). I cache this result in a new field of components. > In this way we could theoretically also support a number of other different > record types without having to add new backend_decl fields for each > combination (we would merely add a linear number of more cache entries, > in the hope that the program author is not in fact making use of all such > combinations). > I'll look at it tomorrow.
