https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |anlauf at gcc dot gnu.org
--- Comment #19 from anlauf at gcc dot gnu.org ---
(In reply to Bernhard Reutner-Fischer from comment #18)
> (In reply to Bernhard Reutner-Fischer from comment #17)
> > (In reply to Bernhard Reutner-Fischer from comment #16)
> We can just mark the dt symbol (which is used to describe the generic
> interface) as attr.generic = 1
>
> This regtests cleanly and fixes the reported bug.
>
>
> 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. */
>
>
> i.e. it marks the dt as GENERIC, so the gmodule contents from comment #16
> become
I have reduced the failing version further for easier debugging
(it still fails on 14-trunk and on 13-branch) to the following:
module AModule
use, intrinsic :: ISO_C_BINDING, only: C_PTR
end module
module DModule
type, abstract :: DType
end type
end module
module FModule
use AModule
use DModule
implicit none
public :: FProc
private
contains
subroutine FProc(x)
class(DType), allocatable, intent(out) :: x
end subroutine
end module
module GModule
use AModule
end module
module HModule
use FModule
use, intrinsic :: ISO_C_BINDING, only: C_PTR
use GModule
implicit none
type(C_PTR) :: context
end module
I think I agree more with your thoughts in comment#16 than comment#18:
the symbol C_PTR is erroneously marked as ambiguous in module reading,
but for the wrong reason. C_PTR is an intrinsic DT and not a procedure;
so we should not mark it as "generic".
As long as a symbol from an *intrinsic module* is use-associated - either
directly or indirectly - the conflict check could trace it down to its
origin (in case it is renamed), and we would resolve this explicitly.
I haven't checked the standard about possible issues coming with renaming;
I should do that now..
