From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5340B3858D20; Fri, 14 Apr 2023 17:21:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5340B3858D20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1681492914; bh=MnCUB0cfd80HVKgL+j03cMi5SbQR/cxeH/4AwZdpuPY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=I9fhxlpY0qjsv7vdYiYlPyCa1voqfvdRVC6aBb9GHgGLKYs2NvReDIaknDtkjN9Xb nBg2Xjo5QiNoMaVT4VwqnUkkUxPjp23kkgJVL7cJ/OyCcfzKkExVx2NKoRV90WcSD3 rAXz4daBGH6BjAZkKZDFW8A71E0kIzJNsnJ67JEI= From: "aldot at gcc dot 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: Fri, 14 Apr 2023 17:21:53 +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: aldot 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: Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103931 --- Comment #16 from Bernhard Reutner-Fischer --- > Under the assumption that we have a generic "c_ptr" in a module, we know = (?) that "c_ptr" is not ambiguous. >=20 > Is that right? When we look at gmodule (when compiled when DModule has a commented-out "use CModule"), we have: GFORTRAN module version '15' created from pr103931.F90 (() () () () () () () () () () () () () () () () () () () () () () () () () () ()) // oper interfaces () // user oper (('c_funptr' '__iso_c_binding' 2) ('c_ptr' '__iso_c_binding' 3)) // generic interfaces () // blank commons, common () // equiv () // omp_udr // now first symbols w/ generic interfaces, flavour PROCEDURE but not sub n= or function (2 'C_funptr' '__iso_c_binding' '' 1 ((DERIVED UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0 IS_BIND_C IS_C_INTEROP PRIVATE_COMP) ( (4 'c_address' (INTEGER 8 0 1 0 INTEGER ()) () () () (UNKNOWN-FL UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0) PRIVATE ())) PRIVATE ( DERIVED 2 0 1 1 VOID ()) 0 0 () () 0 () () () 2 44 0) 3 'C_ptr' '__iso_c_binding' '' 1 ((DERIVED UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0 IS_BIND_C IS_C_INTEROP PRIVATE_COMP) ((5 'c_address' (INTEGER 8 0 1 0 INTEGER ()) () () () (UNKNOWN-FL UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0) PRIVATE ())) PRIVATE (DERIVED 3 0 1 1 VOID ()) 0 0 () () 0 () () () 2 42 0) [snip] // second, symbols rest So, the ambiguous error comes from seeing C_ptr with id 3, loading that. Th= en we check if it _has_ the GENERIC attr set, but it has not, since (i think) = this very symbol is *used* to describe the type of the generic interface. I do n= ot quite see why we check_for_ambiguous for these generic interface types in t= he first place, i think that they are just not ambiguous, at least as far as i= can see in the aforementioned gmodule.mod. I'm testing a more elaborate test which keeps check_for_ambiguous in the sa= me spot as before, but in that check, looks if the symtree (C_ptr in this case, number 3) is listed in the generic interfaces after the existing check that looks if the symbol itself is GENERIC. I did not really look at the standard, so i wonder if that makes sense to somebody more familiar with that area?=