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

[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

[...@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
[...@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)
[...@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  for instructions.
[...@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)
[...@gnu-34 rrs]$


-- 


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

[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

[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

[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

[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