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

[CFM]

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

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

[James_C_Intel2]

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/ )

[CFM]

Thank you James!

I will moved wy post there.

[TimP]

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.

[Steven_L_Intel1]

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.

[CFM]

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  !

[Steven_L_Intel1 · Accepted solution]

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.

[CFM]

Many thanks. I will let you know.