From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id DB6823858D28; Mon, 24 Apr 2023 20:14:01 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DB6823858D28
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1682367241;
	bh=j0s5SO3aWl5+Ppj7iO64m8+2t+VsTSnUuMsfE36i8M8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=hqYAbfEhz1ZEyzztk8mSSwvdMEkpALTKN6BhkeESxOGGYB3qRk+GQ5rNZz5MEB/tm
	 i9chZgA5jjL3Z1qOJQVnw5lJKHRwvrGsrMulaLvNhH/n3Eois0BAEqJk+mmPKhStV4
	 Op30blFUDGxzz9h0GM5JJ3vj/yYuRQzJNh4PhAJY=
From: "anlauf at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/103931] Type name "c_ptr" is ambiguous when
 iso_c_binding is imported both directly and indirectly
Date: Mon, 24 Apr 2023 20:14:01 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 10.2.1
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: anlauf at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-103931-4-GiBwLj0fc2@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-103931-4@http.gcc.gnu.org/bugzilla/>
References: <bug-103931-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103931

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 =3D 1
>=20
> This regtests cleanly and fixes the reported bug.
>=20
>=20
> 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 =3D 1;
>  	    }
>=20=20
>  	  /* Say what module this symbol belongs to.  */
>=20
>=20
> 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..=