[Bug fortran/62044] New: ICE in USE statement with RENAME for extended derived type

[Bug fortran/62044] New: ICE in USE statement with RENAME for extended derived type

[reubendb at gmail dot com]

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

            Bug ID: 62044
           Summary: ICE in USE statement with RENAME for extended derived
                    type
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: reubendb at gmail dot com

Hello,
I am getting an internal compiler error with the following code when using
RENAME list of USE statement with extended derived type. The following reduced
source code reproduce the issue:

$ cat GridImageSilo_Template.f90 
module GridImageSilo_Template
  implicit none
  private
  type, public, abstract :: GridImageSiloTemplate
  end type GridImageSiloTemplate
end module GridImageSilo_Template

$ cat UnstructuredGridImageSilo_Form.f90 
module UnstructuredGridImageSilo_Form
  use GridImageSilo_Template
  implicit none
  private
  type, public, extends ( GridImageSiloTemplate ) :: &
    UnstructuredGridImageSiloForm
  end type UnstructuredGridImageSiloForm
end module UnstructuredGridImageSilo_Form

$ cat UnstructuredGridImages.f90 
module UnstructuredGridImages
  use UnstructuredGridImageSilo_Form, &
        UnstructuredGridImageForm => UnstructuredGridImageSiloForm
end module UnstructuredGridImages

$ cat FileSystem.f90 
module FileSystem
  use UnstructuredGridImages
end module FileSystem

And if I compile them in order:
$ gfortran -c GridImageSilo_Template.f90
$ gfortran -c UnstructuredGridImageSilo_Form.f90 
$ gfortran -c UnstructuredGridImages.f90 
$ gfortran -c FileSystem.f90 
f951: internal compiler error: Segmentation fault
0xa3184f crash_signal
        ../../gcc_trunk/gcc/toplev.c:337
0x5a5cf8 load_derived_extensions
        ../../gcc_trunk/gcc/fortran/module.c:4578
0x5a5cf8 read_module
        ../../gcc_trunk/gcc/fortran/module.c:5229
0x5a5cf8 gfc_use_module
        ../../gcc_trunk/gcc/fortran/module.c:6868
0x5a7586 gfc_use_modules()
        ../../gcc_trunk/gcc/fortran/module.c:6992
0x5af9c7 use_modules
        ../../gcc_trunk/gcc/fortran/parse.c:114
0x5b1f24 decode_statement
        ../../gcc_trunk/gcc/fortran/parse.c:329
0x5b31f9 next_free
        ../../gcc_trunk/gcc/fortran/parse.c:926
0x5b31f9 next_statement
        ../../gcc_trunk/gcc/fortran/parse.c:1121
0x5b3bbb parse_spec
        ../../gcc_trunk/gcc/fortran/parse.c:3065
0x5b6bb3 parse_module
        ../../gcc_trunk/gcc/fortran/parse.c:4757
0x5b6bb3 gfc_parse_file()
        ../../gcc_trunk/gcc/fortran/parse.c:5063
0x5f57d5 gfc_be_parse_file
        ../../gcc_trunk/gcc/fortran/f95-lang.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

Here's gfortran version that I have:
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gcc/4.10/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc_trunk/configure --prefix=/usr/local/gcc/4.10
--enable-languages=c,fortran,c++ --disable-multilib
Thread model: posix
gcc version 4.10.0 20140709 (experimental) (GCC) 

Thanks for looking into this.

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-08-11
      Known to work|                            |4.4.7
            Summary|ICE in USE statement with   |[4.8/4.9/4.10 Regression]
                   |RENAME for extended derived |ICE in USE statement with
                   |type                        |RENAME for extended derived
                   |                            |type
     Ever confirmed|0                           |1
      Known to fail|                            |4.10.0, 4.5.4, 4.8.3, 4.9.1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The code compiles with gfortran 4.4.7, but not with 4.5.4 up to trunk (4.10).

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.4

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
      Known to fail|4.10.0                      |5.0

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.4                       |4.8.5

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.4 has been released.

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

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |damian at sourceryinstitute dot or
                   |                            |g

--- Comment #3 from janus at gcc dot gnu.org ---
*** Bug 64591 has been marked as a duplicate of this bug. ***

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

[mikael at gcc dot gnu.org]

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

--- Comment #4 from Mikael Morin <mikael at gcc dot gnu.org> ---
Author: mikael
Date: Sun Jan 25 20:30:53 2015
New Revision: 220097

URL: https://gcc.gnu.org/viewcvs?rev=220097&root=gcc&view=rev
Log:
fortran/
    PR fortran/62044
    * decl.c (gfc_match_derived_decl): Don't insert a new symtree element.
    * module.c (MOD_VERSION): Bump.
    (write_module): Don't write list of extensions.
    (read_module): Don't jump over list of extensions;
    don't load list of extensions.
    (load_derived_extensions, write_dt_extensions,
     write_derived_extensions): Remove.

testsuite/
    PR fortran/62044
    * gfortran.dg/use_rename_7.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/use_rename_7.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/module.c
    trunk/gcc/testsuite/ChangeLog

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

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |mikael at gcc dot gnu.org
         Resolution|---                         |FIXED
            Summary|[4.8/4.9/5 Regression] ICE  |[4.8/4.9 Regression] ICE in
                   |in USE statement with       |USE statement with RENAME
                   |RENAME for extended derived |for extended derived type
                   |type                        |

--- Comment #5 from Mikael Morin <mikael at gcc dot gnu.org> ---
Fixed for 5.0.
No backport to 4.9/4.8 to preserve module file compatibility.
Closing.

[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]

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

paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paul.richard.thomas at gmail dot c
                   |                            |om

--- Comment #6 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
(In reply to Mikael Morin from comment #4)
> Author: mikael
> Date: Sun Jan 25 20:30:53 2015
> New Revision: 220097
> 
> URL: https://gcc.gnu.org/viewcvs?rev=220097&root=gcc&view=rev
> Log:
> fortran/
> 	PR fortran/62044
> 	* decl.c (gfc_match_derived_decl): Don't insert a new symtree element.
> 	* module.c (MOD_VERSION): Bump.
> 	(write_module): Don't write list of extensions.
> 	(read_module): Don't jump over list of extensions;
> 	don't load list of extensions.
> 	(load_derived_extensions, write_dt_extensions,
> 	 write_derived_extensions): Remove.
> 
> testsuite/
> 	PR fortran/62044
> 	* gfortran.dg/use_rename_7.f90: New.
> 
> 
> Added:
>     trunk/gcc/testsuite/gfortran.dg/use_rename_7.f90
> Modified:
>     trunk/gcc/fortran/ChangeLog
>     trunk/gcc/fortran/decl.c
>     trunk/gcc/fortran/module.c
>     trunk/gcc/testsuite/ChangeLog

Mikael,

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.

module GridImageSilo_Template
  implicit none
!  private
  type, public, abstract :: GridImageSiloTemplate
  end type GridImageSiloTemplate
end module GridImageSilo_Template

module UnstructuredGridImageSilo_Form
  use GridImageSilo_Template
  implicit none
!  private
  type, public, extends ( GridImageSiloTemplate ) :: &
    UnstructuredGridImageSiloForm
  end type UnstructuredGridImageSiloForm
end module UnstructuredGridImageSilo_Form

module UnstructuredGridImages
  use UnstructuredGridImageSilo_Form, &
        UnstructuredGridImageForm => UnstructuredGridImageSiloForm
contains
  subroutine foo
    class (GridImageSiloTemplate), allocatable :: a
    type (UnstructuredGridImageForm) :: b
    allocate (a, mold = b)
    select type (a)
      type is (UnstructuredGridImageForm)
        print *, "correct type selected"
      class default
        print *, "wrong type"
    end select
  end subroutine
end module UnstructuredGridImages

  use UnstructuredGridImages
  call foo
end

I think that it should be reopened as a placeholder. I suspect that removing
the inheritance information is not the right way to go.

Cheers

Paul
>From gcc-bugs-return-474811-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jan 26 06:56:06 2015
Return-Path: <gcc-bugs-return-474811-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14199 invoked by alias); 26 Jan 2015 06:56:04 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 14123 invoked by uid 48); 26 Jan 2015 06:55:55 -0000
From: "bernd.edlinger at hotmail dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/60718] [4.8/4.9 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM
Date: Mon, 26 Jan 2015 06:56:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bernd.edlinger at hotmail dot de
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.5
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60718-4-oscsgsF7cP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60718-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60718-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-01/txt/msg02805.txt.bz2
Content-length: 3264

https://gcc.gnu.org/bugzilla/show_bug.cgi?id`718

--- Comment #22 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Hmm....

I tried to boot-strap a clean gcc 4.9.2 with this patch, but it did not make
it.  Looks like some one spoiled the armv7l-unknown-linux-gnueabihf target.
So it is currently pointless to fix this for 4.9.x and as far as I remember
the situation for 4.8.x was similar.


/home/ed/gnu/gcc-test/./prev-gcc/xg++ -B/home/ed/gnu/gcc-test/./prev-gcc/
-B/home/ed/gnu/arm-linux-gnueabihf/armv7l-unknown-linux-gnueabihf/bin/
-nostdinc++
-B/home/ed/gnu/gcc-test/prev-armv7l-unknown-linux-gnueabihf/libstdc++-v3/src/.libs
-B/home/ed/gnu/gcc-test/prev-armv7l-unknown-linux-gnueabihf/libstdc++-v3/libsupc++/.libs

-I/home/ed/gnu/gcc-test/prev-armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/armv7l-unknown-linux-gnueabihf

-I/home/ed/gnu/gcc-test/prev-armv7l-unknown-linux-gnueabihf/libstdc++-v3/include
 -I/home/ed/gnu/gcc-4.9.2/libstdc++-v3/libsupc++
-L/home/ed/gnu/gcc-test/prev-armv7l-unknown-linux-gnueabihf/libstdc++-v3/src/.libs
-L/home/ed/gnu/gcc-test/prev-armv7l-unknown-linux-gnueabihf/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -gtoggle -DIN_GCC    -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
-I../../gcc-4.9.2/gcc -I../../gcc-4.9.2/gcc/. -I../../gcc-4.9.2/gcc/../include
-I../../gcc-4.9.2/gcc/../libcpp/include -I/home/ed/gnu/gcc-test/./gmp
-I/home/ed/gnu/gcc-4.9.2/gmp -I/home/ed/gnu/gcc-test/./mpfr
-I/home/ed/gnu/gcc-4.9.2/mpfr -I/home/ed/gnu/gcc-4.9.2/mpc/src
-I../../gcc-4.9.2/gcc/../libdecnumber -I../../gcc-4.9.2/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../gcc-4.9.2/gcc/../libbacktrace -DCLOOG_INT_GMP
-I/home/ed/gnu/gcc-test/./cloog/include -I/home/ed/gnu/gcc-4.9.2/cloog/include
-I../gcc-4.9.2/cloog/include  -I/home/ed/gnu/gcc-test/./isl/include
-I/home/ed/gnu/gcc-4.9.2/isl/include  -o haifa-sched.o -MT haifa-sched.o -MMD
-MP -MF ./.deps/haifa-sched.TPo ../../gcc-4.9.2/gcc/haifa-sched.c
../../gcc-4.9.2/gcc/haifa-sched.c: In function 'bool
schedule_block(basic_block_def**, state_t)':
../../gcc-4.9.2/gcc/haifa-sched.c:6507:1: internal compiler error: in
lra_create_copy, at lra.c:1532
 }
 ^
0x951cfb lra_create_copy(int, int, int)
    ../../gcc-4.9.2/gcc/lra.c:1532
0x97bc5f process_bb_lives
    ../../gcc-4.9.2/gcc/lra-lives.c:568
0x97d81f lra_create_live_ranges(bool)
    ../../gcc-4.9.2/gcc/lra-lives.c:1008
0x9544b7 lra(_IO_FILE*)
    ../../gcc-4.9.2/gcc/lra.c:2372
0x8ecd27 do_reload
    ../../gcc-4.9.2/gcc/ira.c:5457
0x8ed193 rest_of_handle_reload
    ../../gcc-4.9.2/gcc/ira.c:5598
0x8ed1ff execute
    ../../gcc-4.9.2/gcc/ira.c:5627
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [haifa-sched.o] Error 1
make[3]: Leaving directory `/home/ed/gnu/gcc-test/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/ed/gnu/gcc-test'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/ed/gnu/gcc-test'
make: *** [all] Error 2

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

[dominiq at lps dot ens.fr]

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

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

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #8 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to paul.richard.thomas@gmail.com from comment #6)
> 
> I think that it should be reopened as a placeholder. 
Alright, let's reopen for the sake of the discussion

> I suspect that removing
> the inheritance information is not the right way to go.
> 
I should have explained better.
I removed code that was touching
some_derived_type_symbol->f2k_derived->sym_root, which was never used.
The inheritance information is still present, through the type of the first
component of an extended type.

I don't think it is related to the patch I committed, because 4.9 also gives
the wrong result.

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

[mikael at gcc dot gnu.org]

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

--- Comment #9 from Mikael Morin <mikael at gcc dot gnu.org> ---
Created attachment 34571
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34571&action=edit
segregate derived type namespaces from regular namespaces

To convince yourself that sym_root fields are never used in derived type
namespaces, here is a patch that gives a type without sym_root field to
f2k_derived.  It passes bootstrapping.

[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]

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

--- Comment #10 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
Hi Mikael,

Yes, you will see from my comment on the PR that I had come to the
same conclusion. However, rather than take PR62044 as a place holder,
I will open a new PR. Thanks for the information about the derived
type namespaces. Originally they were added with precisely this in
mind (and in fact?) but they seem to have fallen into disuse (or
not!).

Cheers

Paul

On 26 January 2015 at 13:11, mikael at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044
>
> --- Comment #9 from Mikael Morin <mikael at gcc dot gnu.org> ---
> Created attachment 34571
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34571&action=edit
> segregate derived type namespaces from regular namespaces
>
> To convince yourself that sym_root fields are never used in derived type
> namespaces, here is a patch that gives a type without sym_root field to
> f2k_derived.  It passes bootstrapping.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[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]

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

--- Comment #11 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
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.

[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]

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

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

[damian at sourceryinstitute dot org]

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

--- Comment #13 from Damian Rouson <damian at sourceryinstitute dot org> ---
Paul,

In case it matters, I reported a duplicate of this bug that I isolated from
code in an open-source NASA project (http://sourceforge.net/projects/pfunit/). 
NASA has expressed a desire for the fix to be backported to 4.9 (and 4.8 if
possible) and I just received approval to fund Andre to work on it in case that
helps.  Please let me know how to proceed.

Damian

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

[damian at sourceryinstitute dot org]

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

--- Comment #14 from Damian Rouson <damian at sourceryinstitute dot org> ---
Correction: the backport I was discussing with Andre was for a different bug. 
Nonetheless, I'm reasonably certain that the fix for this bug would benefit the
aforementioned project (pFUnit) so I'm still interested in this patch being
back ported if that's an option.

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

[pault at gcc dot gnu.org]

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

--- Comment #15 from Paul Thomas <pault at gcc dot gnu.org> ---
Author: pault
Date: Mon Jan 26 21:58:42 2015
New Revision: 220140

URL: https://gcc.gnu.org/viewcvs?rev=220140&root=gcc&view=rev
Log:
2015-01-26  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/62044
    * resolve.c (resolve_allocate_expr): If the default initializer
    is NULL, keep the original MOLD expression so that the correct
    typespec is available.

2015-01-26  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/62044
    * gfortran.dg/allocate_with_mold_1.f90: New test

Added:
    trunk/gcc/testsuite/gfortran.dg/allocate_with_mold_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog

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

[pault at gcc dot gnu.org]

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

--- Comment #16 from Paul Thomas <pault at gcc dot gnu.org> ---
Author: pault
Date: Tue Jan 27 20:54:49 2015
New Revision: 220191

URL: https://gcc.gnu.org/viewcvs?rev=220191&root=gcc&view=rev
Log:
2015-01-27  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/62044
    * resolve.c (resolve_allocate_expr): If the default initializer
    is NULL, keep the original MOLD expression so that the correct
    typespec is available.

2015-01-27  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/62044
    * gfortran.dg/allocate_with_mold_1.f90: New test

Added:
    branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/allocate_with_mold_1.f90
Modified:
    branches/gcc-4_9-branch/gcc/fortran/ChangeLog
    branches/gcc-4_9-branch/gcc/fortran/resolve.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

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

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |pault at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #17 from Paul Thomas <pault at gcc dot gnu.org> ---
The extra bug in mold= allocatations to class entities, exposed by the fix for
this PR, have been fixed on 4.9 and 5.0.

Note that the patch to 4.9 accidentally fixed a load of trailing white space
instances. My editor is very picky about such things :-)

Paul