[Bug fortran/62044] [4.8/4.9 Regression] ICE in USE statement with RENAME for extended derived type

["paul.richard.thomas at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044

--- Comment #12 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
Dear All,

As I just said on #gfortran, the previous explanation is wrong. The
problem is that, for the mold= case with no default initializer, the
code->expr winds up being NULL. This fixes it and is being regtested:

Index: /svn/trunk/gcc/fortran/resolve.c
===================================================================
*** /svn/trunk/gcc/fortran/resolve.c    (revision 220097)
--- /svn/trunk/gcc/fortran/resolve.c    (working copy)
*************** resolve_allocate_expr (gfc_expr *e, gfc_
*** 6995,7003 ****
      {
        /* Default initialization via MOLD (non-polymorphic).  */
        gfc_expr *rhs = gfc_default_initializer (&code->expr3->ts);
!       gfc_resolve_expr (rhs);
!       gfc_free_expr (code->expr3);
!       code->expr3 = rhs;
      }

    if (e->ts.type == BT_CLASS && !unlimited && !UNLIMITED_POLY (code->expr3))
--- 6995,7006 ----
      {
        /* Default initialization via MOLD (non-polymorphic).  */
        gfc_expr *rhs = gfc_default_initializer (&code->expr3->ts);
!       if (rhs != NULL)
!     {
!       gfc_resolve_expr (rhs);
!       gfc_free_expr (code->expr3);
!       code->expr3 = rhs;
!     }
      }

    if (e->ts.type == BT_CLASS && !unlimited && !UNLIMITED_POLY (code->expr3))

If it regtests OK, I intend to commit right away as obvious. I guess
that for this completely stupid bug, I should backport to 4.9 at
least?

Cheers

Paul


On 26 January 2015 at 18:19, Paul Richard Thomas
<paul.richard.thomas@gmail.com> wrote:
> Dear Dominique,
>
> For some reason, the hash values are different in the vtable and the
> TYPE IS. I had always worried that that we would have different names
> giving the same hash sometime but not that the same name would give a
> different hash!
>
> The 'other brand'  gives the correct result.
>
> Thanks for the testcase!
>
> Paul
>
> On 26 January 2015 at 11:55, dominiq at lps dot ens.fr
> <gcc-bugzilla@gcc.gnu.org> wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
>>
>> --- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
>>> The following, which works OK with another brand, selects the "wrong type"
>>> with trunk. 4.9 still segfaults. Without the use rename, 4.9 runs and gives
>>> the wrong result.
>>
>> The following test without module also selects the "wrong type" when compiled
>> with 4.8 up to 5.0
>>
>>   implicit none
>>   type, abstract :: GridImageSiloTemplate
>>   end type GridImageSiloTemplate
>>
>>   type, extends ( GridImageSiloTemplate ) :: &
>>     UnstructuredGridImageSiloForm
>>   end type UnstructuredGridImageSiloForm
>>
>>   call foo
>> contains
>>   subroutine foo
>>     class (GridImageSiloTemplate), allocatable :: a
>>     type (UnstructuredGridImageSiloForm) :: b
>>     allocate (a, mold = b)
>>     select type (a)
>>       type is (UnstructuredGridImageSiloForm)
>>         print *, "correct type selected"
>>       class default
>>         print *, "wrong type"
>>     end select
>>   end subroutine
>> end
>>
>> --
>> You are receiving this mail because:
>> You are on the CC list for the bug.
>
>
>
> --
> Outside of a dog, a book is a man's best friend. Inside of a dog it's
> too dark to read.
>
> Groucho Marx