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

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


On 29 Mag, 16:03, Salvatore <sfilipp...@uniroma2.it> wrote:
> 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 <sfilippone@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

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

On 30 Mag, 08:40, robert.corb...@sun.com wrote:
> 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

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

Salvatore wrote:
> On 30 Mag, 08:40, robert.corb...@sun.com wrote:
>> 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
> 
> 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).

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.

On 30 Mag, 20:12, Craig Powers <craig.pow...@invalid.invalid> wrote:
> Salvatore wrote:
> > On 30 Mag, 08:40, robert.corb...@sun.com wrote:
> >> 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
>
> > 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).
>
> 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.

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