[Bug fortran/58007] New: ICE -- free_pi_tree(): Unresolved fixup, depends on order of module inclusion

[Bug fortran/58007] New: ICE -- free_pi_tree(): Unresolved fixup, depends on order of module inclusion

[shapero at uw dot edu]

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

            Bug ID: 58007
           Summary: ICE -- free_pi_tree(): Unresolved fixup, depends on
                    order of module inclusion
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: shapero at uw dot edu

I have a moderate-size code I've been developing in Fortran 2003. I've tried to
reproduce it with small test cases to no avail -- perhaps I can give a link to
my git repository with instructions?


The following should work just fine:

git clone https://github.com/danshapero/fempack.git
git checkout e7547abe131b5c0e137fb0327069a75fcfed5d90
make libs


However, make the following change to src/linalg/linalg.f90:

-    use bsr
     use ellpack
     use csr
+    use bsr

and the following error results:

Internal Error at (1):
free_pi_tree(): Unresolved fixup
make: *** [src/linalg/linalg.o] Error 1

If it makes a difference, I'm using polymorphism somewhat extensively.


I've seen the following bug reports with similar behavior before: 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47546
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53015
In 47546, it's suggested that the error can be fixed by using implicit instead
of explicit shape arrays; all my arrays are implicit shape, so it's not that.
I'm compiling with just the -J flag; in 53015 it was suggested that using both
-I and -J can contribute to the problem.

While I might be able to make my code compile by cramming a bunch of modules
all together, it would make everything less, well, modular. Not desirable.

Hope the instructions were helpful and thanks for the help!

[Bug fortran/58007] ICE -- free_pi_tree(): Unresolved fixup, depends on order of module inclusion

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Created attachment 30565
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30565&action=edit
Patch to make it compile with GCC 4.8 and 4.9

(In reply to shapero from comment #0)
> git clone https://github.com/danshapero/fempack.git
> git checkout e7547abe131b5c0e137fb0327069a75fcfed5d90
> make libs

To underline the elusiveness: With 4.7.3 (release build), it builds without
running into the ICE.


With GCC 4.9 (and GCC 4.8) it doesn't build:

src/linalg/matrix_formats/csr.f90:24.13:
    procedure :: subset_matrix_add => csr_subset_matrix_add
             1
Error: Argument mismatch for the overriding procedure 'subset_matrix_add' at
(1): Type mismatch in argument 'b' (CLASS(csr_matrix)/CLASS(sparse_matrix))


However, if I apply the attached patch, it builds with gcc 4.9 - and I can
reproduce the "free_pi_tree(): Unresolved fixup".

[Bug fortran/58007] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[burnus at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-07-28
            Summary|ICE -- free_pi_tree():      |ICE in free_pi_tree():
                   |Unresolved fixup, depends   |Unresolved fixup -
                   |on order of module          |resolve_fixups does not
                   |inclusion                   |fixup component of
                   |                            |__class_bsr_Bsr_matrix
     Ever confirmed|0                           |1

[Bug fortran/58007] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[shapero at uw dot edu]

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

--- Comment #3 from shapero at uw dot edu ---
(In reply to Tobias Burnus from comment #2)
> Created attachment 30567 [details]
> Reduced test case
> 
> Reduced test case, which fails at least on my 86-64-gnu-linux system with a
> recent GCC 4.9. Compile as: 
> 
> $ gfortran matrix.f90 ellpack.f90 bsr.f90 matrix_c.f90
> matrix_c.f90:4.8:
>     use bsr
>         1
> Internal Error at (1):
> free_pi_tree(): Unresolved fixup
> 
> * * *
> 
> The triggered assert is:
> 221     free_pi_tree (pointer_info *p)
> 222     {
> 223       if (p == NULL)
> 224         return;
> 225
> 226       if (p->fixup != NULL)
> 227         gfc_internal_error ("free_pi_tree(): Unresolved fixup");
> 
> For the failing case, one has:
> 
> (gdb) p *p->fixup
> $4 = {pointer = 0x1678e08, next = 0x16780a0}
> 
> (gdb) p *p
> $2 = {priority = 38379, left = 0x1609dd0, right = 0x1606b20, integer = 6,
> type = P_COMPONENT, fixup = 0x1678f80, u = {pointer = 0x0, rsym = {sym =
> 0x0, true_name = 0x0, module = 0x0, binding_label = 0x0, stfixup = 0x0,
> symtree = 0x0, state = UNUSED, ns = 0, referenced = 0, renamed = 0, where =
> {column = 0, line = 0, pos = 0}}, wsym = {sym = 0x0, state = UNREFERENCED}}}
> 
> Here, *(p->fixup->pointer) == NULL and *p->fixup->next->pointer == NULL.
> 
> 
> Debugging shows that p->fixup->pointer is the address of the "cp" argument
> in the call to mio_pointer_ref in mio_component_ref for sym ==
> __class_bsr_Bsr_matrix and the component name "max_degreemio_pointer_ref".
> 
> And p->fixup->next->pointer is sym='__class_bsr_Bsr_matrix' and component
> name max_degreemio_pointer_ref
> 
> (i.e. the same, except that "cp" has a different pointer address.)
> 
> * * *
> 
> read_cleanup takes care of resolve_fixups - but only for p->type ==
> P_SYMBOL. However, we have here a p->type == P_COMPONENT.

I should have specified in my post but I'm using gfortran 4.7.2; your reduced
test case also fails for me. Could it be due to the explicit shape of the
return argument for bsr_get_neighbors?

Also, in reply to your first comment: should I be getting a type mismatch error
for the code I've written and my version of the compiler isn't working right,
or is my code compliant and versions 4.8/4.9 have a problem?

[Bug fortran/58007] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #30567|0                           |1
        is obsolete|                            |
                 CC|                            |janus at gcc dot gnu.org

--- Comment #4 from janus at gcc dot gnu.org ---
Created attachment 30641
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30641&action=edit
further reduced test case

Here is a further reduced test case, based on comment 2.

It consists of only two files. One contains the three modules, the other one an
almost empty main program.

For me this fails only with 4.8 and trunk, but not with 4.7.

[Bug fortran/58007] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

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

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

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

--- Comment #5 from Mikael Morin <mikael at gcc dot gnu.org> ---
I suppose the following is happening (based on Janus' test):

 - At the time bsr is use-associated we see references to
matrix::sparse_matrix, but as the type has already been loaded, we redirect
references to matrix::sparse_matrix to the one already loaded.  See
read_module, the code that comes after the comment:
      /* See if the symbol has already been loaded by a previous module.
     If so, we reference the existing symbol and prevent it from
     being loaded again.  This should not happen if the symbol being
     read is an index for an assumed shape dummy array (ns != 1).  */

 - Normally, mio_component (called from mio_component_list, from mio_symbol)
associates a component pointer to the corresponding pointer id so that it can
be referenced in expressions for example.  As the type is not loaded from file
(see above) the association isn't done either.

 - get_neighbors contains an expression (in the result's array spec)
referencing max_degree, one of matrix::sparse_matrix's components.  Because of
the above, the reference is not associated with the corresponding component
pointer, and it leads to the internal error.

[Bug fortran/58007] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

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

--- Comment #6 from Mikael Morin <mikael at gcc dot gnu.org> ---
further reduced test below.
Fails with trunk-20130619 and 4.7.3 here.
And works with 4.8-20130416.



module matrix
  type :: sparse_matrix
    integer :: max_degree
  end type
end module

module bsr
  use matrix
  type, extends(sparse_matrix) :: bsr_matrix
  contains
    procedure :: get_neighbors
  end type
contains
  function get_neighbors (A)
    class(bsr_matrix), intent(in) :: A
    integer :: get_neighbors(A%max_degree)
  end function
end module

program main
  use matrix
  use bsr
end

[Bug fortran/58007] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

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

--- Comment #7 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #5)
> I suppose the following is happening (based on Janus' test):
> 
> [...]
>
This may well be wrong as the typebound procedure in the just-submitted reduced
testcase is necessary to trigger the internal error.

[Bug fortran/58007] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

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

--- Comment #8 from Mikael Morin <mikael at gcc dot gnu.org> ---
Created attachment 30656
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30656&action=edit
tentative hack

For some reason this patch fixes the internal error on comment #6, but not on
comment #4.

[Bug fortran/58007] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[townsend at astro dot wisc.edu]

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

Rich Townsend <townsend at astro dot wisc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |townsend at astro dot wisc.edu

--- Comment #9 from Rich Townsend <townsend at astro dot wisc.edu> ---
(In reply to Mikael Morin from comment #8)
> Created attachment 30656 [details]
> tentative hack
> 
> For some reason this patch fixes the internal error on comment #6, but not
> on comment #4.

I can conform that this patch works to fix the bug on trunk (rev. 202487)
running on OS X 10.7. Without the patch, the test case in #6 fails with the
usual unresolved fixup issue.

However, *with* Mikael's patch I'm no longer able to build the HDF5 libraries
(1.8.10-patch1). During compilation of the Fortran API, I get the following:

tH5L_F03.f90:125.6:

  USE liter_cb_mod
      1
Internal Error at (1):
free_pi_tree(): Unresolved fixup
make[2]: *** [tH5L_F03.o] Error 1

I configured thusly:

./configure --build=x86_64-apple-darwin11.4.2 --prefix=/Applications/mesasdk
--enable-fortran --enable-fortran2003

This has become a showstopper for me: I need Mikael's patch to fix unresolved
fixup issues with my own codes (with a similar trigger to the examples given
above), but I also need the HDF5 libraries for the codes. Unresolved fixups are
the #1 bug I've encountered with gfortran over the past year, yet due to their
very temperamental nature they're difficult to report and thus difficult to
make the gfortran developers sit up and take notice of.

So, I'd like to make a earnest plea to the devs: please get to the bottom of
this! I'm happy to work closely with you in coming up with test cases that
trigger the bug. But this really needs to be fixed; it basically kills gfortran
as a viable compiler.

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.6.4, 4.8.1
            Summary|[OOP] ICE in                |[4.7/4.9 Regression] [OOP]
                   |free_pi_tree(): Unresolved  |ICE in free_pi_tree():
                   |fixup - resolve_fixups does |Unresolved fixup -
                   |not fixup component of      |resolve_fixups does not
                   |__class_bsr_Bsr_matrix      |fixup component of
                   |                            |__class_bsr_Bsr_matrix
      Known to fail|                            |4.7.3, 4.9.0

--- Comment #10 from janus at gcc dot gnu.org ---
Marking this one as a regression, since comment 6 seems to fail only with 4.7
and trunk.

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.7.4

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[townsend at astro dot wisc.edu]

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

--- Comment #11 from Rich Townsend <townsend at astro dot wisc.edu> ---
#6 fails with 4.9.0 (svn rev. 206179), on both OS X and Linux.

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #30656|0                           |1
        is obsolete|                            |

--- Comment #12 from Mikael Morin <mikael at gcc dot gnu.org> ---
Created attachment 31511
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31511&action=edit
Patch fixing both comment #4 and comment #6

Let's hope it's not too late to put this under the christmas tree.

This patch does forces pointer association of components of a derived type
which has already been loaded.
I don't like it much, as it is dependent on the order of the symbol contents as
specified by the mio_symbol code.

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-p
                   |                            |atches/2014-01/msg00038.htm
                   |                            |l
           Assignee|unassigned at gcc dot gnu.org      |mikael at gcc dot gnu.org

--- Comment #14 from Mikael Morin <mikael at gcc dot gnu.org> ---
I have just committed a fix on trunk, so I may as well take the bug.
For reference, the patch submission was at:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00038.html

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #15 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #14)
> so I may as well take the bug.

Grrr! ASSIGNED, I said.

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

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

--- Comment #16 from Mikael Morin <mikael at gcc dot gnu.org> ---
Author: mikael
Date: Sun Jan 26 13:04:54 2014
New Revision: 207117

URL: http://gcc.gnu.org/viewcvs?rev=207117&root=gcc&view=rev
Log:
fortran/
        PR fortran/58007
        * module.c
        (fp2, find_pointer2): Remove.
        (mio_component_ref): Don't forcedfully set the containing derived type
        symbol for loading.  Remove unused argument.
        (mio_ref): Update caller
        (skip_list): New argument nest_level.  Initialize level with the new
        argument.
        (read_module): Add forced pointer components association for derived
        type symbols.

testsuite/
        PR fortran/58007
        * gfortran.dg/unresolved_fixup_1.f90: New test.
        * gfortran.dg/unresolved_fixup_2.f90: New test.


Added:
    branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/unresolved_fixup_1.f90
    branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/unresolved_fixup_2.f90
Modified:
    branches/gcc-4_8-branch/gcc/fortran/ChangeLog
    branches/gcc-4_8-branch/gcc/fortran/module.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

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

--- Comment #18 from Mikael Morin <mikael at gcc dot gnu.org> ---
Author: mikael
Date: Sun Jan 26 14:49:47 2014
New Revision: 207119

URL: http://gcc.gnu.org/viewcvs?rev=207119&root=gcc&view=rev
Log:
fortran/
        PR fortran/58007
        * module.c (fp2, find_pointer2): Remove.
        (mio_component_ref): Don't forcedfully set the containing derived type
        symbol for loading.  Remove unused argument.
        (mio_ref): Update caller
        (skip_list): New argument nest_level.  Initialize level with the new
        argument.
        (read_module): Add forced pointer components association for derived
        type symbols.

testsuite/
        PR fortran/58007
        * gfortran.dg/unresolved_fixup_1.f90: New test.
        * gfortran.dg/unresolved_fixup_2.f90: New test.


Added:
    branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/unresolved_fixup_1.f90
    branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/unresolved_fixup_2.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/testsuite/ChangeLog

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

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

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

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

--- Comment #19 from Mikael Morin <mikael at gcc dot gnu.org> ---
Fixed for 4.7.4, 4.8.3 and 4.9.0.

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[mikael at gcc dot gnu.org]

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

--- Comment #20 from Mikael Morin <mikael at gcc dot gnu.org> ---
Author: mikael
Date: Mon Jan 27 21:23:16 2014
New Revision: 207152

URL: http://gcc.gnu.org/viewcvs?rev=207152&root=gcc&view=rev
Log:
fortran/
        PR fortran/58007
        * module.c (skip_list): Don't use default argument value.
        (load_derived_extensions, read_module): Update callers.


Modified:
    branches/gcc-4_7-branch/gcc/fortran/ChangeLog
    branches/gcc-4_7-branch/gcc/fortran/module.c