 |
 |
On Thu, Jul 20, 2017 at 8:24 PM, Malcolm Cohen <[log in to unmask]> wrote: >>> I think that a strong case should be made that the behavior of this >>> intrinsic should be consistent with SELECT TYPE which does really end >>> up being SELECT TYPE AND KIND. > > No, this would have adverse impacts both on existing program semantics, and on performance. > What impact on performance? And how? Consider this simple program: >>>>>>>>>>>>>>>>>>> class(*), allocatable :: x class(*), allocatable :: y allocate( x, source=0.0 ) allocate( y, source=0D0 ) print *, "same_type_as( real :: x, double precision :: y ) = ", same_type_as(x, y) end >>>>>>>>>>>>>>>>>>> The compilers I am able to try all print F with above program which is only what most coders would intuitively expect as the result. But based on the original note in this thread, there is some processor out there that would disagree with this (it'll be interesting to know which one!). Can one or more of the compiler writers please chime in and indicate what "adverse impact" on performance or what "inefficiency" has been introduced into their processor as a result of having SAME_TYPE_AS effectively behave the same as SELECT TYPE? Thanks, Vipul Parekh