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

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

[mikael at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #31 from Mikael Morin <mikael at gcc dot gnu.org> 2011-02-23 23:08:18 UTC ---
(In reply to comment #25)
> 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?

This is not a module loading problem I think. 
It's true that the two `my_get' functions do conflict in the program namespace.
One does not need to pass by the program namespace to resolve the typebound
call however. 
That is, the gfc_typebound_proc.u.specific field should be a gfc_symbol, not a
gfc_symtree. 
This way, even if that gfc_symbol is not accessible through a gfc_symtree in
the program namespace, it is loaded anyway (and gets a unique symtree but this
is an implementation detail) because it is needed in the gfc_typebound_proc
struct. 

That being said, I suppose there is a reason for it to be a gfc_symtree, and
not a gfc_symbol.

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

[mikael at gcc dot gnu.org]

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

--- Comment #32 from Mikael Morin <mikael at gcc dot gnu.org> 2011-02-24 22:04:52 UTC ---
Created attachment 23460
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23460
hack implementing comment 31

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

[mikael at gcc dot gnu.org]

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

--- Comment #33 from Mikael Morin <mikael at gcc dot gnu.org> 2011-02-24 23:57:24 UTC ---
One should also look at related bugs PR45836 and pr45900.

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

[mikael at gcc dot gnu.org]

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

--- Comment #34 from Mikael Morin <mikael at gcc dot gnu.org> 2011-03-01 16:26:53 UTC ---
The hack in comment 32 compiles correctly comment 24, but rejects the following
variant (with the type-bound call in a subroutine) with:

  use mod2
          1
Error: Name 'my_get' at (1) is an ambiguous reference to 'my_get' from module
'mod2'



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 call_get
  contains
  subroutine call_get
    call a%get()
  end subroutine call_get
end


The reason is that the following code in resolve_call reloads the procedure
symbol from the current namespace. This could be disabled with a flag, but it
would just make the hack uglier.

  if (csym && gfc_current_ns->parent && csym->ns != gfc_current_ns)
    {
      gfc_symtree *st;
      gfc_find_sym_tree (csym->name, gfc_current_ns, 1, &st);
      sym = st ? st->n.sym : NULL;
      if (sym && csym != sym
          && sym->ns == gfc_current_ns
          && sym->attr.flavor == FL_PROCEDURE
          && sym->attr.contained)
    {
      sym->refs++;
      if (csym->attr.generic)
        c->symtree->n.sym = sym;
      else
        c->symtree = st;
      csym = c->symtree->n.sym;
    }
    }

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

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.0                       |4.6.1

--- Comment #35 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-25 19:53:08 UTC ---
GCC 4.6.0 is being released, adjusting target milestone.

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.1                       |---

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

[mikael at gcc dot gnu.org]

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

--- Comment #36 from Mikael Morin <mikael at gcc dot gnu.org> 2013-01-06 15:50:19 UTC ---
Author: mikael
Date: Sun Jan  6 15:50:09 2013
New Revision: 194949

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194949
Log:
    PR fortran/42769
    PR fortran/45836
    PR fortran/45900
    * module.c (read_module): Don't reuse local symtree if the associated
    symbol isn't exactly the one wanted.  Don't reuse local symtree if it is
    ambiguous.
    * resolve.c (resolve_call): Use symtree's name instead of symbol's to
    lookup the symtree.

    PR fortran/42769
    PR fortran/45836
    PR fortran/45900
    * gfortran.dg/use_23.f90: New test.
    * gfortran.dg/use_24.f90: New test.
    * gfortran.dg/use_25.f90: New test.
    * gfortran.dg/use_26.f90: New test.
    * gfortran.dg/use_27.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/use_23.f90
    trunk/gcc/testsuite/gfortran.dg/use_24.f90
    trunk/gcc/testsuite/gfortran.dg/use_25.f90
    trunk/gcc/testsuite/gfortran.dg/use_26.f90
    trunk/gcc/testsuite/gfortran.dg/use_27.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/module.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog

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

[mikael at gcc dot gnu.org]

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

--- Comment #37 from Mikael Morin <mikael at gcc dot gnu.org> 2013-01-08 19:42:47 UTC ---
Author: mikael
Date: Tue Jan  8 19:42:38 2013
New Revision: 195031

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195031
Log:
    PR fortran/42769
    PR fortran/45836
    PR fortran/45900
    * module.c (read_module): Don't reuse local symtree if the associated
    symbol isn't exactly the one wanted.  Don't reuse local symtree if it is
    ambiguous.
    * resolve.c (resolve_call): Use symtree's name instead of symbol's to
    lookup the symtree.

    PR fortran/42769
    PR fortran/45836
    PR fortran/45900
    * gfortran.dg/use_23.f90: New test.
    * gfortran.dg/use_24.f90: New test.
    * gfortran.dg/use_25.f90: New test.
    * gfortran.dg/use_26.f90: New test.
    * gfortran.dg/use_27.f90: New test.


Added:
    branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_23.f90
    branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_24.f90
    branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_25.f90
    branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_26.f90
    branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_27.f90
Modified:
    branches/gcc-4_7-branch/gcc/fortran/ChangeLog
    branches/gcc-4_7-branch/gcc/fortran/module.c
    branches/gcc-4_7-branch/gcc/fortran/resolve.c
    branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

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

[mikael at gcc dot gnu.org]

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

--- Comment #38 from Mikael Morin <mikael at gcc dot gnu.org> 2013-01-08 20:02:00 UTC ---
Author: mikael
Date: Tue Jan  8 20:01:49 2013
New Revision: 195032

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195032
Log:
    PR fortran/42769
    PR fortran/45836
    PR fortran/45900
    * module.c (read_module): Don't reuse local symtree if the associated
    symbol isn't exactly the one wanted.  Don't reuse local symtree if it is
    ambiguous.
    * resolve.c (resolve_call): Use symtree's name instead of symbol's to
    lookup the symtree.

    PR fortran/42769
    PR fortran/45836
    PR fortran/45900
    * gfortran.dg/use_23.f90: New test.
    * gfortran.dg/use_24.f90: New test.
    * gfortran.dg/use_25.f90: New test.
    * gfortran.dg/use_26.f90: New test.
    * gfortran.dg/use_27.f90: New test.


Added:
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_23.f90
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_24.f90
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_25.f90
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_26.f90
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_27.f90
Modified:
    branches/gcc-4_6-branch/gcc/fortran/ChangeLog
    branches/gcc-4_6-branch/gcc/fortran/module.c
    branches/gcc-4_6-branch/gcc/fortran/resolve.c
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

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

[mikael at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.6.4

--- Comment #39 from Mikael Morin <mikael at gcc dot gnu.org> 2013-01-09 14:29:31 UTC ---
Fixed for 4.6.4  4.7.3  4.8.0.
Thanks for the bug report.

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