[Bug fortran/42769] New: ICE in resolve_typebound_procedure

[Bug fortran/42769] New: ICE in resolve_typebound_procedure

[sfilippone at uniroma2 dot it]

The attached source file produces the error with a fresh trunk checkout at
r155958.
[sfilippo@localhost bugr1]$ gfortran -c  psb_s_tools_mod.f90
psb_s_tools_mod.f90:6363:0: internal compiler error: in
resolve_typebound_procedure, at fortran/resolve.c:10023
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[sfilippo@localhost bugr1]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu45/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnu45
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.5.0 20100116 (experimental) (GCC)


-- 
           Summary: ICE  in resolve_typebound_procedure
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sfilippone at uniroma2 dot it
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] ICE in resolve_typebound_procedure

[sfilippone at uniroma2 dot it]

------- Comment #1 from sfilippone at uniroma2 dot it  2010-01-16 17:02 -------
Created an attachment (id=19624)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19624&action=view)
test case

Sorry, the test case is a bit lengthy, but I have no time to reduce it further,
and I'll be away next week. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] ICE in resolve_typebound_procedure

[sfilippone at uniroma2 dot it]

------- Comment #2 from sfilippone at uniroma2 dot it  2010-01-16 17:05 -------
As mentioned in 
http://gcc.gnu.org/ml/fortran/2010-01/msg00075.html
the code works with Nag; it is not supposed to behave correctly at runtime
under gfortran, not until the vtables from fortran-dev are fixed and merged,
but it is supposed to compile correctly, and it did until early December
(sorry, I don't remember more precisely). 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] ICE in resolve_typebound_procedure

[hjl dot tools at gmail dot com]

------- Comment #3 from hjl dot tools at gmail dot com  2010-01-16 17:22 -------
(In reply to comment #1)
> Created an attachment (id=19624)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19624&action=view) [edit]
> test case
> 
> Sorry, the test case is a bit lengthy, but I have no time to reduce it further,
> and I'll be away next week. 
> 

I got

    use psb_error_mod
                     1
Fatal Error: Can't open module file 'psb_error_mod.mod' for reading at (1): No
such file or directory


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl dot tools at gmail dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] ICE in resolve_typebound_procedure

[dominiq at lps dot ens dot fr]

------- Comment #4 from dominiq at lps dot ens dot fr  2010-01-16 17:39 -------
> I got
>
>    use psb_error_mod
>                      1
> Fatal Error: Can't open module file 'psb_error_mod.mod' for reading at (1): No
> such file or directory

Me too! After removing all the 'use psb_error_mod' I get the same error (at
line 9990) with the fortran-exp branch (r155767) and a segmetation fault with
fortran-dev (r155781) and my patched tree.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] ICE in resolve_typebound_procedure

[hjl dot tools at gmail dot com]

------- Comment #5 from hjl dot tools at gmail dot com  2010-01-16 21:04 -------
It is very likely caused by revision :

http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janus at gcc dot gnu dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-01-16 21:04:41
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] [4.5 Regression] ICE in resolve_typebound_procedure

[burnus at gcc dot gnu dot org]

------- Comment #6 from burnus at gcc dot gnu dot org  2010-01-16 21:46 -------
(Mark as regression (P5); while it was not supported in <4.5, it was working
before in 4.5.)


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
           Priority|P3                          |P5
            Summary|ICE  in                     |[4.5 Regression] ICE  in
                   |resolve_typebound_procedure |resolve_typebound_procedure
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] [4.5 Regression] ICE in resolve_typebound_procedure

[sfilippone at uniroma2 dot it]

------- Comment #7 from sfilippone at uniroma2 dot it  2010-01-17 08:30 -------
(In reply to comment #4)
Sorry, I thought I had taken out all those USE instances (as you guessed they
are irrelevant to the bug). 
Rushing to the airport now... 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] [4.5 Regression] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

------- Comment #8 from janus at gcc dot gnu dot org  2010-01-17 11:59 -------
Here is a reduced test case:

module mod1
  type :: t1
  contains
    procedure, nopass :: get => my_get
  end type
contains 
  logical function my_get()
  end function
end module

module mod2
contains 
  logical function my_get()     ! must have the same name as the function in
mod1
  end function
end module

module mod3
contains
  subroutine sub(a)
    use mod2, only: my_get
    use mod1, only: t1          ! order of use statements is important
    type(t1) :: a               ! 'a' must be dummy
  end subroutine
end module


use mod2, only: my_get
use mod3, only: sub             ! order of use statements is important
end 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] [4.5 Regression] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

------- Comment #9 from janus at gcc dot gnu dot org  2010-01-17 20:53 -------
(In reply to comment #5)
> It is very likely caused by revision :
> http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html

Actually I don't see how this bug could be caused by r152526. That patch was
about SELECT TYPE and (ideally) should have no effect on TBPs at all. Also, at
first sight, I don't see anything suspicious in the patch. Is there any
evidence for the above claim?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] [4.5 Regression] ICE in resolve_typebound_procedure

[hjl dot tools at gmail dot com]

------- Comment #10 from hjl dot tools at gmail dot com  2010-01-17 21:18 -------
(In reply to comment #8)
> Here is a reduced test case:
> 
> module mod1
>   type :: t1
>   contains
>     procedure, nopass :: get => my_get
>   end type
> contains 
>   logical function my_get()
>   end function
> end module
> 
> module mod2
> contains 
>   logical function my_get()     ! must have the same name as the function in
> mod1
>   end function
> end module
> 
> module mod3
> contains
>   subroutine sub(a)
>     use mod2, only: my_get
>     use mod1, only: t1          ! order of use statements is important
>     type(t1) :: a               ! 'a' must be dummy
>   end subroutine
> end module
> 
> 
> use mod2, only: my_get
> use mod3, only: sub             ! order of use statements is important
> end 
> 

I got

pr42769-2.f90:14:

mod1
1
Error: Unclassifiable statement at (1)
pr42769-2.f90:21.26:

    use mod2, only: my_get
                          1
Fatal Error: Can't open module file 'mod2.mod' for reading at (1): No such file
or directory


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] [4.5 Regression] ICE in resolve_typebound_procedure

[hjl dot tools at gmail dot com]

------- Comment #11 from hjl dot tools at gmail dot com  2010-01-17 21:21 -------
(In reply to comment #9)
> (In reply to comment #5)
> > It is very likely caused by revision :
> > http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html
> 
> Actually I don't see how this bug could be caused by r152526. That patch was
> about SELECT TYPE and (ideally) should have no effect on TBPs at all. Also, at
> first sight, I don't see anything suspicious in the patch. Is there any
> evidence for the above claim?


With original testcase, removing all "use psb_error_mod", I got

[hjl@gnu-34 rrs]$ /export/gnu/import/rrs/152525/usr/bin/gcc  -S pr42769.f90
pr42769.f90:1309.36:

    class is (psb_s_base_sparse_mat)
                                    1
Error: CLASS IS specification at (1) is not yet supported
pr42769.f90:1310.22:

      call b%cp_to_coo(tmp,info)
                      1
Error: 'cp_to_coo' at (1) is not a member of the 'psb_base_sparse_mat'
structure
pr42769.f90:2919.36:

    class is (psb_d_base_sparse_mat)
                                    1
Error: CLASS IS specification at (1) is not yet supported
pr42769.f90:2920.22:

      call b%cp_to_coo(tmp,info)
                      1
Error: 'cp_to_coo' at (1) is not a member of the 'psb_base_sparse_mat'
structure
pr42769.f90:3894.24:

  use psb_d_base_mat_mod
                        1
Fatal Error: Can't open module file 'psb_d_base_mat_mod.mod' for reading at
(1): No such file or directory
[hjl@gnu-34 rrs]$ /export/gnu/import/rrs/152525/usr/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/export/gnu/import/rrs/152525/usr/bin/gcc
COLLECT_LTO_WRAPPER=/export/gnu/import/rrs/152525/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../src/configure --prefix=/export/gnu/import/rrs/152525/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared
--enable-threads=posix --enable-haifa --enable-checking
--enable-languages=c,c++,fortran --with-ppl=/ --with-cloog=/
--disable-bootstrap
Thread model: posix
gcc version 4.5.0 20091007 (experimental) [trunk revision 152525] (GCC)
[hjl@gnu-34 rrs]$ /export/gnu/import/rrs/152526/usr/bin/gcc  -S pr42769.f90
pr42769.f90:1309.36:

    class is (psb_s_base_sparse_mat)
                                    1
Error: CLASS IS specification at (1) is not yet supported
pr42769.f90:180:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[hjl@gnu-34 rrs]$ /export/gnu/import/rrs/152526/usr/bin/gcc  -v
Using built-in specs.
COLLECT_GCC=/export/gnu/import/rrs/152526/usr/bin/gcc
COLLECT_LTO_WRAPPER=/export/gnu/import/rrs/152526/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../src/configure --prefix=/export/gnu/import/rrs/152526/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared
--enable-threads=posix --enable-haifa --enable-checking
--enable-languages=c,c++,fortran --with-ppl=/ --with-cloog=/
--disable-bootstrap
Thread model: posix
gcc version 4.5.0 20091007 (experimental) [trunk revision 152526] (GCC)
[hjl@gnu-34 rrs]$


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] [4.5 Regression] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

------- Comment #12 from janus at gcc dot gnu dot org  2010-01-17 21:29 -------
I'd argue this is not even a regression. Sure, the code in comment #1 fails to
compile with 4.4 since it contains lots of CLASS declarations. But on comment
#8, gfortran 4.4 fails with (almost) the same error:

internal compiler error: in resolve_typebound_procedure, at
fortran/resolve.c:8505

Salvatore, are you sure this worked with 4.5 at some point, or is this sudden
failure rather due to changes in your code?

Daniel, since you were the one who implemented most of the TBP stuff in 4.4,
could you maybe have a look at this? Seems like there is a problem with equal
names in different namespaces ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] [4.5 Regression] ICE in resolve_typebound_procedure

[dominiq at lps dot ens dot fr]

------- Comment #13 from dominiq at lps dot ens dot fr  2010-01-17 21:31 -------
(In reply to comment #10)
> I got
>
> pr42769-2.f90:14:
>
> mod1
> 1
> Error: Unclassifiable statement at (1)

The two lines

>   logical function my_get()     ! must have the same name as the function in
> mod1

have to be merged in a single one: "...!...the function in mod1".


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] [4.5 Regression] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

------- Comment #14 from janus at gcc dot gnu dot org  2010-01-17 21:34 -------
(In reply to comment #10)
> mod1
> 1
> Error: Unclassifiable statement at (1)

Sorry, this is due to a wrapped comment in comment #8. Let's try it again:

module mod1
  type :: t1
  contains
    procedure, nopass :: get => my_get
  end type
contains 
  logical function my_get()
  end function
end module

module mod2
contains 
  logical function my_get()
  end function
end module

module mod3
contains
  subroutine sub(a)
    use mod2, only: my_get
    use mod1, only: t1
    type(t1) :: a
  end subroutine
end module


use mod2, only: my_get
use mod3, only: sub
end 


This fails with the same error message as comment #1 (with "use psb_error_mod"
removed). PLUS, it ICEs also with 4.4. So, no regression.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

------- Comment #15 from janus at gcc dot gnu dot org  2010-01-17 21:58 -------
(In reply to comment #5)
> It is very likely caused by revision :
> http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html

Just for completeness: With trunk r152525 you get the same ICE (with a
different line number) on comment #8/#14:

internal compiler error: in resolve_typebound_procedure, at
fortran/resolve.c:9668

So, r152526 is definitely not the culprit. And this is another hint that this
bug was probably always present in 4.5.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] ICE in resolve_typebound_procedure

[sfilippone at uniroma2 dot it]

------- Comment #16 from sfilippone at uniroma2 dot it  2010-01-22 13:20 -------
I have found a compiled version of the library dating back to Nov. 10, one of
the modules has this header:

GFORTRAN module version '3' created from psb_base_mod.f90 on Tue Nov 10
13:02:06 2009
MD5:4297c507a682f5457f8eb0404ad04766 -- If you edit this, you'll get what you
deserve.


I THINK it was trunk. But anyway, an ICE is an ICE, no? 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] ICE in resolve_typebound_procedure

[dominiq at lps dot ens dot fr]

------- Comment #17 from dominiq at lps dot ens dot fr  2010-03-08 14:57 -------
At revision 157277, I no longer see the ICE, but a bunch of errors:

pr42769.f90:5063.10:

    res = a%a%csnmi()
          1
Error: Type mismatch in argument 'a' at (1); passed
CLASS(psb_d_base_sparse_mat) to CLASS(psb_d_coo_sparse_mat)
pr42769.f90:4292.30:

    if (allocated(a%a)) res = a%a%get_nz_row(idx)
                              1
Error: Type mismatch in argument 'a' at (1); passed
CLASS(psb_d_base_sparse_mat) to CLASS(psb_d_coo_sparse_mat)
pr42769.f90:4279.10:

    res = a%a%get_size()
          1
Error: Type mismatch in argument 'a' at (1); passed
CLASS(psb_d_base_sparse_mat) to CLASS(psb_d_coo_sparse_mat)
pr42769.f90:4265.10:

    res = a%a%get_nzeros()
          1
Error: Type mismatch in argument 'a' at (1); passed
CLASS(psb_d_base_sparse_mat) to CLASS(psb_d_coo_sparse_mat)
pr42769.f90:4075.12:

      res = a%a%get_fmt()
            1
Error: Type mismatch in argument 'a' at (1); passed
CLASS(psb_d_base_sparse_mat) to CLASS(psb_d_coo_sparse_mat)
pr42769.f90:4062.12:

      res = a%a%sizeof()
            1
Error: Type mismatch in argument 'a' at (1); passed
CLASS(psb_d_base_sparse_mat) to CLASS(psb_d_coo_sparse_mat)
pr42769.f90:6279.10:

    res = a%a%csnmi()
          1
Error: Type mismatch in argument 'a' at (1); passed
CLASS(psb_s_base_sparse_mat) to CLASS(psb_s_coo_sparse_mat)
pr42769.f90:5508.30:

    if (allocated(a%a)) res = a%a%get_nz_row(idx)
                              1
Error: Type mismatch in argument 'a' at (1); passed
CLASS(psb_s_base_sparse_mat) to CLASS(psb_s_coo_sparse_mat)
pr42769.f90:5495.10:

    res = a%a%get_size()
          1
Error: Type mismatch in argument 'a' at (1); passed
CLASS(psb_s_base_sparse_mat) to CLASS(psb_s_coo_sparse_mat)
pr42769.f90:5481.10:

    res = a%a%get_nzeros()
          1
Error: Type mismatch in argument 'a' at (1); passed
CLASS(psb_s_base_sparse_mat) to CLASS(psb_s_coo_sparse_mat)
pr42769.f90:5291.12:

      res = a%a%get_fmt()
            1
Error: Type mismatch in argument 'a' at (1); passed
CLASS(psb_s_base_sparse_mat) to CLASS(psb_s_coo_sparse_mat)
pr42769.f90:5278.12:

      res = a%a%sizeof()
            1
Error: Type mismatch in argument 'a' at (1); passed
CLASS(psb_s_base_sparse_mat) to CLASS(psb_s_coo_sparse_mat)
pr42769.f90:6329.19:

  use psb_s_mat_mod
                   1
Fatal Error: Can't open module file 'psb_s_mat_mod.mod' for reading at (1): No
such file or directory

I also get similar errors for pr41685:

pr41685.f90:374.12:

      res = a%a%sizeof()
            1
Error: Type mismatch in argument 'a' at (1); passed CLASS(s_base_sparse_mat) to
CLASS(s_coo_sparse_mat)
pr41685.f90:374.12:

      res = a%a%sizeof()
            1
Error: Type mismatch in argument 'a' at (1); passed CLASS(s_base_sparse_mat) to
CLASS(s_csr_sparse_mat)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

------- Comment #18 from janus at gcc dot gnu dot org  2010-03-08 15:43 -------
(In reply to comment #17)
> At revision 157277, I no longer see the ICE, but a bunch of errors:
> 
> pr42769.f90:5063.10:
> 
>     res = a%a%csnmi()
>           1
> Error: Type mismatch in argument 'a' at (1); passed
> CLASS(psb_d_base_sparse_mat) to CLASS(psb_d_coo_sparse_mat)

Dominique, thanks for noticing. This is surely due to the patch for PR43256
that I committed today. Note that this only happens for comment #1, but not for
comment #8, which still gives the same error as before. I will open a new PR
for this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] ICE in resolve_typebound_procedure

[dominiq at lps dot ens dot fr]

------- Comment #19 from dominiq at lps dot ens dot fr  2010-03-08 15:49 -------
(In reply to comment #18)
> This is surely due to the patch for PR43256 that I committed today. 

Sure!

> Note that this only happens for comment #1, but not for
> comment #8, which still gives the same error as before. 

Confirmed

> I will open a new PR for this.

What about the test in pr41685? Reopen, this new PR or another one?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

------- Comment #20 from janus at gcc dot gnu dot org  2010-03-08 15:50 -------
(In reply to comment #18)
> I will open a new PR for this.

This is now PR 43291.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] ICE in resolve_typebound_procedure

[rguenth at gcc dot gnu dot org]

------- Comment #21 from rguenth at gcc dot gnu dot org  2010-04-06 11:20 -------
GCC 4.5.0 is being released.  Deferring to 4.5.1.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.0                       |4.5.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] ICE in resolve_typebound_procedure

[dfranke at gcc dot gnu dot org]

------- Comment #22 from dfranke at gcc dot gnu dot org  2010-05-13 20:44 -------
Janus, is there something left to do here?
If yes, are summary and keywords still appropriate?


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

------- Comment #23 from janus at gcc dot gnu dot org  2010-05-14 11:53 -------
(In reply to comment #22)
> Janus, is there something left to do here?

Yes, sure. The ICE has not been fixed yet. With 4.6 trunk (r159368) I still get
the same ICE on comment #8/#14:

internal compiler error: in resolve_typebound_procedure, at
fortran/resolve.c:10304


-- 

janus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ICE  in                     |[OOP] ICE  in
                   |resolve_typebound_procedure |resolve_typebound_procedure
   Target Milestone|4.5.1                       |4.6.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

------- Comment #24 from janus at gcc dot gnu dot org  2010-06-11 21:33 -------
Here is a somewhat modified version of comment #14, which compiles but produces
wrong code:

module mod1
  type :: t1
  contains
    procedure, nopass :: get => my_get
  end type
contains 
  subroutine my_get()
    print *,"my_get (mod1)"
  end subroutine
end module

module mod2
contains 
  subroutine my_get()   ! must have the same name as the function in mod1
    print *,"my_get (mod2)"
  end subroutine
end module

  use mod2
  use mod1              ! order of use statements is important
  type(t1) :: a
  call a%get()
end


Output is "my_get (mod2)" while it should be "my_get (mod1)".


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

------- Comment #25 from janus at gcc dot gnu dot org  2010-06-11 22:16 -------
This seems to be a module-loading bug. When reading the specific binding of the
TBP 'get' from 'mod1' (which happens in module.c, mio_typebound_proc), we
expect to get the symbol 'my_get' from 'mod1', but instead we get 'my_get' from
'mod2'.

My knowledge of the module-reading code is not sufficient to see where stuff
goes wrong. Maybe someone else can?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

------- Comment #26 from janus at gcc dot gnu dot org  2010-08-13 17:28 -------
cf. also PR45271


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

------- Comment #27 from janus at gcc dot gnu dot org  2010-08-23 13:25 -------
(In reply to comment #24)
> Here is a somewhat modified version of comment #14, which compiles but produces
> wrong code:

The example in comment #24 contains a statically-resolved TBP call (the pass
object is non-polymorphic). One can construct an analogous version with a
polymorphic TBP call, which also fails:

> module mod1
>   type :: t1
>   contains
>     procedure, nopass :: get => my_get
>   end type
> contains 
>   subroutine my_get()
>     print *,"my_get (mod1)"
>   end subroutine
> end module
> 
> module mod2
> contains 
>   subroutine my_get()   ! must have the same name as the function in mod1
>     print *,"my_get (mod2)"
>   end subroutine
> end module

  use mod2
  use mod1              ! order of use statements is important
  class(t1),allocatable :: a
  allocate(a)
  call a%get()
end


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

------- Comment #28 from janus at gcc dot gnu dot org  2010-08-23 13:32 -------
Comment #27 can be fixed by:


Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c       (revision 163468)
+++ gcc/fortran/resolve.c       (working copy)
@@ -10937,10 +10937,12 @@ error:
   stree->n.tb->error = 1;
 }

+
 static gfc_try
 resolve_typebound_procedures (gfc_symbol* derived)
 {
   int op;
+  gfc_symbol *vtab;

   if (!derived->f2k_derived || !derived->f2k_derived->tb_sym_root)
     return SUCCESS;
@@ -10948,6 +10950,9 @@ resolve_typebound_procedures (gfc_symbol* derived)
   resolve_bindings_derived = derived;
   resolve_bindings_result = SUCCESS;

+  /* Make sure the vtab has been generated.  */
+  vtab = gfc_find_derived_vtab (derived);
+
   if (derived->f2k_derived->tb_sym_root)
     gfc_traverse_symtree (derived->f2k_derived->tb_sym_root,
                          &resolve_typebound_procedure);


-- 

janus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2010-01-16 21:04:41         |2010-08-23 13:32:36
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

------- Comment #29 from janus at gcc dot gnu dot org  2010-08-29 21:29 -------
Subject: Bug 42769

Author: janus
Date: Sun Aug 29 21:29:38 2010
New Revision: 163631

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163631
Log:
2010-08-29  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/42769
        * resolve.c (resolve_structure_cons): For derived types, make sure the
        type has been resolved.
        (resolve_typebound_procedures): Make sure the vtab has been generated.


2010-08-29  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/42769
        * gfortran.dg/dynamic_dispatch_11.f03: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_11.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769

[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure

[janus at gcc dot gnu dot org]

------- Comment #30 from janus at gcc dot gnu dot org  2010-08-29 21:36 -------
r163631 fixes comment #27, but the other stuff still fails:
1) the original test case (comment #1, ICE)
2) the reduced version (comment #8, ICE)
3) the variant in comment #24 (wrong-code)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769