(j3.2006) derived types with type parameters are different

[Robert Corbett]

Bill Long wrote:
> 
> Robert Corbett wrote:
> 
>>Aleksandar Donev wrote:
>>  
>>
>>>On Friday 25 July 2008 09:44, Bill Long wrote:
>>>
>>>    
>>>
>>>>The feature is a pain to implement, so resistance to
>>>>doing it over a different way will be very high.
>>>>      
>>>
>>>But what way does Cray do---you seemed unsure of the actual answer? Can Robert 
>>>please prepare two examples (one KIND, one non-KIND), including the mentioned 
>>>generic interface, and see if Cray and IBM actually do the same thing?
>>>Aleks
>>>    
>>
>>Here are three programs that can be used to test how
>>bounds expressions affect type equivalence.
>>Different bounds expressions can be substituted for
>>those in the derived types.
>>
>>Bob Corbett
>>
>>
>>-----------------------------------------------------------------
>>
>>       MODULE M1
>>         INTERFACE S
>>           SUBROUTINE S1(X)
>>             TYPE T(N)
>>               INTEGER, KIND :: N
>>               SEQUENCE
>>               REAL A(N+N)
>>             END TYPE
>>             TYPE(T(2)) :: X
>>           END SUBROUTINE
>>         END INTERFACE
>>         TYPE T(N)
>>           INTEGER, KIND :: N
>>           SEQUENCE
>>           REAL A(N+N)
>>         END TYPE
>>         TYPE(T(2)) :: X
>>       END
>>
>>       MODULE M2
>>         INTERFACE S
>>           SUBROUTINE S2(X)
>>             TYPE T(N)
>>               INTEGER, KIND :: N
>>               SEQUENCE
>>               REAL A(2*N)
>>             END TYPE
>>             TYPE(T(2)) :: X
>>           END SUBROUTINE
>>         END INTERFACE
>>         TYPE T(N)
>>           INTEGER, KIND :: N
>>           SEQUENCE
>>           REAL A(2*N)
>>         END TYPE
>>         TYPE(T(2)) :: X
>>       END
>>
>>       SUBROUTINE S1(X)
>>         TYPE T(N)
>>           INTEGER, KIND :: N
>>           SEQUENCE
>>           REAL A(N+N)
>>         END TYPE
>>         TYPE(T(2)) :: X
>>         PRINT *, 'CALLED S1'
>>       END
>>
>>       SUBROUTINE S2(X)
>>         TYPE T(N)
>>           INTEGER, KIND :: N
>>           SEQUENCE
>>           REAL A(2*N)
>>         END TYPE
>>         TYPE(T(2)) :: X
>>         PRINT *, 'CALLED S2'
>>       END
>>
>>       PROGRAM MAIN
>>         USE M1, ONLY: S, X
>>         USE M2, ONLY: S, Y=>X
>>         CALL S(X)
>>         CALL S(Y)
>>       END
>>  
> 
> 
> This one compiled and output:
> 
> CALLED S1
> CALLED S2

So your compiler decides that the attributes of the components
REAL A(N+N) and REAL A(2*N) are different.  I assume it uses
some form of lexical matching to decide that the bounds expressions
are different.  According to my understanding of James Xia's
description of what IBM's compiler does, if the bounds expressions
had been N and N+0 instead of N+N and 2*N, IBM's compiler would
consider the two derived types to be the same type.  What does
Cray's compiler do in that case?  What if the bounds expressions
were N+2 and N+02?

Bob Corbett