Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28457 Discussions

OpenMP with select type construct

RonanV
Beginner
816 Views

Hello,

Our intel compiler version is 19.0.3.199 and I have met some troubles when combining OpenMP and a select type declaration. When trying to replicate the hypothetical bug in a shorter program (see attached file), I encountered two other possible bugs.

The starting point is a structure with a polymorphic component.

  • 1st issue: if the component is declared allocatable and if the variable corresponding to the created structure is declared PRIVATE in the OPENMP PARALLEL statement, there is an internal compiler error.
  • 2nd issue: if the variable is declared FIRSTPRIVATE instead (as invited in other posts), a segmentation fault takes place later during the allocation of the variable's component.

Somehow, I had to declare the structure's component as a pointer in this short program although I did not meet this issue in my original, and much larger, program. The third issue corresponds to the one that confused me in the first place:

  • 3rd issue: the select type crashes because of the associated name 'ptr => ...' . When compiling without openmp, everything is fine. I also tried to explicitly declare a polymorphic pointer to remove the association feature but without success... The only successful trick was to move the bunch of lines in a separate subroutine.

I also tried another compiler (GNU Fortran v10.1) that did not present any of the three mentioned issues.

Thank you for your feedback.

 

0 Kudos
5 Replies
Johannes_Rieke
New Contributor III
787 Views

Hi RonanV,

I cannot help much, but only point to the OpenMP specification 4.5, which is currently supported by PSXE 2019/2020.

On page 22 it says, that select type is NOT supportet.

OpenMP 5.0 seems to support it, since it is not listed on page 33.

For the bug 1 related ICE you should open a ticket.

Dear Intel team, if you read that: Please give us information, which version of the compiler supports which OpenMP feature or what are the limitations. In different threads I read and commented that it is hard to get any information about compatability of Fortran feeatures from F2003 up to F2018 with OpenMP. E.g. although submodules are officially not supported by OpenMP 5.0 (look in the speck above), submodules work with Intel Fortran PSXE2019/2020. The information one finds here is not sufficient.

 

0 Kudos
Barbara_P_Intel
Moderator
768 Views

Here is some additional information about OpenMP features by compiler version.

0 Kudos
Johannes_Rieke
New Contributor III
754 Views

Dear Barbara, many thanks for the link to the information what OMP features are supported from which compiler version.

However, I had in mind, that a list similar to this, but the other way round, would be helpful.

E.g.:

  • 19.1 supports submodules with OMP 5.0, although the OMP 5.0 does not officially supports submodules.
  • OMP 4.5 does not support 'select type' but OMP 5.0 does. Does 19.1 supports 'select type'?

Currently we have to test on our own, whether Fortran features as 'select type' are supported and further working correctly. That is making the use of OMP very tricky, especially if you like to benefit from new Fortran features.

ps: My statement in the post above, seems to be unprecise: 19.1 seems to support OMP specification 5.0 to a certain grade, too. Not only OMP 4.5.

0 Kudos
Barbara_P_Intel
Moderator
739 Views

Thanks for the feedback.  I'll see what can be done.

 

0 Kudos
RonanV
Beginner
728 Views

Thanks for your messages.

So far, it is not clear whether all three bugs are fixed in v19.1 or if they should be in a later version.

Regarding bug 3, the OPENMP - select type combination is handled correctly when the construct is declared in a separate subroutine (still populated with multiple threads). There is then some support of the feature. It is not clear if full support is intended (and if there is indeed a bug). If not, the compiler should send an explicit error message to prevent this usage until future support.

I am also interested in a workaround different than moving everything in a separate subroutine if possible. 

0 Kudos
Reply