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

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

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.