This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran, OOP] PR 58185: [4.8/4.9 Regression] ICE when selector in SELECT TYPE is non-polymorphic
- From: Mikael Morin <mikael dot morin at sfr dot fr>
- To: Janus Weil <janus at gcc dot gnu dot org>
- Cc: gfortran <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 22 Aug 2013 13:08:31 +0200
- Subject: Re: [Patch, Fortran, OOP] PR 58185: [4.8/4.9 Regression] ICE when selector in SELECT TYPE is non-polymorphic
- References: <CAKwh3qhRvbWNM9ErqW49pKZH-MxKV8JiM-3vz1bdCiRgbz1vcQ at mail dot gmail dot com> <52152C8C dot 7010103 at sfr dot fr> <CAKwh3qgg5kda+KHOV8MVY-MJ9X-joELY5YwuNtx6UAG_9nt72A at mail dot gmail dot com> <CAKwh3qhFunS82yyYqrfD8SgqXh+aner7KTw_-e7ABUV_CgR=Fw at mail dot gmail dot com>
Le 22/08/2013 12:49, Janus Weil a écrit :
> Hi,
>
>>> Thus the condition should probably be
>>> else if (selector->ts.type == BT_DERIVED) as the BT_CLASS was handled
>>> before? OK with that change (if it works).
>>
>> Good point. And yes, it works.
>>
>> However, on second thought, I wonder why we need to treat the case
>> "selector->ts.type == BT_DERIVED" at all, since the selector in a
>> SELECT TYPE statement is required to be polymorphic (which is being
>> checked later in resolve_select_type). I.e. we weill get an error on
>> the BT_DERIVED case anyway, so I don't see why we need to build a
>> class container at all here (the only reason I could imagine would be
>> something like error recovery).
>>
>> The attached new version is what I'm regtesting right now (with the
>> whole BT_DERIVED branch removed, since it should not be needed). Ok if
>> it succeeds?
>
> It does regtest cleanly. Ok for trunk and 4.8?
>
Yes.