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

--- Comment #16 from Bernhard Reutner-Fischer <aldot at gcc dot gnu.org> ---
> Under the assumption that we have a generic "c_ptr" in a module, we know (?) 
> that "c_ptr" is not ambiguous.
> 
> 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 nor
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. Then
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 not
quite see why we check_for_ambiguous for these generic interface types in the
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 same
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?

Reply via email to