Bug 47601 - [OOP] Internal Error: mio_component_ref(): Component not found
[OOP] Internal Error: mio_component_ref(): Component not found
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.6.0
: P3 normal
: ---
Assigned To: janus
:
: 48428 (view as bug list)
Depends on:
Blocks: 48428
  Show dependency treegraph
 
Reported: 2011-02-03 18:40 UTC by Rich Townsend
Modified: 2011-06-20 02:31 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-02-03 23:12:41


Attachments
Tar archive with source files and Makefile (13.50 KB, application/x-tar)
2011-02-03 18:40 UTC, Rich Townsend
Details
Fixed Makefile (1.08 KB, text/plain)
2011-02-03 19:20 UTC, Rich Townsend
Details
Revised tar archive w/ source & Makefile (15.00 KB, application/x-tar)
2011-02-03 21:17 UTC, Rich Townsend
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rich Townsend 2011-02-03 18:40:38 UTC
Created attachment 23238 [details]
Tar archive with source files and Makefile

The attached code (Makefile included) produces the following error when compiled:

 gyre_lanr_bvp.f90:8.24:

  use gyre_lanr_jacobian
                        1
Internal Error at (1):
mio_component_ref(): Component not found
make: *** [gyre_lanr_bvp.mod] Error 1

This is similar to problems I've been encountering with another code (see pr47456). But in cutting down the attached code to find the simplest possible test case, I've found some pretty strange behavior. 

If I remove the "use gyre_shell" from gyre_lanr_bvp.f90, then the problem goes away. Likewise, if I remove the "public :: interpolate" from gyre_shell.f90 (so that the interpolate() routine remains private), then the problem goes away. This is odd, given that no types or procedures from shell_t are referenced elsewhere in the code.
Comment 1 Rich Townsend 2011-02-03 18:45:47 UTC
(In reply to comment #0)
> This is similar to problems I've been encountering with another code (see
> pr47456). But in cutting down the attached code to find the simplest possible
> test case, I've found some pretty strange behavior. 

Oops, I meant pr47463
Comment 2 Mikael Morin 2011-02-03 18:58:47 UTC
I get:
gmake: *** No rule to make target `gyre_func.mod', needed by `gyre_lanr_discrim.mod'.  Stop.

Something missing ?
Comment 3 Rich Townsend 2011-02-03 19:20:12 UTC
Created attachment 23239 [details]
Fixed Makefile

Removed some broken dependencies from the original Makefile
Comment 4 Mikael Morin 2011-02-03 19:31:07 UTC
gyre_lanr_discrim.f90:6.15:

  use gyre_func
               1
Fatal Error: Can't open module file 'gyre_func.mod' for reading at (1): No such file or directory
Comment 5 Rich Townsend 2011-02-03 21:17:29 UTC
Created attachment 23241 [details]
Revised tar archive w/ source & Makefile

Seems some stuff got left out of the tar file. Here's a new set of source files, plus the (original) Makefile.
Comment 6 Mikael Morin 2011-02-03 21:54:09 UTC
(In reply to comment #5)
> Created attachment 23241 [details]
> Revised tar archive w/ source & Makefile
> 
> Seems some stuff got left out of the tar file. Here's a new set of source
> files, plus the (original) Makefile.

Now it compiles OK: cannot reproduce with either 4.5 or 4.6 :-/
Comment 7 Dominique d'Humieres 2011-02-03 22:13:11 UTC
On x86_64-apple-darwin10.6.0 the test in attachment 23241 [details] compiles with 4.5.2 (r167027) and trunk r162456, but give an ICE 

gyre_lanr_discrim.f90:7.19:

  use gyre_lanr_bvp
                   1
Internal Error at (1):
mio_component_ref(): Component not found

at r166102 and 

gyre_lanr_bvp.f90:8.24:

  use gyre_lanr_jacobian
                        1
Internal Error at (1):
mio_component_ref(): Component not found

at r169809.
Comment 8 janus 2011-02-03 23:12:41 UTC
(In reply to comment #7)
> gyre_lanr_bvp.f90:8.24:
> 
>   use gyre_lanr_jacobian
>                         1
> Internal Error at (1):
> mio_component_ref(): Component not found
> 
> at r169809.

Confirmed on x86_64-apple-darwin10.6.0. Reduced test case:


module gyre_kinds
  implicit none
end module

module gyre_bvp
  type :: bvp_t
  end type
end module

module gyre_jacobian
  type :: jacobian_t
     integer :: n_e
  end type
end module

module gyre_lanr_jacobian
  use gyre_jacobian
  type, extends(jacobian_t) :: lanr_jacobian_t
   contains
     procedure :: eval
  end type
  private
  public :: lanr_jacobian_t
contains
  function eval (this, w) result (A)
    class(lanr_jacobian_t) :: this
    real       :: w,A(this%n_e)
  end function
end module

module gyre_lanr_bvp
  use gyre_lanr_jacobian
end module



This surely is a duplicate of PR47546 (or at least closely related).
Comment 9 janus 2011-03-29 19:12:51 UTC
At r171684, comment #8 works on x86_64-apple-darwin10.7.0. However, the original test case (cf. comment #5) apparently still fails:

gfortran-4.7 -std=f2003 -fbounds-check -fbacktrace -ffpe-trap=invalid,overflow   -c gyre_kinds.f90
gfortran-4.7 -std=f2003 -fbounds-check -fbacktrace -ffpe-trap=invalid,overflow   -c gyre_bvp.f90
gfortran-4.7 -std=f2003 -fbounds-check -fbacktrace -ffpe-trap=invalid,overflow   -c gyre_jacobian.f90
gfortran-4.7 -std=f2003 -fbounds-check -fbacktrace -ffpe-trap=invalid,overflow   -c gyre_shell.f90
gfortran-4.7 -std=f2003 -fbounds-check -fbacktrace -ffpe-trap=invalid,overflow   -c gyre_lanr_jacobian.f90
gfortran-4.7 -std=f2003 -fbounds-check -fbacktrace -ffpe-trap=invalid,overflow   -c gyre_lanr_bvp.f90
gyre_lanr_bvp.f90:5.24:

  use gyre_lanr_jacobian
                        1
Interner Fehler bei (1):
mio_component_ref(): Component not found
Comment 10 Mikael Morin 2011-04-04 12:54:16 UTC
*** Bug 48428 has been marked as a duplicate of this bug. ***
Comment 11 Kris 2011-04-04 13:33:17 UTC
(In reply to comment #10)
> *** Bug 48428 has been marked as a duplicate of this bug. ***

I further reduced the code from bug 48248.  I don't know if this helps, but if you change the size of the a2n vector from something that refers to a component of e to an integer, it goes away.

--

mio_component_ref_error.f90:39.41:

    use elliptical_elements, only : line 
                                         1
Internal Error at (1):
mio_component_ref(): Component not found

--

module type_definitions
  implicit none
  private 
  public ::   ellipse 
         
  type :: matching 
     integer :: n = -999
  end type matching

  type, extends(matching) :: ellipse
  end type ellipse

end module type_definitions

module elliptical_elements
  implicit none
contains
  function line(e) result(a2n)
    use type_definitions, only : ellipse

    type(ellipse), intent(in) :: e
    complex(8), dimension(e%N) :: a2n   ! <- change "e%N" to "10" 
  end function line
end module elliptical_elements

module solution_mod
  implicit none
  private
  public :: matrix_solution
contains
  subroutine matrix_solution(e) 
    use type_definitions, only :  ellipse
    use elliptical_elements, only : line 
    type(ellipse), intent(inout) :: e
    e = line(e)
  end subroutine matrix_solution
end module solution_mod
Comment 12 Rich Townsend 2011-05-26 18:05:35 UTC
Do we have any progress in fixing this one? It's become a showstopper for me, alas!

(Serves me right for starting a number of new, large projects in F2003).
Comment 13 janus 2011-05-26 21:25:30 UTC
Here is a reduced version of comment #11:


module type_definitions
  implicit none
  type :: matching 
     integer :: n = -999
  end type
  type, extends(matching) :: ellipse
  end type
end module type_definitions

module elliptical_elements
  implicit none
contains
  function line(e) result(a2n)
    use type_definitions
    type(ellipse), intent(in) :: e
    complex, dimension(e%N) :: a2n   ! <- change "e%N" to "10" 
  end function line
end module

  use type_definitions
  use elliptical_elements
end


Fails for me on x86_64-unknown-linux-gnu with 4.5, 4.6 and 4.7. Apparently related to type extension.
Comment 14 Rich Townsend 2011-05-26 21:43:27 UTC
> Fails for me on x86_64-unknown-linux-gnu with 4.5, 4.6 and 4.7. Apparently
> related to type extension.

I think the bug can be summarized thus:

*) The error is triggered by USEing a module in which a 'bad' procedure is defined. 
*) A 'bad' procedure is one having
  b) a dummy argument 'foo' which is an extended derived type
  a) another dummy argument 'bar', whose dimension(s) depends on a component of 'foo'
Comment 15 Kris 2011-05-27 03:33:15 UTC
(In reply to comment #14)
> *) The error is triggered by USEing a module in which a 'bad' procedure is
> defined. 
> *) A 'bad' procedure is one having
>   b) a dummy argument 'foo' which is an extended derived type
>   a) another dummy argument 'bar', whose dimension(s) depends on a component of
> 'foo'

I had this bug, but it went away when I verbatim copied the procedure I was USEing and removed the USE statement (not optimal, but ok).  I still have lots of other extended types and no other problems with gfortran -- based on my limited experience, whatever triggers this bug is pretty subtle.
Comment 16 Tobias Burnus 2011-05-28 12:32:11 UTC
(In reply to comment #13)
>   type :: matching 
>      integer :: N = -999
>   end type
>   type, extends(matching) :: ellipse
>   end type

>     type(ellipse), intent(in) :: e
>     complex, dimension(e%N) :: a2n

Thus, when loading the expression, one needs to resolve e%N. One thus calls module.c's mio_component_ref which does (on reading the .mod):

      if (sym->components != NULL && p->u.pointer == NULL)
        {
          /* Symbol already loaded, so search by name.  */
          for (q = sym->components; q; q = q->next)
            if (strcmp (q->name, name) == 0)
              break;

The comparison by name fails for extended types:

(gdb) p sym->components->name
$11 = 0x2aaaacec33b0 "matching"
(gdb) p sym->components->next
$12 = (struct gfc_component *) 0x0

Thus: Not found. However, one has:

(gdb) p sym->attr.extension 
$13 = 1
(gdb) p sym->components->ts.u.derived->name
$14 = 0x2aaaacec33b0 "matching"
(gdb) p sym->components->ts.u.derived->components->name
$15 = 0x2aaaacde3fa8 "n"

Janus, you know type extension better than me. Does one now needs to do:
  if (!p && sym->attr.extension)
    {
      p = search (sym->components->ts.u.derived)
      if (!p && sym->components->ts.u.derived->attr.extension)
        p = search (sym->components->ts.u.derived->...)

or is this the wrong method?
Comment 17 janus 2011-05-28 13:43:23 UTC
(In reply to comment #16)
> Janus, you know type extension better than me. Does one now needs to do:
>   if (!p && sym->attr.extension)
>     {
>       p = search (sym->components->ts.u.derived)
>       if (!p && sym->components->ts.u.derived->attr.extension)
>         p = search (sym->components->ts.u.derived->...)
> 
> or is this the wrong method?

Yes, sounds good. Also that's exactly what 'gfc_find_component' does, so I'd propose the following patch:


Index: gcc/fortran/module.c
===================================================================
--- gcc/fortran/module.c	(revision 174030)
+++ gcc/fortran/module.c	(working copy)
@@ -2356,9 +2356,7 @@ mio_component_ref (gfc_component **cp, gfc_symbol
       if (sym->components != NULL && p->u.pointer == NULL)
 	{
 	  /* Symbol already loaded, so search by name.  */
-	  for (q = sym->components; q; q = q->next)
-	    if (strcmp (q->name, name) == 0)
-	      break;
+	  q = gfc_find_component (sym, name, false, false);
 
 	  if (q == NULL)
 	    gfc_internal_error ("mio_component_ref(): Component not found");


This fixes the test case, but is not regtested.
Comment 18 Dominique d'Humieres 2011-05-28 14:27:18 UTC
With the patch in comment #17, the "mio_component_ref(): Component not found" are gone, but compiling  gyre_lanr.f90 in the original code gives a segmentation fault:

[macbook] bug/pr47601% gfc -c gyre_lanr.f90
f951: internal compiler error: Segmentation fault

The backtrace is

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000000000000a8
gfc_use_derived (sym=0x0) at ../../work/gcc/fortran/symbol.c:1942
1942	  if (sym->components != NULL || sym->attr.zero_comp)
(gdb) bt
#0  gfc_use_derived (sym=0x0) at ../../work/gcc/fortran/symbol.c:1942
#1  0x000000010009f007 in gfc_find_component (sym=<value temporarily unavailable, due to optimizations>, name=0x7fff5fbfd220 "n_e", noaccess=0 '\0', silent=0 '\0') at ../../work/gcc/fortran/symbol.c:2002
#2  0x0000000000000001 in ?? ()
Comment 19 janus 2011-05-28 15:05:50 UTC
(In reply to comment #18)
> With the patch in comment #17, the "mio_component_ref(): Component not found"
> are gone, but compiling  gyre_lanr.f90 in the original code gives a
> segmentation fault:

Right. Some pieces were missing in your backtrace, here is a complete one:

Program received signal SIGSEGV, Segmentation fault.
0x000000000055a828 in gfc_use_derived (sym=0x0) at /home/jweil/gcc47/trunk/gcc/fortran/symbol.c:1942
1942      if (sym->components != NULL || sym->attr.zero_comp)
(gdb) bt
#0  0x000000000055a828 in gfc_use_derived (sym=0x0) at /home/jweil/gcc47/trunk/gcc/fortran/symbol.c:1942
#1  0x000000000055aa1b in gfc_find_component (sym=0x0, name=0x7fffffffd530 "n_e", noaccess=0 '\000', silent=0 '\000') at /home/jweil/gcc47/trunk/gcc/fortran/symbol.c:2002
#2  0x000000000055aac4 in gfc_find_component (sym=0x1ae7fe0, name=0x7fffffffd530 "n_e", noaccess=0 '\000', silent=0 '\000') at /home/jweil/gcc47/trunk/gcc/fortran/symbol.c:2015
#3  0x000000000050d039 in mio_component_ref (cp=0x1aea0b8, sym=0x1ae7fe0) at /home/jweil/gcc47/trunk/gcc/fortran/module.c:2359
Comment 20 Tobias Burnus 2011-05-28 15:12:26 UTC
Valgrind shows:
==9238== Invalid read of size 8
==9238==    at 0x55AFD9: gfc_use_derived (symbol.c:1942)
==9238==    by 0x55B126: gfc_find_component (symbol.c:2002)
==9238==    by 0x55B24A: gfc_find_component (symbol.c:2015)
==9238==    by 0x520B40: mio_ref (module.c:2359)

In gfc_use_derived, sym == NULL - thus, it is not surprising that sym->components gives an ICE.

The bug seems to be in gfc_find_component where the order of sym == NULL and gfc_use_derived seems to be reverted:

--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -2000,9 +2000,9 @@ gfc_find_component (gfc_symbol *sym, const char *name,
     return NULL;
 
-  sym = gfc_use_derived (sym);
-
   if (sym == NULL)
     return NULL;
 
+  sym = gfc_use_derived (sym);
+
   for (p = sym->components; p; p = p->next)
     if (strcmp (p->name, name) == 0)

 * * *

If one combines both patches, all reduced test cases work (comment 8, comment 11 and comment 13) and also the segfault is gone. However, in the last file of the compilation series, one now gets:

gyre_lanr.f90:6.19:

  use gyre_lanr_bvp
                   1
Interner Fehler bei (1):
mio_component_ref(): Component not found

 * * *

Note: For that ICE, the flag -std=f2003 is crucial. If I compile gyre_lanr_bvp.f90 without it, I do not get an ICE. I have not checked whether that's by chance (memory layout or similar).
Comment 21 janus 2011-05-28 15:23:22 UTC
Improved patch, makes the original test case work:

Index: gcc/fortran/module.c
===================================================================
--- gcc/fortran/module.c	(revision 174380)
+++ gcc/fortran/module.c	(working copy)
@@ -2356,14 +2356,10 @@ mio_component_ref (gfc_component **cp, gfc_symbol
       if (sym->components != NULL && p->u.pointer == NULL)
 	{
 	  /* Symbol already loaded, so search by name.  */
-	  for (q = sym->components; q; q = q->next)
-	    if (strcmp (q->name, name) == 0)
-	      break;
+	  q = gfc_find_component (sym, name, true, true);
 
-	  if (q == NULL)
-	    gfc_internal_error ("mio_component_ref(): Component not found");
-
-	  associate_integer_pointer (p, q);
+	  if (q)
+	    associate_integer_pointer (p, q);
 	}
 
       /* Make sure this symbol will eventually be loaded.  */
Index: gcc/fortran/symbol.c
===================================================================
--- gcc/fortran/symbol.c	(revision 174380)
+++ gcc/fortran/symbol.c	(working copy)
@@ -1996,14 +1996,11 @@ gfc_find_component (gfc_symbol *sym, const char *n
 {
   gfc_component *p;
 
-  if (name == NULL)
+  if (name == NULL || sym == NULL)
     return NULL;
-
+  
   sym = gfc_use_derived (sym);
 
-  if (sym == NULL)
-    return NULL;
-
   for (p = sym->components; p; p = p->next)
     if (strcmp (p->name, name) == 0)
       break;
Comment 22 Dominique d'Humieres 2011-05-28 16:38:18 UTC
If I did not do any mistake, the patch in comment #21 fixes this PR (AFAICT), but cause the following regression (on x86_64-apple-darwin10 with -m32):

[macbook] f90/bug% gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_proc_12.f90
f951: internal compiler error: Segmentation fault

The backtrace is

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000000000000a8
gfc_find_component (sym=<value temporarily unavailable, due to optimizations>, name=0x7fff5fbfcda0 "e", noaccess=0 '\0', silent=0 '\0') at ../../work/gcc/fortran/symbol.c:2004
2004	  for (p = sym->components; p; p = p->next)
(gdb) bt
#0  gfc_find_component (sym=<value temporarily unavailable, due to optimizations>, name=0x7fff5fbfcda0 "e", noaccess=0 '\0', silent=0 '\0') at ../../work/gcc/fortran/symbol.c:2004
#1  0x0000000100072378 in gfc_match_varspec (primary=0x141d19c00, equiv_flag=<value temporarily unavailable, due to optimizations>, sub_flag=0 '\0', ppc_arg=1 '\001') at ../../work/gcc/fortran/primary.c:1913
Comment 23 janus 2011-05-28 17:47:39 UTC
(In reply to comment #22)
> [macbook] f90/bug% gfc
> /opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_proc_12.f90
> f951: internal compiler error: Segmentation fault

Thanks for checking, Dominique. Here is an updated patch:

Index: gcc/fortran/module.c
===================================================================
--- gcc/fortran/module.c	(revision 174380)
+++ gcc/fortran/module.c	(working copy)
@@ -2356,14 +2356,10 @@ mio_component_ref (gfc_component **cp, gfc_symbol
       if (sym->components != NULL && p->u.pointer == NULL)
 	{
 	  /* Symbol already loaded, so search by name.  */
-	  for (q = sym->components; q; q = q->next)
-	    if (strcmp (q->name, name) == 0)
-	      break;
+	  q = gfc_find_component (sym, name, true, true);
 
-	  if (q == NULL)
-	    gfc_internal_error ("mio_component_ref(): Component not found");
-
-	  associate_integer_pointer (p, q);
+	  if (q)
+	    associate_integer_pointer (p, q);
 	}
 
       /* Make sure this symbol will eventually be loaded.  */
Index: gcc/fortran/symbol.c
===================================================================
--- gcc/fortran/symbol.c	(revision 174380)
+++ gcc/fortran/symbol.c	(working copy)
@@ -1996,7 +1996,7 @@ gfc_find_component (gfc_symbol *sym, const char *n
 {
   gfc_component *p;
 
-  if (name == NULL)
+  if (name == NULL || sym == NULL)
     return NULL;
 
   sym = gfc_use_derived (sym);
Comment 24 Dominique d'Humieres 2011-05-28 21:15:44 UTC
(In reply to comment #23)
> Here is an updated patch: ...

It passes my tests. Thanks.

Just one question:

+      if (q)
+        associate_integer_pointer (p, q);

What happens if q==0?
Comment 25 janus 2011-05-29 13:02:21 UTC
(In reply to comment #24)
> Just one question:
> 
> +      if (q)
> +        associate_integer_pointer (p, q);
> 
> What happens if q==0?

q == 0 means that the symbol of the parent derived type has not been loaded yet. In this case we do nothing at that particualar point, and wait until the symbol is loaded (like in the case "sym->components == NULL").
Comment 26 janus 2011-05-29 20:32:14 UTC
Author: janus
Date: Sun May 29 20:32:11 2011
New Revision: 174416

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

	PR fortran/47601
	* module.c (mio_component_ref): Handle components of extended types.
	* symbol.c (gfc_find_component): Return is sym is NULL.

2011-05-29  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/47601
	* gfortran.dg/extends_13.f03: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/extends_13.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/module.c
    trunk/gcc/fortran/symbol.c
    trunk/gcc/testsuite/ChangeLog
Comment 27 janus 2011-05-29 21:01:46 UTC
r174416 fixes all the test cases in this PR (except comment #11, which is invalid). I'm glad we finally nailed this one.

Closing as fixed. Thanks for reporting, Rich!
Comment 28 Rich Townsend 2011-05-29 21:10:08 UTC
(In reply to comment #27)
> r174416 fixes all the test cases in this PR (except comment #11, which is
> invalid). I'm glad we finally nailed this one.
> 
> Closing as fixed. Thanks for reporting, Rich!

Thanks everyone -- I'm very grateful for such a quick fix.

Now, if we could have CLASS arrays implemented within the next couple of months.... ;)
Comment 29 Kris 2011-06-08 13:12:59 UTC
(In reply to comment #27)
> r174416 fixes all the test cases in this PR (except comment #11, which is
> invalid). I'm glad we finally nailed this one.
> 
> Closing as fixed. Thanks for reporting, Rich!

Will this fix be applied to 4.6 or 4.5?
Comment 30 janus 2011-06-08 13:39:42 UTC
(In reply to comment #29)
> Will this fix be applied to 4.6 or 4.5?

Usually we only backport regression fixes, and since this is technically not a regression, the default procedure would be to *not* backport it to earlier releases.

However, if your life depends on it, we could maybe consider having an exception from that rule and doing a backport to the 4.6 branch (which is still young), given that the patch is relatively small and simple.

Doing a backport to 4.5 is probably not worth it, though. 4.5 has only very rudimentary support for CLASSes and polymorphism, and I would not expect anyone to seriously use it for larger OOP codes ...
Comment 31 Kris 2011-06-08 13:49:21 UTC
(In reply to comment #30)
> (In reply to comment #29)
> > Will this fix be applied to 4.6 or 4.5?
 
> However, if your life depends on it, we could maybe consider having an
> exception from that rule and doing a backport to the 4.6 branch (which is still
> young), given that the patch is relatively small and simple.

Although my *life* does not depend on it, I think backporting this fix to 4.6 would be beneficial, because it will be a while before 4.7 will be released and used widely.  

It seems to me that these sort of fixes are required before people will start using the more modern features of Fortran03/gfortran.

Thanks for fixing this, regardless.
Comment 32 janus 2011-06-19 21:05:22 UTC
Author: janus
Date: Sun Jun 19 21:05:18 2011
New Revision: 175194

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175194
Log:
2011-06-19  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/47601
	* module.c (mio_component_ref): Handle components of extended types.
	* symbol.c (gfc_find_component): Return if sym is NULL.

	PR fortran/48699
	* check.c (gfc_check_move_alloc): If 'TO' argument is polymorphic,
	make sure the vtab is present.

	PR fortran/49074
	* interface.c (gfc_extend_assign): Propagate the locus from the
	assignment to the type-bound procedure call.

	PR fortran/49417
	* module.c (mio_component): Make sure the 'class_ok' attribute is set
	for use-associated CLASS components.
	* parse.c (parse_derived): Check for 'class_ok' attribute.
	* resolve.c (resolve_fl_derived): Ditto.


2011-06-19  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/47601
	* gfortran.dg/extends_13.f03: New.

	PR fortran/48699
	* gfortran.dg/move_alloc_5.f90: New.

	PR fortran/49074
	* gfortran.dg/typebound_assignment_3.f03: New.

	PR fortran/49417
	* gfortran.dg/class_43.f03: New.

Added:
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/class_43.f03
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/extends_13.f03
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/move_alloc_5.f90
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/typebound_assignment_3.f03
Modified:
    branches/gcc-4_6-branch/gcc/fortran/ChangeLog
    branches/gcc-4_6-branch/gcc/fortran/check.c
    branches/gcc-4_6-branch/gcc/fortran/interface.c
    branches/gcc-4_6-branch/gcc/fortran/module.c
    branches/gcc-4_6-branch/gcc/fortran/parse.c
    branches/gcc-4_6-branch/gcc/fortran/resolve.c
    branches/gcc-4_6-branch/gcc/fortran/symbol.c
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
Comment 33 janus 2011-06-19 21:16:06 UTC
Ok, the backport has landed on the 4.6 branch and should be just in time for the 4.6.1 release.
Comment 34 Rich Townsend 2011-06-19 21:18:47 UTC
Thanks, Janus -- you rock!

On Jun 19, 2011, at 4:16 PM, janus at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601
> 
> --- Comment #33 from janus at gcc dot gnu.org 2011-06-19 21:16:06 UTC ---
> Ok, the backport has landed on the 4.6 branch and should be just in time for
> the 4.6.1 release.
> 
> -- 
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
Comment 35 Kris 2011-06-20 02:31:45 UTC
(In reply to comment #34)
> Thanks, Janus -- you rock!

I concur.  Thanks!