Bug 42769 - [OOP] ICE in resolve_typebound_procedure
[OOP] ICE in resolve_typebound_procedure
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.5.0
: P5 normal
: 4.6.4
Assigned To: janus
: ice-on-valid-code, patch
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-16 17:00 UTC by Salvatore Filippone
Modified: 2013-01-09 14:29 UTC (History)
7 users (show)

See Also:
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2010-08-23 13:32:36


Attachments
test case (160.47 KB, text/plain)
2010-01-16 17:02 UTC, Salvatore Filippone
Details
hack implementing comment 31 (9.42 KB, patch)
2011-02-24 22:04 UTC, Mikael Morin
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Salvatore Filippone 2010-01-16 17:00:39 UTC
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)
Comment 1 Salvatore Filippone 2010-01-16 17:02:23 UTC
Created attachment 19624 [details]
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.
Comment 2 Salvatore Filippone 2010-01-16 17:05:07 UTC
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). 
Comment 3 H.J. Lu 2010-01-16 17:22:24 UTC
(In reply to comment #1)
> Created an attachment (id=19624) [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
Comment 4 Dominique d'Humieres 2010-01-16 17:39:41 UTC
> 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.
Comment 5 H.J. Lu 2010-01-16 21:04:41 UTC
It is very likely caused by revision :

http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html
Comment 6 Tobias Burnus 2010-01-16 21:46:01 UTC
(Mark as regression (P5); while it was not supported in <4.5, it was working before in 4.5.)
Comment 7 Salvatore Filippone 2010-01-17 08:30:13 UTC
(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... 

Comment 8 janus 2010-01-17 11:59:03 UTC
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 
Comment 9 janus 2010-01-17 20:53:07 UTC
(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?
Comment 10 H.J. Lu 2010-01-17 21:18:43 UTC
(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

Comment 11 H.J. Lu 2010-01-17 21:21:19 UTC
(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]$

Comment 12 janus 2010-01-17 21:29:13 UTC
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 ...
Comment 13 Dominique d'Humieres 2010-01-17 21:31:59 UTC
(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".
Comment 14 janus 2010-01-17 21:34:28 UTC
(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.
Comment 15 janus 2010-01-17 21:58:34 UTC
(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.
Comment 16 Salvatore Filippone 2010-01-22 13:20:07 UTC
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? 
Comment 17 Dominique d'Humieres 2010-03-08 14:57:09 UTC
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)

Comment 18 janus 2010-03-08 15:43:34 UTC
(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.
Comment 19 Dominique d'Humieres 2010-03-08 15:49:09 UTC
(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?
Comment 20 janus 2010-03-08 15:50:03 UTC
(In reply to comment #18)
> I will open a new PR for this.

This is now PR 43291.
Comment 21 Richard Biener 2010-04-06 11:20:45 UTC
GCC 4.5.0 is being released.  Deferring to 4.5.1.
Comment 22 Daniel Franke 2010-05-13 20:44:12 UTC
Janus, is there something left to do here?
If yes, are summary and keywords still appropriate?
Comment 23 janus 2010-05-14 11:53:24 UTC
(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
Comment 24 janus 2010-06-11 21:33:20 UTC
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)".
Comment 25 janus 2010-06-11 22:16:40 UTC
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?
Comment 26 janus 2010-08-13 17:28:59 UTC
cf. also PR45271
Comment 27 janus 2010-08-23 13:25:54 UTC
(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
Comment 28 janus 2010-08-23 13:32:36 UTC
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);

Comment 29 janus 2010-08-29 21:29:53 UTC
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

Comment 30 janus 2010-08-29 21:36:16 UTC
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)
Comment 31 Mikael Morin 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.
Comment 32 Mikael Morin 2011-02-24 22:04:52 UTC
Created attachment 23460 [details]
hack implementing comment 31
Comment 33 Mikael Morin 2011-02-24 23:57:24 UTC
One should also look at related bugs PR45836 and pr45900.
Comment 34 Mikael Morin 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;
	}
    }
Comment 35 Jakub Jelinek 2011-03-25 19:53:08 UTC
GCC 4.6.0 is being released, adjusting target milestone.
Comment 36 Mikael Morin 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
Comment 37 Mikael Morin 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
Comment 38 Mikael Morin 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
Comment 39 Mikael Morin 2013-01-09 14:29:31 UTC
Fixed for 4.6.4  4.7.3  4.8.0.
Thanks for the bug report.