Bug 47546

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.

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

(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?

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

(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.

(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).

> 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

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.

(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

(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.

> ... 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 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).

(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.

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.

(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.

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.

(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

(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.

(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?

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.

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)

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==

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?

Created attachment 23678 [details]
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.

AFAICT this pr seems fixed by revision 171654 (pr48095).

(In reply to comment #25)
> AFAICT this pr seems fixed by revision 171654 (pr48095).

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

(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)?

Comment #0 also works for me on darwin, so I'm closing this PR.

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