problem with f95

[roddur]

A piece of my code is compiled fine with ifort, but not with sun(hope, you will not mind putting a sun problem here)
my code while compiling with sunstudio12, gives error:

sunf95 -c  -xopenmp  thread.f90
module mthread
^      
"thread.f90", Line = 5, Column = 9: ERROR: The compiler has detected errors in module "MTHREAD". 
 No module information file will be created for this module.

type(typethread):: threadcontext
^            
"thread.f90", Line = 14, Column = 21: ERROR: Object "THREADCONTEXT" is in a common block 
and is derived-type "TYPETHREAD".  This derived-type must be a sequence type.

f90comp: 19 SOURCE LINES
f90comp: 2 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 0 ANSI
make: *** [thread.o] Error 1

the code is

!***********************************************!
!    This module is required to parallalize  !
!    mmat                    !
!***********************************************!
module mthread
use parameters

implicit none

type::typethread
real*8,dimension(lorbit,lorbit)::ap61,ap71
end type typethread

type(typethread):: threadcontext
common/context/threadcontext

!$omp     threadprivate(/context/)
end module mthread

this mthread is used in one code:

module mmat
CONTAINS
subroutine matmult(ap5,i,srl)

use kinds
use parameters
use mthread

implicit none
integer(i3),intent(in):: i!,lorbit,nrsite
integer(i3):: j,l,ii,jj,k
real*8:: sumk
real*8, dimension(lorbit,lorbit),intent(in):: ap5
real*8, dimension(lorbit,lorbit,0:nrsite),intent(inout):: srl


do j=1,lorbit
do l=1,lorbit
sumk=0.0d0
do k=1,lorbit
sumk=sumk+srl(j,k,i)*ap5(k,l)
enddo

threadcontext%ap61(j,l)=sumk
enddo
enddo

do j=1,lorbit
do l=1,lorbit
sumk=0.0d0
do k=1,lorbit
sumk=sumk+ap5(j,k)*threadcontext%ap61(k,l)
enddo
threadcontext%ap71(j,l)=sumk
enddo
enddo

do j=1,lorbit
do k=1,lorbit
srl(j,k,i)=threadcontext%ap71(j,k)
enddo
enddo

end subroutine matmult

end module mmat

but is actually working using ifort. will anybody help me specify where it is creating problem?

[TimP]

You're pushing your luck in hoping that non-standard code will work with a variety of compilers. I suspect that the advice Sun f95 gave you about SEQUENCE being required to put derived type in COMMON is correct. If gfortran gives you the same advice, you might consider filing a bug report against ifort for not putting out a warning about the SEQUENCE requirement, if it doesn't do so with -std95.
If you don't want to turn on standard warnings on account of the great number of warnings you get, that should be a clue.

[roddur]

Quoting - tim18

You're pushing your luck in hoping that non-standard code will work with a variety of compilers.

yes...i hv done it; I was not aware of SEQUENCE statement. But can you explain me why this happens? neither CHAPMAN nor f03 std give me any clue why sequence is necessary when derived data type is COMMON block element.

[TimP]

Quoting - roddur

yes...i hv done it; I was not aware of SEQUENCE statement. But can you explain me why this happens? neither CHAPMAN nor f03 std give me any clue why sequence is necessary when derived data type is COMMON block element.

According to the standard, at least in the version attached to the Windows Fortran forum:

C589 (R558) If a common-block-object is of a derived type, it shall be a sequence type (4.5.1) or a
23
type with the BIND attribute and it shall have no default initialization.
24

This implies that allowing a non-sequence derived type in COMMON is an extension which must be flagged when standards warnings are turned on.
The standard clearly categorizes COMMON, EQUIVALENCE, and SEQUENCE as storage association types. Without SEQUENCE, the compiler would be entitled to optimize a derived type with padding, or maybe even changing the storage order in a way you would never see in "legal" code.

Unless Chapman recommends this usage (hard to believe), it's understandable he wouldn't mention the restrictions on it. If he does recommend it, I'm sure some people would add that to their list of reasons to recommend against that textbook. I can imagine it opening up uglier possibilities than have occurred with COMMON in the past. A major reason for introduction of f90 was to provide better structured alternatives to COMMON.