[Bug fortran/103931] New: Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[Bug fortran/103931] New: Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[trnka at scm dot com]

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

            Bug ID: 103931
           Summary: Type name "c_ptr" is ambiguous when iso_c_binding is
                    imported both directly and indirectly
           Product: gcc
           Version: 10.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: trnka at scm dot com
  Target Milestone: ---

Created attachment 52135
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52135&action=edit
full testcase demonstrating the bug

Compiling the attached test case fails for me on gfortran 11.2.1 20210728 (Red
Hat 11.2.1-1):

$ gfortran -c gcc-ambiguous-cptr.f90
gcc-ambiguous-cptr.f90:97:19:

   97 |       type (C_PTR) :: context
      |                   1
Error: Type name ‘c_ptr’ at (1) is ambiguous

(Sorry for the convoluted module structure, I can't seem to reduce it further
without making the issue disappear.)

The issue occurs in this piece of code:

   subroutine HProc()
      use FModule
      use ISO_C_BINDING
      use GModule

      type (C_PTR) :: context
   end subroutine

Here, both FModule and GModule use ISO_C_BINDING indirectly in different ways,
so their module files contain c_ptr which gets picked up. Apparently, c_ptr
then gets marked as ambiguous by check_for_ambiguous() in
module.c:read_module() while reading GModule.

After compiling it once as above to generate all the modules, you can add "-cpp
-DNODEPS=1" for further testing to focus on the problematic part (using
existing module files).

Strangely enough, gfortran 9.3.1 20200804 compiles the test without errors when
compiling everything but fails with the above error with NODEPS. gfortran 11
fails in both modes. Not sure if that counts as a regression or if it's just a
random coincidence. I can bisect that if desired.

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |dominiq at gcc dot gnu.org,
                   |                            |jaydub66 at gmail dot com,
                   |                            |markeggleston at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org
   Last reconfirmed|                            |2022-01-06

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
I can confirm that it's been accepted on GCC 9 since
r9-8584-g5a17beaecadf10d1c9c44d2b31eedc11dfdea35a which was supposed to be a
backport.

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[anlauf at gcc dot gnu.org]

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Created attachment 52138
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52138&action=edit
Somewhat reduced reproducer

The issue can be reproduced with a few less modules

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |9.2.0, 9.3.0, 9.4.0

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #1)
> I can confirm that it's been accepted on GCC 9 since
> r9-8584-g5a17beaecadf10d1c9c44d2b31eedc11dfdea35a which was supposed to be a
> backport.

The released version of GCC 9.4.0 still reject it ...

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Also it looks like it is only intrinsic module ISO_C_BINDING which is showing
this issue. I tried defining a new module T which had a type of yy and replace
ISO_C_BINDING with T and C_PTR with yy (and remove intrinsic) and it worked.

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[trnka at scm dot com]

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

--- Comment #5 from Tomáš Trnka <trnka at scm dot com> ---
(In reply to anlauf from comment #2)
> Created attachment 52138 [details]
> Somewhat reduced reproducer
> 
> The issue can be reproduced with a few less modules

FWIW, this reduced testcase doesn't reproduce the bug (compiles cleanly) on my
11.2.1.

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Tomáš Trnka from comment #5)
> FWIW, this reduced testcase doesn't reproduce the bug (compiles cleanly) on
> my 11.2.1.

But it does on the trunk, hmmm.

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Tomáš Trnka from comment #5)
> > FWIW, this reduced testcase doesn't reproduce the bug (compiles cleanly) on
> > my 11.2.1.
> 
> But it does on the trunk, hmmm.

the reduced testcase works in GCC 10.1.0, 10.2.0, 10.3.0, 11.1.0, and 11.2.0.
maybe there is some kind of memory issue even.

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldot at gcc dot gnu.org,
                   |                            |pault at gcc dot gnu.org

--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
> the reduced testcase works in GCC 10.1.0, 10.2.0, 10.3.0, 11.1.0, and 11.2.0.
> maybe there is some kind of memory issue even.

I guess so as it's rejected with r12-5073-g8875a92d31329ae5 which is a memory
leak fix. Note that before that it was accepted since
r10-2912-g70570ec192745095.

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[anlauf at gcc dot gnu.org]

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> Created attachment 52138 [details]
> Somewhat reduced reproducer
> 
> The issue can be reproduced with a few less modules

The reduced testcase compiles for me with today's 13-trunk, but not 12-branch.
However, the full original testcase fails with varying errors depending on the
gfortran version.

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[aldot at gcc dot gnu.org]

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

--- Comment #10 from Bernhard Reutner-Fischer <aldot at gcc dot gnu.org> ---
(In reply to anlauf from comment #9)
> The reduced testcase compiles for me with today's 13-trunk, but not
> 12-branch.
> However, the full original testcase fails with varying errors depending on
> the
> gfortran version.

Does the full testcase compile on trunk, with d7caf313525a, i assume?

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[aldot at gcc dot gnu.org]

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

--- Comment #11 from Bernhard Reutner-Fischer <aldot at gcc dot gnu.org> ---
(In reply to Bernhard Reutner-Fischer from comment #10)
> (In reply to anlauf from comment #9)
> > The reduced testcase compiles for me with today's 13-trunk, but not
> > 12-branch.
> > However, the full original testcase fails with varying errors depending on
> > the
> > gfortran version.
> 
> Does the full testcase compile on trunk, with d7caf313525a, i assume?

Both the original testcase as well as the reduced testcase from comment #2
compile fine for me with trunk from earlier today at r13-6974-g802ab7d0db5b5a

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[anlauf at gcc dot gnu.org]

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

--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Bernhard Reutner-Fischer from comment #11)
> Both the original testcase as well as the reduced testcase from comment #2
> compile fine for me with trunk from earlier today at r13-6974-g802ab7d0db5b5a

The behavior of gfortran is very fragile.

Consider the original testcase.  Module CModule has no public symbols.
Technically, the "use CModule" in module DModule should not have any effect.
(Confirmed by other brands).  However, commenting the "use CModule" reproduces
the original error message.

This PR may be a duplicate of others that describe gfortran's confusion
when using (intrinsic) modules along a module chain like here.
Just try running gfortran under valgrind.

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[aldot at gcc dot gnu.org]

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

--- Comment #13 from Bernhard Reutner-Fischer <aldot at gcc dot gnu.org> ---
(In reply to anlauf from comment #12)

> Consider the original testcase.  Module CModule has no public symbols.
> Technically, the "use CModule" in module DModule should not have any effect.
> (Confirmed by other brands).  However, commenting the "use CModule"
> reproduces
> the original error message.

Ok, i see. Thanks for the enlightenment :)

First and foremost, re-instating the class finalization memory leak cited in
comment #8 does not help, as expected.
At first i thought that we might look in the wrong namespace, but that does not
seem the case.

I'm testing a patch.

> 
> This PR may be a duplicate of others that describe gfortran's confusion
> when using (intrinsic) modules along a module chain like here.

There are 50 bugs with "module" in the description, i should go through them to
see if there are similar cases. Or do you by chance remember a specific one in
that area?

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[anlauf at gcc dot gnu.org]

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

--- Comment #14 from anlauf at gcc dot gnu.org ---
(In reply to Bernhard Reutner-Fischer from comment #13)
> > This PR may be a duplicate of others that describe gfortran's confusion
> > when using (intrinsic) modules along a module chain like here.
> 
> There are 50 bugs with "module" in the description, i should go through them
> to see if there are similar cases. Or do you by chance remember a specific
> one in that area?

IIRC the bug could to be connected to the "USE" of intrinsic modules,
e.g. pr66973.

There should be another one where intrinsic modules and BLOCK are used,
but I have to look for it.

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[aldot at gcc dot gnu.org]

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

--- Comment #15 from Bernhard Reutner-Fischer <aldot at gcc dot gnu.org> ---
(In reply to Bernhard Reutner-Fischer from comment #13)

> I'm testing a patch.

I have to admit that this is a mess.

It's even more frustrating now as i did some preparatory cleanup for at least
some of the inconveniences in that area a while ago but never got to apply
these. Anyway.

Not sure if the following would be correct:

Under the assumption that we have a generic "c_ptr" in a module, we know (?)
that "c_ptr" is not ambiguous.

Is that right?

From what i see from a quick glance, we seem to write more symbols to the
module files than strictly needed, and that does not really help the case.

Short of a broader fix, a quick-hack to avoid the error about ambiguous
intrinsic built-in symbols might be to (*cough*):

--- a/gcc/fortran/module.cc
+++ b/gcc/fortran/module.cc
@@ -5320,6 +5322,11 @@ check_for_ambiguous (gfc_symtree *st, pointer_info
*info)
        return false;
     }

+  /* A symbol from an intrinsic module is not ambiguous.  */
+  /* This should not be necessary, at least not in this form!  */
+  if (st_sym->from_intmod != INTMOD_NONE)
+    return false;
+
   return true;
 }


This works as expected, fixes this specific PR and tests cleanly.
Should i propose this workaround as a patch or is it a bit too gross?
WDYT?

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[aldot at gcc dot gnu.org]

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?

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[aldot at gcc dot gnu.org]

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

--- Comment #17 from Bernhard Reutner-Fischer <aldot at gcc dot gnu.org> ---
(In reply to Bernhard Reutner-Fischer from comment #16)

> 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.

This highlights cases like in use_24.f90 and use_27.f90 and requires follow-up
changes that i'm not entirely comfortable with.

> 
> I did not really look at the standard, so i wonder if that makes sense to
> somebody more familiar with that area?

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[aldot at gcc dot gnu.org]

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

--- Comment #18 from Bernhard Reutner-Fischer <aldot at gcc dot gnu.org> ---
(In reply to Bernhard Reutner-Fischer from comment #17)
> (In reply to Bernhard Reutner-Fischer from comment #16)
> 
> > 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.
> 
> This highlights cases like in use_24.f90 and use_27.f90 and requires
> follow-up changes that i'm not entirely comfortable with.

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
...
(('c_funptr' '__iso_c_binding' 2) ('c_ptr' '__iso_c_binding' 3)) // generic
interfaces
...
(2 'C_funptr' '__iso_c_binding' '' 1 ((DERIVED UNKNOWN-INTENT
UNKNOWN-PROC UNKNOWN UNKNOWN 0 0 GENERIC 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 GENERIC 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)

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[anlauf at gcc dot gnu.org]

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..

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[anlauf at gcc dot gnu.org]

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...

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[aldot at gcc dot gnu.org]

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

--- Comment #21 from Bernhard Reutner-Fischer <aldot at gcc dot gnu.org> ---
(In reply to anlauf from comment #19)

> C_PTR is an intrinsic DT and not a procedure;
> so we should not mark it as "generic".

Ok, that makes sense indeed.

> 
> 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 think renaming works. Let's concentrate on a case without renaming first.
I'll have another look now.

Btw, there is also module == "(intrinsic)" which we might want to reconsider
nowadays, but that is for another day.

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

[anlauf at gcc dot gnu.org]

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

--- Comment #22 from anlauf at gcc dot gnu.org ---
Here another invalid example which ICEs because the clash is not detected:

module AModule
  implicit none
  type, bind(C) :: c_ptr
     private
     integer(8) :: c_address
  end type c_ptr
end module

module GModule
  use AModule, only: C_PTR
  use, intrinsic :: ISO_C_BINDING, only: C_PTR
  implicit none
  type(c_ptr) :: ptr
end module

This hits an assert a few lines above the place you looked at...
(Interchanging the use statements helps here.)