http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #37 from rguenther at suse dot de <rguenther at suse dot de> 2011-01-24 09:41:28 UTC --- On Fri, 21 Jan 2011, mikael at gcc dot gnu.org wrote: > 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. That's what we do ;) And void * restrict is not compatible with void *. So you get the ICE. Richard.
