[Bug fortran/37829] ICE in resolve_symbol

["dominiq at lps dot ens dot fr" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #9 from dominiq at lps dot ens dot fr  2009-10-25 15:34 -------
(In reply to comment #8)
> > It seems that the patch in comment #2 has been silently applied 
> Not exactly silently. It was pr38672

Thanks for the pointer. This PR has not been marked as a duplicate of pr38672
and while the later refers to this one, the converse was not true.

> The whole iso_c_binding is messy because it doesn't look like normal modules.

I have also noticed that!-)

> It hijacks functions everywhere to take care of iso_c_binding cases and doesn't
> benefit from the general code. Here, the derived type of the function c_funloc
> is given a mangled name because it is not wanted by the user.
> This seems to fix it :
> ...

I think the patch just papers over the problem. With it, the following (weird,
but legal?) code:

module b
  use iso_c_binding, only:c_funloc!,c_funptr
end module b

program c
  use b
  implicit none
  type c_funptr
     integer :: i
  end type
  type (c_funptr) :: d 
  d = c_funptr(1)
end

now gives errors:

pr37829_2_red_1.f90:8.15:

  type c_funptr
               1
Error: Derived type name 'c_funptr' at (1) already has a basic type of
TYPE(c_funptr)
pr37829_2_red_1.f90:10.5:

  end type
     1
Error: Expecting END PROGRAM statement at (1)
pr37829_2_red_1.f90:12.6:

  d = c_funptr(1)
      1
Error: Components of structure constructor 'c_funptr' at (1) are PRIVATE

This is coherent if the mangling is used to hide symbols not wanted by the
user.
In my opinion the question is how to remove the mangling done in module b, when
the symbol is used in module a. From the little I understand that does seem
obvious for me.

Indeed using c_funloc in one module and defining the return type in another one
is asking for trouble.
Nevertheless if it is legal it should be accepted by gfortran. So either we
change the summary of this pr or close it, opening a new one for this use of
modules. It both cases the pr can be marked with a low priority and as an
enhancement.


-- 


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