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.tho...@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-bugzi...@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