This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/62044] [4.8/4.9 Regression] ICE in USE statement with RENAME for extended derived type
- From: "paul.richard.thomas at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 26 Jan 2015 19:51:18 +0000
- Subject: [Bug fortran/62044] [4.8/4.9 Regression] ICE in USE statement with RENAME for extended derived type
- Auto-submitted: auto-generated
- References: <bug-62044-4 at http dot gcc dot gnu dot org/bugzilla/>
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