[Bug fortran/47601] New: Internal Error (mio_component_ref(): Component not found) with strange behavior

[Bug fortran/47601] New: Internal Error (mio_component_ref(): Component not found) with strange behavior

[townsend at astro dot wisc.edu]

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

           Summary: Internal Error (mio_component_ref(): Component not
                    found) with strange behavior
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: townsend@astro.wisc.edu


Created attachment 23238
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23238
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.

[Bug fortran/47601] Internal Error (mio_component_ref(): Component not found) with strange behavior

[townsend at astro dot wisc.edu]

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

--- Comment #1 from Rich Townsend <townsend at astro dot wisc.edu> 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

[Bug fortran/47601] Internal Error (mio_component_ref(): Component not found) with strange behavior

[mikael at gcc dot gnu.org]

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

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

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

--- Comment #2 from Mikael Morin <mikael at gcc dot gnu.org> 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 ?

[Bug fortran/47601] Internal Error (mio_component_ref(): Component not found) with strange behavior

[townsend at astro dot wisc.edu]

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

--- Comment #3 from Rich Townsend <townsend at astro dot wisc.edu> 2011-02-03 19:20:12 UTC ---
Created attachment 23239
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23239
Fixed Makefile

Removed some broken dependencies from the original Makefile

[Bug fortran/47601] Internal Error (mio_component_ref(): Component not found) with strange behavior

[mikael at gcc dot gnu.org]

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

--- Comment #4 from Mikael Morin <mikael at gcc dot gnu.org> 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

[Bug fortran/47601] Internal Error (mio_component_ref(): Component not found) with strange behavior

[townsend at astro dot wisc.edu]

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

--- Comment #5 from Rich Townsend <townsend at astro dot wisc.edu> 2011-02-03 21:17:29 UTC ---
Created attachment 23241
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23241
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.

[Bug fortran/47601] Internal Error (mio_component_ref(): Component not found) with strange behavior

[mikael at gcc dot gnu.org]

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

--- Comment #6 from Mikael Morin <mikael at gcc dot gnu.org> 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 :-/

[Bug fortran/47601] Internal Error (mio_component_ref(): Component not found) with strange behavior

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-02-03 22:13:11 UTC ---
On x86_64-apple-darwin10.6.0 the test in attachment 23241 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.

[Bug fortran/47601] Internal Error: mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.02.03 23:12:41
            Summary|Internal Error              |Internal Error:
                   |(mio_component_ref():       |mio_component_ref():
                   |Component not found) with   |Component not found
                   |strange behavior            |
     Ever Confirmed|0                           |1

--- Comment #8 from janus at gcc dot gnu.org 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).

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org 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

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[mikael at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kristopher.kuhlman at gmail
                   |                            |dot com

--- Comment #10 from Mikael Morin <mikael at gcc dot gnu.org> 2011-04-04 12:54:16 UTC ---
*** Bug 48428 has been marked as a duplicate of this bug. ***

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[kristopher.kuhlman at gmail dot com]

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

--- Comment #11 from Kris <kristopher.kuhlman at gmail dot com> 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

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[townsend at astro dot wisc.edu]

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

--- Comment #12 from Rich Townsend <townsend at astro dot wisc.edu> 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).

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

--- Comment #13 from janus at gcc dot gnu.org 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.

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[townsend at astro dot wisc.edu]

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

--- Comment #14 from Rich Townsend <townsend at astro dot wisc.edu> 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'

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[kristopher.kuhlman at gmail dot com]

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

--- Comment #15 from Kris <kristopher.kuhlman at gmail dot com> 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.

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #16 from Tobias Burnus <burnus at gcc dot gnu.org> 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?

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |janus at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #17 from janus at gcc dot gnu.org 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.

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[dominiq at lps dot ens.fr]

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

--- Comment #18 from Dominique d'Humieres <dominiq at lps dot ens.fr> 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 ?? ()

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

--- Comment #19 from janus at gcc dot gnu.org 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

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[burnus at gcc dot gnu.org]

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

--- Comment #20 from Tobias Burnus <burnus at gcc dot gnu.org> 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).

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

--- Comment #21 from janus at gcc dot gnu.org 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;

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[dominiq at lps dot ens.fr]

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

--- Comment #22 from Dominique d'Humieres <dominiq at lps dot ens.fr> 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

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

--- Comment #23 from janus at gcc dot gnu.org 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);

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[dominiq at lps dot ens.fr]

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

--- Comment #24 from Dominique d'Humieres <dominiq at lps dot ens.fr> 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?

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

--- Comment #25 from janus at gcc dot gnu.org 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").

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

--- Comment #26 from janus at gcc dot gnu.org 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

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #27 from janus at gcc dot gnu.org 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!

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[townsend at astro dot wisc.edu]

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

--- Comment #28 from Rich Townsend <townsend at astro dot wisc.edu> 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.... ;)

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[kristopher.kuhlman at gmail dot com]

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

--- Comment #29 from Kris <kristopher.kuhlman at gmail dot com> 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?

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

--- Comment #30 from janus at gcc dot gnu.org 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 ...

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[kristopher.kuhlman at gmail dot com]

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

--- Comment #31 from Kris <kristopher.kuhlman at gmail dot com> 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.

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

--- Comment #32 from janus at gcc dot gnu.org 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

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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.

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[townsend at astro dot wisc.edu]

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

--- Comment #34 from Rich Townsend <townsend at astro dot wisc.edu> 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.

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[kristopher.kuhlman at gmail dot com]

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

--- Comment #35 from Kris <kristopher.kuhlman at gmail dot com> 2011-06-20 02:31:45 UTC ---
(In reply to comment #34)
> Thanks, Janus -- you rock!

I concur.  Thanks!