Is this legal?

[Salvatore]

Hi,
subject says all: is the attached code legal? two compilers accept it,
one does not.

Thanks
Salvatore
---------------------------------------- usemod2.f90
-------------------
module s_type_mod
type s_foo_type
real(kind(1.e0)), allocatable :: v(:)
end type s_foo_type
end module s_type_mod
module s_foo_mod
use s_type_mod
interface foobar
subroutine s_foobar(x)
use s_type_mod
type(s_foo_type), intent (inout) :: x
end subroutine s_foobar
end interface
end module s_foo_mod

module d_type_mod
type d_foo_type
real(kind(1.d0)), allocatable :: v(:)
end type d_foo_type
end module d_type_mod

module d_foo_mod
use d_type_mod

interface foobar
subroutine d_foobar(x)
use d_type_mod
type(d_foo_type), intent (inout) :: x
end subroutine d_foobar
end interface
end module d_foo_mod

module foo_mod
use s_foo_mod
use d_foo_mod
end module foo_mod

subroutine s_foobar(x)
use foo_mod, protect => s_foobar
type(s_foo_type), intent (inout) :: x

if (.not.allocated(x%v)) allocate(x%v(10))
end subroutine s_foobar

subroutine d_foobar(x)
use foo_mod, protect => d_foobar
type(d_foo_type), intent (inout) :: x

if (.not.allocated(x%v)) allocate(x%v(10))
end subroutine d_foobar

program test
use foo_mod
type(d_foo_type) :: z

call foobar(z)

end program test

[Salvatore]

Before someone asks, the error is about the renaming of the specific
versions of foobar
as in

use foo_mod, protect => s_foobar

all three compilers support ALLOCATABLEs in derived types as per
tr15581
Thanks

[Richard Maine]

Salvatore <sfili...@uniroma2.it> wrote:

> Before someone asks, the error is about the renaming of the specific
> versions of foobar

Yes, I was going to ask. Without that, it simply wasn'y worth my time to
try to guess what someone might think was illegal.

> > subject says all: is the attached code legal? two compilers accept it,
> > one does not.

I see nothing wrong with it. Nor can I particularly think of any reason
why it would even be questionable. Prevention of name conflicts is one
of the things renaming is for.

There aren't any special rules related to specific procedure names that
would prohibit this. It is reasonably common to not make specific names
public at all. Some people might misunderstand that and think that would
prohibit use of the specific, but it doesn't. It just prohibits use of
the specific by that name; it has no affect on use by the generic name.
But anyway, that's not what you are doing. Its just an alternate way to
do something simillar.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

[robert....@sun.com]

On May 29, 7:07 am, Salvatore <sfilipp...@uniroma2.it> wrote:
> Before someone asks, the error is about the renaming of the specific
> versions of foobar
> as in
> use foo_mod, protect => s_foobar

Can you provide the text of the error message?

Bob Corbett

[Salvatore]

Actually the culprit is gfortran, the error message is
Error: Name 'foobar' at (1) is an ambiguous reference to 'foobar' from
module 's_foo_mod'

At first I thought it was about the renaming, but it seems to be
something more fundamental; anyway there is nothing ambiguous in this
example (at least, nothing that I can see, and Richard Maine seems to
think the same).

Thanks
Salvatore Filippone

[Craig Powers]

Which version of gfortran? I know that there have been some hiccups
with handling ambiguity (or lack of some) properly, so you may have run
into a bug which was fixed in 4.3 or newer.

[Salvatore]

It's in both 4.3.0 and in the development snapshot. The issue has
already been notifed to the GCC/gfortran crew.
Salvatore