Silverfrost Forums

Welcome to our forums

Problem with derived types when compiling with /CHECK

28 Jun 2011 8:26 #8473

The following program generates what appears to be a spurious error when compiled with /CHECK or /CHECKMATE, but works otherwise. Module m1 defines a simple derived type, and a procedure for assigning values to the derived type. Module m2 defines a second derived type that contains the derived type from m1. The second derived type is declared as a pointer, and a subroutine is defined to assign memory, and to define an initial value.

Please advise if I am doing something invalid, or if this is a compiler problem.

MODULE m1
!
  TYPE t1
     INTEGER :: i
  END TYPE t1
!
  INTERFACE ASSIGNMENT(=)
     MODULE PROCEDURE s1
  END INTERFACE
!
CONTAINS
!
 SUBROUTINE s1 (t,j)
!
  INTEGER, INTENT(IN) :: j
  TYPE(t1), INTENT(OUT) :: t
!
  t%i=j
!
 END SUBROUTINE s1
!
END MODULE m1
!
!
MODULE m2
!
 USE m1
!
 TYPE t2
  TYPE(t1) :: t
 END TYPE t2
!
 TYPE(t2), POINTER, PUBLIC :: tt(:)=>NULL()
!
CONTAINS
!
 SUBROUTINE s2 (tt)
  TYPE(t2), POINTER :: tt(:)
  ALLOCATE (tt(1))
  tt(1)%t=1
 END SUBROUTINE s2
!
END MODULE m2
!
!
PROGRAM p
!
 USE m2
!
 CALL s2 (tt)
!
END PROGRAM p
28 Jun 2011 11:52 #8476

If 'tt' is a pointer, is the statement 'tt(1)%t=1 ' a valid statement ?

28 Jun 2011 4:39 #8480

I have declared tt as a pointer because I want an allocatable array that is assigned memory in a subroutine, and retains that memory for use later. The size of the array is not known a priori, and so in my actual program the size of the array is passed as an argument. In the example program I simply assign the array to have dimension 1, just to simplify the program for identifying the error, but in my original program there is an additional argument to s2 that defines the intended dimension of tt.

Regardless of my intention, I am not sure of the answer to your question!

29 Jun 2011 7:20 #8482

/check appears to be failing to work for the INTERFACE ASSIGNMENT(=). I guess it is one of those special situations that has never been tested.

In the short term you will need to either a) avoid /check in this locality or b) use the default 'equals' rather than your over-ride of 'equals' [i.e. use tt(1)%t%i=42].

Please login to reply.