Re: A question concerning ambiguous interfaces involving unlimited polymorphic formal arguments

[Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>]

Dear All,

I think that I have answered my own question. From the F2008 standard:

4.3.1.3
CLASS
1 The CLASS type specifier is used to declare polymorphic entities. A
polymorphic entity is a data entity that is
....snip....
3 An entity declared with the CLASS(*) specifier is an unlimited
polymorphic entity. An unlimited polymorphic entity is not declared to
have a type. It is not considered to have the same declared type as
any other entity, including another unlimited polymorphic entity.
4 A nonpolymorphic entity is type compatible only with entities of the
same declared type. A polymorphic entity that is not an unlimited
polymorphic entity is type compatible with entities of the same
declared type or any of its extensions. Even though an unlimited
polymorphic entity is not considered to have a declared type, it is
type compatible with all entities. An entity is type compatible with a
type if it is type compatible with entities of that type.

and

C.9.6
3 Although the declared type of a data entity is a fixed property,
polymorphic variables allow for a limited degree of type mismatch
between dummy arguments and actual arguments, so the requirement for
distinguishing two dummy arguments is type incompatibility, not merely
different types. (This is illustrated in the BAD6 example later in
this note.)

Since from 4.3.1.3, CLASS(*) is type compatible with all entities and
distinguishing arguments requires type incompatibility, I would say
that gfortran is correct in flagging up ambiguity between CLASS(*)
dummy arguments and any other types in the PGI example.

Cheers

Paul

On 1 March 2015 at 13:07, Paul Richard Thomas
<paul.richard.thomas@gmail.com> wrote:
> Dear All,
>
> Jerry found that the example of OOP given in the PGI Insider will not
> compile with gfortran because it does not distinguish unlimited
> polymorphic formal arguments from any other type or kind. This is
> trapped at interface.c:487;
>
>
>   if (ts1->type == BT_CLASS
>       && ts1->u.derived->components->ts.u.derived->attr.unlimited_polymorphic)
>     return 1;
>
> On removing this, gfortran is happy with the example.
>
> Otherwise, 'addValue has to be removed from the generic 'add' and
> called explicitly from each of the other generics subroutines.
>
> I am unable to find any enlightenment in the F2003 standard as to
> which is correct.
>
> Does anybody know how this should be resolved?
>
> Cheers
>
> Paul



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx