This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, fortran] PR37274 - [Regression] error: type name is ambiguous and PR36374 - nested module inclusion fails
- From: Salvatore Filippone <salvatore dot filippone at uniroma2 dot it>
- To: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- Cc: Fortran List <fortran at gcc dot gnu dot org>
- Date: Thu, 04 Sep 2008 10:56:44 +0200
- Subject: Re: [Patch, fortran] PR37274 - [Regression] error: type name is ambiguous and PR36374 - nested module inclusion fails
- References: <339c37f20809040135v71f39be8v52837a01a4bac348@mail.gmail.com>
- Reply-to: salvatore dot filippone at uniroma2 dot it
Il giorno gio, 04/09/2008 alle 10.35 +0200, Paul Richard Thomas ha
scritto:
+ /* If the existing symbol is generic and from a different module,
+ there can be no ambiguity. */
+ if (st_sym->attr.generic
+ && st_sym->module
+ && strcmp (st_sym->module, module_name))
+ return false;
+
+ return true;
+}
Hmmmm. Forgive me if I'm being naive, but just by reading the patch
code, and not knowing the rest, I am not sure what happens in case of a
real ambiguity, such as trying to add to the same generic two different
routines that use indistinguishable arguments. Could you ease my concern
and confirm that they are resolved in the following mini-example?
module s_foo_mod
interface foobar
subroutine s_foobar(x)
real(kind(1.e0)), intent (inout) :: x
end subroutine s_foobar
end interface
end module s_foo_mod
module r_foo_mod
interface foobar
subroutine r_foobar(x)
real, intent (inout) :: x
end subroutine r_foobar
end interface
end module r_foo_mod
use s_foo_mod
use r_foo_mod