topic It is only recently that the in Intel® Fortran Compiler

Is OpenMP not supporting Fortran 2003 (PASS, Finalization, etc.)

CFM — Wed, 10 Jun 2015 13:07:25 GMT

Hi all,

My question is related to integration of OpenMP in Fortran with some features in standard 2003/2008

In the document of latest 4.0 release it is stated that some features are not supported. The problem is : such features are in my opinion very important for new Object-Oriented paradigm as introduced in new standards.

I made some simple code containing type extension and pass atribute. The OpenMP work and a get speedup of 12x. ( on 12 cores !!!)

But in other complex cases ( with multiple classes and procedures pointers) I got unexpected access violation in runtime.

Before I investigate more, is any one had similar errors with OepnMP in context of OOP paradigm of Fortran 2003/2008.

Thanks

P.S. Here is the part of text related to my post, see for details the link: http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf

!==========================================================================================

ISO/IEC 1539-1:2004, Information Technology - Programming Languages - Fortran.

This OpenMP API specification refers to ISO/IEC 1539-1:2004 as Fortran 2003. The following features are not supported:

• IEEE Arithmetic issues covered in Fortran 2003 Section 14

• Allocatable enhancement • Parameterized derived types

• Finalization

• Procedures bound by name to a type

• The PASS attribute

• Procedures bound to a type as operators

• Type extension

• Overriding a type-bound procedure

• Polymorphic entities

• SELECT TYPE construct

• Deferred bindings and abstract types

• Controlling IEEE underflow

• Another IEEE class value

Where this OpenMP API specification refers to C, C++ or Fortran, reference is made to the base language supported by the implementation

!============================================================================================================

I'm afraid you're asking in

James_C_Intel2 — Wed, 10 Jun 2015 13:18:31 GMT

I'm afraid you're asking in the wrong place. This forum is specifically for discussion of aspects of theOopenMP runtime implementation, not which language features the OpenMP compiler supports. To attract the Intel Fortran compiler folk, please ask again at https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x (though some of your queries may not even be for them since you seem to be asking about the OpenMP standard itself, not the Intel implementation. If that's so you should be asking in one of the forums at http://openmp.org/forum/ )

Thank you James!

CFM — Wed, 10 Jun 2015 13:37:00 GMT

Thank you James!

I will moved wy post there.

In this connection, ifort

TimP — Wed, 10 Jun 2015 14:49:15 GMT

In this connection, ifort documents the requirement to set /fp:strict for full implementation of IEEE Arithmetic, although some features don't depend on that (they don't tell you which). As your reference indicates, capabilities such as floating point exception handling aren't compatible with vectorization or parallelization. Those don't appear to be your primary interest, however.

It would be unusual, in my opinion, to require /fp:strict when using OpenMP. In some cases, OpenMP performance might be less than optimized single thread. You might have to divide your source files into those which use the strict features but not OpenMP and vice versa.

If you could make specific working examples of features which don't have evident reasons for problems with parallelization, you might be able to get it investigated, OpenMP does lag seriously in support of newer language features, even some which are 2 decades old. Some problems might be due simply to the lack of a requirement for testing for them.

People who aren't known to the regulars at openmp.org are likely to have their posts ignored; to a lesser extent, stackoverflow has some of that as well, but those are the forums for asking about OpenMP features independent of specific compilers. If you found something which works with gfortran but not with ifort, that would give more reason for making an ifort problem report at premier.intel.com.

If you found something in the open source code OpenMP which relates to your question, the forum where you started (or the one associated with the source code) might be suitable for asking about it. James apparently assumed you were interested in linux, as the open source works better there. With gfortran on Windows, I think you must work with the libgomp source provided with gfortran.

The general issue is that the

Steven_L_Intel1 — Wed, 10 Jun 2015 15:13:54 GMT

The general issue is that the OpenMP standard hasn't defined behavior for some of the newer language features. I wasn't aware of issues with the IEEE intrinsic modules, but it may be related to exception processing, which may not work properly in a threaded environment across all implementations. I don't recall hearing of any issues with our implementation, though.

Things such as finalization and anything that triggers "hidden" procedure calls may not be well-defined in a parallel region. Note, though, that just because OpenMP doesn't define the behavior, that doesn't mean it won't work. We'd be interested in test cases that fail.

Hi Steve, Hi all,

CFM — Thu, 11 Jun 2015 17:57:25 GMT

Hi Steve, Hi all,

The complex program was not running in parallel because some variables had SAVE attributes. In parallel mode, this generated run time errors.

Still, I am confused of the text I mentionned " The features of FORTRAN 2003 not being supported by OepnMP 4....". I will ask to the OpenMP team.

BTW, I attached a simplified file where few FORTRAN 2003 features in question are used : PASS ATTRIBUTE , TYPE EXTENSION , FINALIZATION. The code runs well with nice speedup using OpenMP.

Chuma

! test_OpenMP_pass_attributes.f90
!
! FUNCTIONS:
! test_OpenMP_pass_attributes. - Entry point of console application.
!

!****************************************************************************
!
! PROGRAM: test_OpenMP_pass_attributes.
!
! PURPOSE: Entry point for the console application.
!
!****************************************************************************
module abstr_class_module
IMPLICIT NONE
public abstr_class
type, abstract :: abstr_class
INTEGER :: ID
INTEGER , ALLOCATABLE :: data_array(:)
contains

procedure(construc_interface) , deferred, pass :: constructor
procedure(method_interface) , deferred, pass :: method

endtype abstr_class

interface

subroutine construc_interface(this, size_data_array)
import abstr_class
class(abstr_class) :: this
integer ,intent(in) :: size_data_array
endsubroutine construc_interface

subroutine method_interface(this, trunc_data)
import abstr_class
class(abstr_class) :: this
integer ,intent(in) :: trunc_data
endsubroutine method_interface

end interface

contains

endmodule abstr_class_module
!------------------------------------------------------------------
!------------------------------------------------------------------
module ext_from_abstr_class_module
use abstr_class_module

public ext_class

type, extends(abstr_class) :: ext_class

procedure(ptr_method_interface), &
pass, pointer :: ptr_method => NULL()

contains

procedure, pass :: constructor
procedure, pass :: method
procedure, pass :: method_invoking_procedure_ptr

final :: clean_and_free

endtype ext_class

interface
subroutine ptr_method_interface(this, trunc_data)
import ext_class
class(ext_class) :: this
integer ,intent(in) :: trunc_data
endsubroutine ptr_method_interface

end interface

contains
!------------------------------------------------------------------
subroutine constructor(this,size_data_array )
class(ext_class) this
integer, intent(in) :: size_data_array

allocate (this%data_array(size_data_array))! allocate data

this%ptr_method => method ! associate proc pointer

endsubroutine constructor
!------------------------------------------------------------------
subroutine method(this, trunc_data)
class(ext_class) :: this ! this calling obj
integer, intent(in):: trunc_data ! some INT to truncate data

integer :: n_data , ido

!select type(this) ! not necessary , coherence of type extension
!class is(ext_class)
n_data = size(this%data_array, 1)
this%data_array = 0
do ido = 1, n_data
this%data_array (ido) = this%data_array (ido) + trunc_data
call dummy_operations(); ! to increase loading for each thread
enddo
!endselect

endsubroutine method
!------------------------------------------------------------------
subroutine method_invoking_procedure_ptr(this, trunc_data)
class(ext_class) :: this
integer, intent(in):: trunc_data

CALL this%ptr_method(trunc_data)

endsubroutine method_invoking_procedure_ptr

!------------------------------------------------------------------
subroutine dummy_operations ! just to increase processor loading
REAL(8), ALLOCATABLE, DIMENSION (:,:) :: arr_int
INTEGER size_dummy_array, i1 , i2
REAL(8) :: INIT_REAL

INIT_REAL = 3.3
size_dummy_array = 100

ALLOCATE(arr_int(size_dummy_array,size_dummy_array))

arr_int(1,:) = (/(i2, i2=1,size_dummy_array)/)

DO i1 = 2, size_dummy_array
arr_int(i1,:) = (/(i2, i2=1,size_dummy_array)/)*(INIT_REAL) &
- arr_int(i1-1,:)
ENDDO

DO i1 = 2, size_dummy_array
arr_int = arr_int * arr_int
arr_int = arr_int / arr_int
enddo
DEALLOCATE(arr_int)
endsubroutine dummy_operations
!------------------------------------------------------------------
subroutine clean_and_free (this)
type(ext_class) :: this

deallocate(this%data_array)
NULLIFY (this%ptr_method )

endsubroutine clean_and_free

endmodule ext_from_abstr_class_module
!------------------------------------------------------------------
!------------------------------------------------------------------
program test_OpenMP_pass_attributes

use abstr_class_module
use ext_from_abstr_class_module

implicit none

type enc_abstr_class
class(abstr_class), &
pointer :: p => null()!will point to extended class
endtype

! Variables
class(abstr_class), pointer :: abs_to_ext => null()
type(enc_abstr_class), allocatable :: arr_obj (:)
integer imemo , ib
integer size_all_objs , size_data_array

size_all_objs = 1500 !3000
size_data_array = 10 !
allocate (arr_obj(size_all_objs))

!$OMP PARALLEL SHARED(arr_obj, size_all_objs)
!$OMP DO SCHEDULE(DYNAMIC,1) PRIVATE(abs_to_ext,ib)
do ib = 1, size_all_objs
allocate(ext_class::arr_obj(ib)%p)
enddo
!$OMP END DO NOWAIT
!$OMP END PARALLEL

!$OMP PARALLEL SHARED(arr_obj, size_all_objs)
!$OMP DO SCHEDULE(DYNAMIC,1) PRIVATE(abs_to_ext,ib)
do ib = 1, size_all_objs
abs_to_ext=>arr_obj(ib)%p
CALL abs_to_ext%constructor(size_data_array)
enddo
!$OMP END DO NOWAIT
!$OMP END PARALLEL

!$OMP PARALLEL SHARED(arr_obj, size_all_objs)
!$OMP DO SCHEDULE(DYNAMIC,1) PRIVATE(abs_to_ext,ib)
do ib = 1, size_all_objs
abs_to_ext=>arr_obj(ib)%p
CALL abs_to_ext%method(ib)
enddo
!$OMP END DO NOWAIT
!$OMP END PARALLEL

!VERIFY OPERATION DONE BY CALLING METHOD(), TO TEST OpenMP functions:
!ib is equal to abs_to_ext%data_array(1)
do ib = 1, size_all_objs
abs_to_ext=>arr_obj(ib)%p
IF ( ANY( abs_to_ext%data_array(:)-ib /= 0 )) THEN
print *, 'error detected: method() not properly performed'
STOP
ENDIF
print *, ib , '-th block tested : = ', abs_to_ext%data_array(1)
enddo
print *, 'all data have been correctly set'
nullify(abs_to_ext)


!verify usage of procedure pointer in OpenMP parallelized DO loop
!$OMP PARALLEL SHARED(arr_obj, size_all_objs)
!$OMP DO SCHEDULE(DYNAMIC,1) PRIVATE(abs_to_ext,ib)
do ib = 1, size_all_objs
abs_to_ext=>arr_obj(ib)%p
!CALL abs_to_ext%method(ib)
!CALL abs_to_ext%ptr_method(ib) ! error: not on abstract class
select type(abs_to_ext)
class is(ext_class)
CALL abs_to_ext%ptr_method(ib) != method(), see constructor()
endselect

enddo
!$OMP END DO NOWAIT
!$OMP END PARALLEL

!deallocate using finalization
!$OMP PARALLEL SHARED(arr_obj, size_all_objs)
!$OMP DO SCHEDULE(DYNAMIC,1) PRIVATE(abs_to_ext,ib)
do ib = 1, size_all_objs
abs_to_ext=>arr_obj(ib)%p
DEALLOCATE(abs_to_ext)
enddo
!$OMP END DO NOWAIT
!$OMP END PARALLEL

end program test_OpenMP_pass_attributes !

It is only recently that the

Steven_L_Intel1 — Thu, 11 Jun 2015 20:24:07 GMT

It is only recently that the OpenMP standard admitted to anything newer than Fortran 90. As I mentioned, not all of the F2003 features have defined behavior when combined with OpenMP. That doesn't mean you can't use them, but some aspects may not work properly in a parallel region. If you run into issues, please provide us with a test case and we'll be glad to take a look to see if we can make it work in our compiler, even though OpenMP doesn't define the behavior.

Many thanks. I will let you

CFM — Thu, 11 Jun 2015 20:30:20 GMT

Many thanks. I will let you know.