https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931
--- Comment #20 from anlauf at gcc dot gnu.org ---
(In reply to Bernhard Reutner-Fischer from comment #18)
> diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
> index 221165d6dac..28ed1a32b9e 100644
> --- a/gcc/fortran/symbol.cc
> +++ b/gcc/fortran/symbol.cc
> @@ -4977,6 +4986,10 @@ generate_isocbinding_symbol (const char *mod_name,
> iso_c_binding_symbol s,
> if (!tmp_sym->attr.function
> && !gfc_add_function (&tmp_sym->attr, tmp_sym->name, NULL))
> return NULL;
> +
> + /* Mark the derived-type symbol in the generic interface
> + as generic. */
> + dt_sym->attr.generic = 1;
> }
>
> /* Say what module this symbol belongs to. */
>
>
This change would lead to an accepts-invalid, such as for:
module AModule
use, intrinsic :: ISO_C_BINDING, only: C_PTR
use, intrinsic :: ISO_C_BINDING, only: X_PTR => C_FUNPTR
implicit none
end module
module GModule
use AModule, only: X_PTR => C_PTR ! C_PTR
implicit none
end module
module HModule
use AModule, only: C_PTR => X_PTR ! C_FUNPTR
use GModule, only: C_PTR => X_PTR ! C_PTR
implicit none
type(c_ptr) :: ptr
end module
Without the patch I'd get (as expected):
pr103931-v3.f90:16:14:
16 | type(c_ptr) :: ptr
| 1
Error: Type name 'c_ptr' at (1) is ambiguous
With the patch the actual type of ptr depends on the order of the use
statements in HModule - at least this is what the fortran-dump says...
