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