topic Re: OpenMP support in Intel® Fortran Compiler

OpenMP support

Mark_Lewy — Thu, 06 Jul 2023 08:03:46 GMT

https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2023-1/openmp-support.html claims Intel Fortran in OneAPI 2023.1 supports OpenMP 5.0 TR4 with some parts of OpenMP 5.1.

From the normative references in 5.0 TR4:

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
– Parameterized derived types
– The PASS attribute
– Procedures bound to a type as operators
– Overriding a type-bound procedure
– Polymorphic entities
– SELECT TYPE construct
– Deferred bindings and abstract types
– Controlling IEEE underflow
– Another IEEE class value

From the normative references in 5.1:

This OpenMP API specification refers to ISO/IEC 1539-1:2018 as Fortran 2018. While future
versions of the OpenMP specification are expected to address the following features, currently
their use may result in unspecified behavior.
– Declared type of a polymorphic allocatable component in structure constructor
– SELECT RANK construct
– IEEE comparison predicate in intrinsic relational operators
– Finalization of an allocatable subobject in intrinsic assignment
– Locality of variables in a DO CONCURRENT construct
– IMPORT statement extensions
– Assumed-rank dummy argument
– Assumed-type dummy argument
– Interoperable procedure enhancements
– ASYNCHRONOUS attribute enhancement

What does OneAPI 2023.1 actually support, in terms of Fortran standards?

Re: OpenMP support

Barbara_P_Intel — Thu, 06 Jul 2023 10:43:03 GMT

@Mark_Lewy, have you seen this article with OpenMP info for ifx?

Re: OpenMP support

Mark_Lewy — Thu, 06 Jul 2023 12:06:09 GMT

@Barbara_P_IntelI had a look at the article, but it doesn't answer the question I posed originally, which is what Fortran standard does the Intel OneAPI 2023.1 OpenMP implementation target and what exceptions (if any) are there?

Re: OpenMP support

Ron_Green — Thu, 06 Jul 2023 23:08:53 GMT

@Mark_Lewy we follow the OMP Standard, and have the same restrictions as you cited above for F2003 and F2018. We do not go beyond the OMP spec for additional features or extending support. For example, you cannot offload coarray objects. Other examples, intrinsics: you cannot offload many of the Fortran Runtime library functions. IO is a prime example. Date/time functions. File operations.

Does any other vendor or open source Fortran compiler have a table of Fortran features from 2018 and if those are allowed in OpenMP regions? We do not have such a list. If you have an example of what you would like to see from us, let us know and we can work on creating such a table for our OpenMP implementation.

Re: OpenMP support

Mark_Lewy — Fri, 07 Jul 2023 07:36:51 GMT

@Ron_GreenUnderstood. What's not clear to me is whether the current version of OpenMP in OneAPI is following 5.0 TR4 and hence Fortran 2003 or 5.1 and hence Fortran 2018. Our code uses some Fortran 2008 and some of the unsupported features of Fortran 2003 in OpenMP regions, so I want to confirm that any odd behaviour we may observe is because we are not following the standard (whatever that is). For example, we have some OpenMP regions that fail with an access violation in omp_set_lock() in debug builds.

do ilink = 1, n_links link_ => iw2d_1D_data%get_ld_link(model_index, ilink) call link_%slot_data%ver_conn%process_flow_into_twod(input_dt) end do

link_ is declared as class(iw2d_1D_object), pointer :: link_, so is this an unsupported polymorphic entity according to 5.0 TR4?

Re: OpenMP support

Ron_Green — Wed, 12 Jul 2023 17:45:11 GMT

@Mark_Lewy we had a look at this in our team meeting today.

Line 2 - is something we do not support currently. A reproducer would help us evaluate the difficulty needed to support this, and whether we should adhere to 5.0 TR4 or extend our implementation to support this usage. Can you create a reproducer for us, or is it too much work? The question is, since it may not be allowed by 5.0 TR4, even if we accept it someday, will other vendors do the same?

Re: OpenMP support

Mark_Lewy — Thu, 13 Jul 2023 08:27:03 GMT

Thanks @Ron_Green, I'll see what I can do about a reproducer, might be a while as I'm busy with other stuff and this is deep inside some commercial code and doesn't always trip an access violation. As for 5.0 TR4, I would hope that Intel will at some point support OpenMP 5.1 fully or the latest 5.2 spec, in which case this code should be valid. As for other vendors, this isn't an issue for us, as we only support x64 Windows and Linux, and use OneAPI only, but GNU Fortran "strives" to be compatible with OpenMP 4.5 (https://gcc.gnu.org/onlinedocs/gfortran/OpenMP.html).

As a suggestion, it would be good if the compiler produced diagnostics when the user was using non-standard (unsupported) features in OpenMP.

For the time being, I have made the offending regions serial in debug builds; we haven't noticed any unexpected results in release builds.

Re: OpenMP support

jimdempseyatthecove — Thu, 13 Jul 2023 13:00:34 GMT

FWIW, does it work to replace => with ASSOCIATE?

do ilink = 1, n_links associate (link_ => iw2d_1D_data%get_ld_link(model_index, ilink)) call link_%slot_data%ver_conn%process_flow_into_twod(input_dt) end associate end do

Jim Dempsey

Re: OpenMP support

Mark_Lewy — Thu, 13 Jul 2023 13:12:50 GMT

@jimdempseyatthecoveGood point - I have had issues with OpenMP loops and ASSOCIATE in the past, where the associate names were treated as SHARED OpenMP variables in debug builds. I'll try experimenting again and report back here. One other possible option would be to factor out the loop body into a separate SUBROUTINE.

Re: OpenMP support

jimdempseyatthecove — Thu, 13 Jul 2023 14:06:35 GMT

>> I have had issues with OpenMP loops and ASSOCIATE in the past, where the associate names were treated as SHARED OpenMP variables in debug builds.

An issue I've had with OpenMP loops and ASSOCIATE in the past was when the ASSOCIATE name/variable was not declared outside of the parallel region. While the associate name replaces the outer scope/region name, the lack of an outer scope name generated an error.

I haven't noticed a shared issue (or implicit SAVE issue).

Another work around is to use a contained procedure:

subroutine ... ... do ilink = 1, n_links call do_link(iw2d_1D_data%get_ld_link(model_index, ilink)) end do ... return contains subroutine do_link(link) class(iw2d_1D_object) :: link call link%slot_data%ver_conn%process_flow_into_twod(input_dt) end subroutine do_link end subroutine ...

Jim Dempsey