RFC resolving typespecs of the kind "typespec function ...."
Paul Richard Thomas
paul.richard.thomas@gmail.com
Tue Dec 18 18:03:00 GMT 2007
Tobias,
> Otherwise, attached are some challenging test cases. Except of b1, where
> I and NAG f95 disagree, they all compile with NAG f95.
> Both fail with g95, ifort 9.1 and gfortran at several places. (I run out
> of time of creating invalid examples.)
Thanks a heap! Between you and Dominique, you are ruining my beauty sleep:)
I made a lot of progress today, both with the original PRs and the
tests below. None of them really work but I am beginning to
understand why they don't. With your testcases, I have reached the
point where the function characteristics are correctly set but then
the derived types disappear. I realised on the drive home that this
is probably because the derived type is not being set as referenced.
Cheers
Paul
>
> If I can do something regarding this topic, say so.
>
> The standard says the following; I think it is not 100% clear about the
> order, but I would expect the order is the same as usual, i.e.
> use-associated or declared in the procedure has a higher precedence than
> host-associated.
>
>
> "5.1.2.10 PARAMETER attribute
> [...]
> A named constant shall not be referenced unless it has been defined previously
> in the same statement, defined in a prior statement, or made accessible by use
> or host association."
>
>
>
> "5.1.1.1 TYPE
> [...]
> Where a data entity is declared explicitly using the TYPE type specifier, the
> specified derived type shall have been defined previously in the scoping unit
> or be accessible there by use or host association. If the data entity is a
> function result, the derived type may be specified in the FUNCTION statement
> provided the derived type is defined within the body of the function or is
> accessible there by use or host association. If the derived type is specified
> in the FUNCTION statement and is defined within the body of the function, it is
> as if the function result variable was declared with that derived type
> immediately following the derived-type-def of the specified derived type."
>
>
> Tobias
>
> module m1
> integer :: hh
> type t
> real :: r
> end type t
> end module m1
>
> module m2
> type t
> integer :: k
> end type t
> end module m2
>
> type(t) function a()
> use m1, only: hh
> type t2
> integer :: j
> end type t2
> type t
> logical :: b
> end type t
> a%b = .true.
> end function a
>
> type(t) function b()
> use m1, only: hh
> use m2
> b%k = 5
> end function b
>
> type(t) function c()
> use m1, only: hh
> type t2
> integer :: j
> end type t2
> type t
> logical :: b
> end type t
> c%b = .true.
> end function c
>
> program main
> type t
> integer :: m
> end type t
> contains
> type(t) function a1()
> use m1, only: hh
> type t2
> integer :: j
> end type t2
> type t
> logical :: b
> end type t
> a1%b = .true.
> end function a1
>
> type(t) function b1()
> use m1, only: hh
> use m2, only: t
> ! NAG f95 believes that the host-associated type(t)
> ! should be used:
> ! b1%m = 5
> ! However, I believe that the use-associated one should
> ! be used:
> b1%k = 5
> end function b1
>
> type(t) function c1()
> use m1, only: hh
> type t2
> integer :: j
> end type t2
> type t
> logical :: b
> end type t
> c1%b = .true.
> end function c1
>
> type(t) function d1()
> d1%m = 55
> end function d1
>
> end program main
>
> module m1
> integer, parameter :: i1 = 1, i2 = 2
> end module m1
>
> module m2
> integer, parameter :: i1 = 8
> end module m2
>
> integer(i1) function three()
> use m1, only: i2
> use m2
> three = i1
> if(three /= kind(three)) call abort()
> end function three
>
> program main
> implicit none
> interface
> integer(8) function three()
> end function three
> end interface
> integer, parameter :: i1 = 4
> integer :: i
> i = one()
> i = two()
> if(three() /= 8) call abort()
> contains
> integer(i1) function one()
> if (kind(one) /= 4) call abort()
> one = 1
> end function one
> integer(i1) function two()
> use m1, only: i2
> use m2
> if (kind(two) /= 8) call abort()
> two = 1
> end function two
> end program main
>
>
--
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy
More information about the Fortran
mailing list