[Bug fortran/47546] New: Internal error - free_pi_tree(): Unresolved fixup

[Bug fortran/47546] New: Internal error - free_pi_tree(): Unresolved fixup

[townsend at astro dot wisc.edu]

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

           Summary: Internal error - free_pi_tree(): Unresolved fixup
           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 23169
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23169
Tar file containing source code and Makefile

Compiling the attached code:

gfortran -c hydro_types.f90 hydro_state.f90 hydro_speeds.f90 hydro_fluxes.f90

...I get the following error:

hydro_fluxes.f90:7.18:

  use hydro_speeds
                  1
Internal Error at (1):
free_pi_tree(): Unresolved fixup

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.01.30 19:21:40
                 CC|                            |janus at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-01-30 19:21:40 UTC ---
The code compiles with if I concatenate all the files in a single one. The ICE
is still there if I reduce the file hydro_fluxes.f90 to

module hydro_fluxes

! Uses

  use hydro_types
  use hydro_state
  use hydro_speeds

end module hydro_fluxes

and disappears if I comment the line

  use hydro_speeds

If gfortran is 4.5, I get 

hydro_fluxes.f90:7.18:

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

so it looks like an avatar of pr45827.

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[mikael at gcc dot gnu.org]

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

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-01-30 19:45:02 UTC ---
It works here if I circumvent the driver.

$ for file in hydro_types.f90 hydro_state.f90 hydro_speeds.f90 hydro_fluxes.f90
do
~/gcc46/build/gcc/f951 $file
done

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org 2011-02-02 14:49:16 UTC ---
(In reply to comment #1)
> If gfortran is 4.5, I get 
> 
> hydro_fluxes.f90:7.18:
> 
>   use hydro_speeds
>                   1
> Internal Error at (1):
> mio_component_ref(): Component not found


I get the same error with gfortran 4.5, but 4.6 works nicely for me at r169520.
Rich, which version are you using?

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[townsend at astro dot wisc.edu]

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

--- Comment #4 from Rich Townsend <townsend at astro dot wisc.edu> 2011-02-02 16:52:49 UTC ---
On Feb 2, 2011, at 8:49 AM, janus at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47546
> 
> --- Comment #3 from janus at gcc dot gnu.org 2011-02-02 14:49:16 UTC ---
> (In reply to comment #1)
>> If gfortran is 4.5, I get 
>> 
>> hydro_fluxes.f90:7.18:
>> 
>>  use hydro_speeds
>>                  1
>> Internal Error at (1):
>> mio_component_ref(): Component not found
> 
> 
> I get the same error with gfortran 4.5, but 4.6 works nicely for me at r169520.
> Rich, which version are you using?

Here's what gfortran -v gives:

Using built-in specs.
COLLECT_GCC=gfortran-mp-4.6
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.6-20110122/configure --prefix=/opt/local
--build=x86_64-apple-darwin10 --libdir=/opt/local/lib/gcc46
--includedir=/opt/local/include/gcc46 --infodir=/opt/local/share/info
--mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.6
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-4.6 --with-gxx-include-dir=/opt/local/include/gcc46/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local
--enable-stage1-checking --disable-multilib --enable-fully-dynamic-string
--enable-languages=c,c++,objc,obj-c++,fortran
Thread model: posix
gcc version 4.6.0 20110122 (experimental) (GCC) 

The install is via macports.

cheers,

Rich

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org 2011-02-02 17:14:56 UTC ---
(In reply to comment #4)
> > Rich, which version are you using?
> 
> Here's what gfortran -v gives:
> [...]
> Target: x86_64-apple-darwin10
> [...]
> gcc version 4.6.0 20110122 (experimental) (GCC) 

Huh. Either it has been fixed in the meantime or it is a Darwin-specific
problem, since I don't see it on Linux with the current trunk.

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org 2011-02-02 18:25:42 UTC ---
(In reply to comment #0)
> hydro_fluxes.f90:7.18:
> 
>   use hydro_speeds
>                   1
> Internal Error at (1):
> free_pi_tree(): Unresolved fixup

I can reproduce the error on Darwin with current trunk (r169590).

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-02-02 18:51:17 UTC ---
> I can reproduce the error on Darwin with current trunk (r169590).

Me too at revision 169531. Revision 158105 gives

hydro_fluxes.f90:7.18:

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

revision 159105 gives

hydro_fluxes.f90:7.18:

  use hydro_speeds
                  1
Internal Error at (1):
free_pi_tree(): Unresolved fixup

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org 2011-02-02 19:31:39 UTC ---
This is a *very* strange bug, to say the least. Here is a reduced test case:


module hydro_types
  implicit none
end module hydro_types

module hydro_state
  implicit none
  type :: state_t
     real    :: U         
     integer :: n
  end type
  private
  public :: state_t
contains
  subroutine init
    type(state_t) :: this
  end subroutine init
end module hydro_state

module hydro_speeds
  use hydro_state
  implicit none
contains
  subroutine speeds_cell (st, c_l, c_r)
    class(state_t) :: st
    real     :: c_l(st%n)
    real     :: c_r(st%n)
  end subroutine speeds_cell
end module hydro_speeds

module hydro_fluxes
  use hydro_state
  use hydro_speeds
end module



Putting this in a single file and compiling still gives me the error:

  use hydro_speeds
                  1
Interner Fehler bei (1):
free_pi_tree(): Unresolved fixup


I'm not quite sure it is related to OOP. There is still one CLASS variable in
there which I could not remove.

On the other hand, the failure is very elusive: Even removing the 'implicit
none' line in the module 'hydro_types' (which btw is never used) will make it
go away for me.

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[townsend at astro dot wisc.edu]

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

--- Comment #9 from Rich Townsend <townsend at astro dot wisc.edu> 2011-02-02 19:56:25 UTC ---
(In reply to comment #8)
> On the other hand, the failure is very elusive: Even removing the 'implicit
> none' line in the module 'hydro_types' (which btw is never used) will make it
> go away for me.

Sounds like a Heisenbug -- it goes away when you look for it. Would it be worth
bringing valgrind into the picture?

cheers,

Rich

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org 2011-02-02 20:15:07 UTC ---
(In reply to comment #9)
> Sounds like a Heisenbug -- it goes away when you look for it. Would it be worth
> bringing valgrind into the picture?

Maybe. Could you try if it gives any useful output? Also: Can you reproduce the
error with my reduced test case in comment #8?


A different thought: Since 4.5 gives on the same test case

mio_component_ref(): Component not found

it may be related to PR45827.

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-02-02 21:04:14 UTC ---
> ... Also: Can you reproduce the
> error with my reduced test case in comment #8?

I can. Apparently some p->fixup has not been initialized/nullified.

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[janus at gcc dot gnu.org]

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

--- Comment #12 from janus at gcc dot gnu.org 2011-02-02 21:17:23 UTC ---
(In reply to comment #11)
> > ... Also: Can you reproduce the
> > error with my reduced test case in comment #8?
> 
> I can. Apparently some p->fixup has not been initialized/nullified.

In fact I can even reproduce this on Linux (in contrast to the code in comment
#0).

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[mikael at gcc dot gnu.org]

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

--- Comment #13 from Mikael Morin <mikael at gcc dot gnu.org> 2011-02-02 21:26:56 UTC ---
(In reply to comment #12)
> (In reply to comment #11)
> > > ... Also: Can you reproduce the
> > > error with my reduced test case in comment #8?
> > 
> > I can. Apparently some p->fixup has not been initialized/nullified.
> 
> In fact I can even reproduce this on Linux (in contrast to the code in comment
> #0).

Same on FreeBSD. 
It is something with the 'n' component of type state_t. 
That component is needed in hydro_speeds for the prototype of speeds_cell but
it is not found somehow. 
I can see it in the module file however.

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[mikael at gcc dot gnu.org]

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

--- Comment #14 from Mikael Morin <mikael at gcc dot gnu.org> 2011-02-02 22:24:54 UTC ---
in read_module, around line 4390

      /* Skip symtree nodes not in an ONLY clause, unless there
         is an existing symtree loaded from another USE statement.  */
      if (p == NULL)
        {
          st = gfc_find_symtree (gfc_current_ns->sym_root, name);
          if (st != NULL)
        info->u.rsym.symtree = st;
          continue;
        }


state_t from hydro_speeds(imported from hydro_state) is not loaded because
state_t from hydro_state is already present in the namespace. Thus the
components of state_t from hydro_speeds are not loaded either. 

I don't see any obvious/easy fix right now.

I think there were some module symbol conflicts PRs more or less related to
this, but can't find them.

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[townsend at astro dot wisc.edu]

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

--- Comment #15 from Rich Townsend <townsend at astro dot wisc.edu> 2011-02-03 00:09:57 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > Sounds like a Heisenbug -- it goes away when you look for it. Would it be worth
> > bringing valgrind into the picture?
> 
> Maybe. Could you try if it gives any useful output? 

==13807== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==13807== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==13807== Command: gfortran-mp-4.6 -c foo.f90
==13807== 
foo.f90:32.17:

 use hydro_speeds
                 1
Internal Error at (1):
free_pi_tree(): Unresolved fixup
==13807== 
==13807== HEAP SUMMARY:
==13807==     in use at exit: 33,558 bytes in 82 blocks
==13807==   total heap usage: 135 allocs, 53 frees, 35,636 bytes allocated
==13807== 
==13807== LEAK SUMMARY:
==13807==    definitely lost: 2,027 bytes in 31 blocks
==13807==    indirectly lost: 75 bytes in 2 blocks
==13807==      possibly lost: 4,085 bytes in 2 blocks
==13807==    still reachable: 27,371 bytes in 47 blocks
==13807==         suppressed: 0 bytes in 0 blocks
==13807== Rerun with --leak-check=full to see details of leaked memory
==13807== 
==13807== For counts of detected and suppressed errors, rerun with: -v
==13807== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 3)

Nothing particularly alarming -- although I guess those memory leaks might need
fixing at some point.

> Also: Can you reproduce the
> error with my reduced test case in comment #8?
> 

Done -- and I get the same fixup error.

> 
> A different thought: Since 4.5 gives on the same test case
> 
> mio_component_ref(): Component not found
> 
> it may be related to PR45827.

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[mikael at gcc dot gnu.org]

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

--- Comment #16 from Mikael Morin <mikael at gcc dot gnu.org> 2011-02-03 18:32:07 UTC ---
Rich, in case this is a blocker on a real world application, you can probably
circumvent the error by not use-importing hydro_state when you use-import
hydro_speeds.

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[townsend at astro dot wisc.edu]

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

--- Comment #17 from Rich Townsend <townsend at astro dot wisc.edu> 2011-02-03 22:54:34 UTC ---
(In reply to comment #16)
> Rich, in case this is a blocker on a real world application, you can probably
> circumvent the error by not use-importing hydro_state when you use-import
> hydro_speeds.

Thanks -- v. helpful suggestion. I implemented this by moving the hydro_speeds
routines into hydro_state, and the code compiles and runs fine.

cheers,

Rich

[Bug fortran/47546] Internal error - free_pi_tree(): Unresolved fixup

[townsend at astro dot wisc.edu]

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

--- Comment #18 from Rich Townsend <townsend at astro dot wisc.edu> 2011-02-03 23:04:22 UTC ---
(In reply to comment #8)
> This is a *very* strange bug, to say the least. Here is a reduced test case:
> 
> 
> module hydro_types
>   implicit none
> end module hydro_types
> 
> module hydro_state
>   implicit none
>   type :: state_t
>      real    :: U         
>      integer :: n
>   end type
>   private
>   public :: state_t
> contains
>   subroutine init
>     type(state_t) :: this
>   end subroutine init
> end module hydro_state
> 
> module hydro_speeds
>   use hydro_state
>   implicit none
> contains
>   subroutine speeds_cell (st, c_l, c_r)
>     class(state_t) :: st
>     real     :: c_l(st%n)
>     real     :: c_r(st%n)
>   end subroutine speeds_cell
> end module hydro_speeds
> 
> module hydro_fluxes
>   use hydro_state
>   use hydro_speeds
> end module

Here's an interesting observation: if the definitions of c_l and c_r are
changed to

 real     :: c_l(:)
 real     :: c_r(:)

(i.e., assumed shape rather than explicit shape), then the problem goes away.

In the interests of full disclosure, I should add that this is how I intended
to code the speeds_cell routine in the first place -- I have no real need of
the explicit shapes, assumed shapes are just fine. So, this bug becomes much
less of a showstopper for me.

[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup

[townsend at astro dot wisc.edu]

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

--- Comment #19 from Rich Townsend <townsend at astro dot wisc.edu> 2011-03-16 02:29:35 UTC ---
(In reply to comment #18)
> (In reply to comment #8)
> > This is a *very* strange bug, to say the least. Here is a reduced test case:
> > 
> > 
> > module hydro_types
> >   implicit none
> > end module hydro_types
> > 
> > module hydro_state
> >   implicit none
> >   type :: state_t
> >      real    :: U         
> >      integer :: n
> >   end type
> >   private
> >   public :: state_t
> > contains
> >   subroutine init
> >     type(state_t) :: this
> >   end subroutine init
> > end module hydro_state
> > 
> > module hydro_speeds
> >   use hydro_state
> >   implicit none
> > contains
> >   subroutine speeds_cell (st, c_l, c_r)
> >     class(state_t) :: st
> >     real     :: c_l(st%n)
> >     real     :: c_r(st%n)
> >   end subroutine speeds_cell
> > end module hydro_speeds
> > 
> > module hydro_fluxes
> >   use hydro_state
> >   use hydro_speeds
> > end module
> 
> Here's an interesting observation: if the definitions of c_l and c_r are
> changed to
> 
>  real     :: c_l(:)
>  real     :: c_r(:)
> 
> (i.e., assumed shape rather than explicit shape), then the problem goes away.
> 
> In the interests of full disclosure, I should add that this is how I intended
> to code the speeds_cell routine in the first place -- I have no real need of
> the explicit shapes, assumed shapes are just fine. So, this bug becomes much
> less of a showstopper for me.

Well, I spoke too soon -- I've just gone through a code refactorization, and
this same bug has cropped up again. This time, the 'workaround' above no longer
helps out.

Fundamentally, this is a problem that hasn't gone away; the reduced test case
fails in exactly the same way, even using a recent (4.6.0 20110312) build. Has
anyone been able to figure out what is going on?

[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

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

--- Comment #20 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-03-16 02:48:41 UTC ---
I see the problem on x86-64 linux with current trunk.

Problem goes away if I reverse the order of the use statements:

From:

module hydro_fluxes
  use hydro_state
  use hydro_speeds
end module

To:

module hydro_fluxes
  use hydro_speeds
  use hydro_state
end module

This hints at some sort of namespace corruption, maybe related to hydro_speeds
uses hydro_state.

[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup

[jvdelisle at gcc dot gnu.org]

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

--- Comment #21 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-03-16 02:57:02 UTC ---
partial valgrind:

==3316== 5,104 bytes in 2 blocks are definitely lost in loss record 433 of 443
==3316==    at 0x4A04896: calloc (vg_replace_malloc.c:418)
==3316==    by 0xD49748: xcalloc (xmalloc.c:162)
==3316==    by 0x522F6D: gfc_get_namespace (symbol.c:2286)
==3316==    by 0x524C64: gfc_copy_formal_args (symbol.c:4022)
==3316==    by 0x5250F1: gfc_copy_formal_args_ppc (symbol.c:4151)
==3316==    by 0x50782A: resolve_fl_derived (resolve.c:11474)
==3316==    by 0x50233E: resolve_symbol (resolve.c:12021)
==3316==    by 0x504110: resolve_structure_cons (resolve.c:967)
==3316==    by 0x50D581: resolve_values (resolve.c:9313)
==3316==    by 0x51EFF6: traverse_ns (symbol.c:3333)
==3316==    by 0x51EFE5: traverse_ns (symbol.c:3330)
==3316==    by 0x50C8EE: resolve_types (resolve.c:13530)
==3316== 
==3316== 8,600 (5,104 direct, 3,496 indirect) bytes in 2 blocks are definitely
lost in loss record 435 of 443
==3316==    at 0x4A04896: calloc (vg_replace_malloc.c:418)
==3316==    by 0xD49748: xcalloc (xmalloc.c:162)
==3316==    by 0x522F6D: gfc_get_namespace (symbol.c:2286)
==3316==    by 0x524C64: gfc_copy_formal_args (symbol.c:4022)
==3316==    by 0x5250F1: gfc_copy_formal_args_ppc (symbol.c:4151)
==3316==    by 0x50782A: resolve_fl_derived (resolve.c:11474)
==3316==    by 0x50233E: resolve_symbol (resolve.c:12021)
==3316==    by 0x51EFF6: traverse_ns (symbol.c:3333)
==3316==    by 0x50C7A3: resolve_types (resolve.c:13513)
==3316==    by 0x501363: gfc_resolve (resolve.c:13612)
==3316==    by 0x4F5E77: gfc_parse_file (parse.c:4368)
==3316==    by 0x52FAA5: gfc_be_parse_file (f95-lang.c:250)

[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup

[jvdelisle at gcc dot gnu.org]

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

--- Comment #22 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-03-16 02:58:59 UTC ---
Another valgrind chunk:

==3316== 318 bytes in 2 blocks are definitely lost in loss record 357 of 443
==3316==    at 0x4A04896: calloc (vg_replace_malloc.c:418)
==3316==    by 0xD49748: xcalloc (xmalloc.c:162)
==3316==    by 0x656E34: init_emit (emit-rtl.c:5544)
==3316==    by 0x6EA958: prepare_function_start (function.c:4433)
==3316==    by 0x6F09F8: init_function_start (function.c:4487)
==3316==    by 0x54859E: trans_function_start.clone.0 (trans-decl.c:2103)
==3316==    by 0x552C60: gfc_generate_function_code (trans-decl.c:4728)
==3316==    by 0x534CA1: gfc_generate_module_code (trans.c:1511)
==3316==    by 0x4F6344: gfc_parse_file (parse.c:4379)
==3316==    by 0x52FAA5: gfc_be_parse_file (f95-lang.c:250)
==3316==    by 0x845EC6: toplev_main (toplev.c:579)
==3316==    by 0x3F03A1EE5C: (below main) (libc-start.c:226)
==3316==

[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup

[jvdelisle at gcc dot gnu.org]

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

--- Comment #23 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-03-16 03:01:11 UTC ---
Another small piece just before the error message.

$ valgrind --leak-check=full f951 pr47546.f90 
==3316== Memcheck, a memory error detector
==3316== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==3316== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==3316== Command: f951 pr47546.f90
==3316== 
 init __copy_hydro_state_State_t speeds_cellpr47546.f90:32.18:

  use hydro_speeds
                  1
Internal Error at (1):
free_pi_tree(): Unresolved fixup

What the heck is that?

[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup

[jvdelisle at gcc dot gnu.org]

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

--- Comment #24 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-03-16 04:10:09 UTC ---
Created attachment 23678
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23678
Valgrind out for test case that completes compilation

This attachment with the version of the test case that compiled without error
shows the valgrind errors.  Hope this helps isolate the problem.

[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup

[dominiq at lps dot ens.fr]

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

--- Comment #25 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-03-29 16:57:17 UTC ---
AFAICT this pr seems fixed by revision 171654 (pr48095).

[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup

[janus at gcc dot gnu.org]

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

--- Comment #26 from janus at gcc dot gnu.org 2011-03-29 17:12:54 UTC ---
(In reply to comment #25)
> AFAICT this pr seems fixed by revision 171654 (pr48095).

Oh, wow. That's kind of unexpected. But nice :)

[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup

[janus at gcc dot gnu.org]

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

--- Comment #27 from janus at gcc dot gnu.org 2011-03-29 17:28:43 UTC ---
(In reply to comment #25)
> AFAICT this pr seems fixed by revision 171654 (pr48095).

I can confirm that comment #8 works with current trunk on
x86_64-unknown-linux-gnu. However, I do not see how or why it is fixed. The
only explanation I have is that it was a bug in module I/O, and the modified
module format somehow fixes (or just hides) it.

Rich, can you confirm that all test cases in this PR now work for you?

Also, since PR 47601 may be related, can someone check if this is fixed too (on
Darwin)?

[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME

--- Comment #28 from janus at gcc dot gnu.org 2011-03-29 19:15:49 UTC ---
Comment #0 also works for me on darwin, so I'm closing this PR.

PR47601, however, does not seem to be fully fixed yet.