Slightly Misbehaving OpenMP implementation?

[zimmer__don]

Using Intel Visual Fortran Professional 11.1.038, the attached code demonstrates an issue (crash)I've encountered with the OpenMP PRIVATE clause relating to treatment of ALLOCATABLE variables. From what I can tell, the Intel implementation does not follow the OMP API in this instance. Further info ascomments in code.

Don.

[IanH]

It might be a question of "which OpenMP spec". In your code you have comments about the OpenMP 3.0 API. The Intel Fortran help docs under the "OpenMP* Fortran Compiler Directives" page talk about supporting "Version 1.1 and most of Version 2.0", which is not a very specific way of specifying a specification, but frankly I don't know enough about OpenMP to know whether that matters and perhaps the help is out of date.

The 1.1 and 2.0 specs have words "An allocatable array declared PRIVATE must have an allocation status of not currently allocated on entry to and on exit from the construct." I think your example violates that, but would appreciate clarification because this has caused issues for me too.

IanH

[jimdempseyatthecove]

Try something along the line of

[cpp]    SUBROUTINE TEST ( NX, NY )

    INTEGER, INTENT(IN) :: NX, NY
    INTEGER             :: I
    REAL, ALLOCATABLE   :: ARR(:)


!$OMP PARALLEL PRIVATE (ARR) COPYIN(ARR)
    ALLOCATE ( ARR(1:NY*NX) )
    ARR = 0.

!$OMP DO SCHEDULE (DYNAMIC,1)
    DO I=1, NY*NX
      ARR(I) = 42.
    END DO
     
    DEALLOCATE ( ARR )
!$OMP END PARALLEL
    END SUBROUTINE
[/cpp]

The COPYIN(ARR) is there to copy in the empty array descriptor.

Jim Dempsey

[zimmer__don]

Quoting - IanH

It might be a question of "which OpenMP spec". In your code you have comments about the OpenMP 3.0 API. The Intel Fortran help docs under the "OpenMP* Fortran Compiler Directives" page talk about supporting "Version 1.1 and most of Version 2.0", which is not a very specific way of specifying a specification, but frankly I don't know enough about OpenMP to know whether that matters and perhaps the help is out of date.

The 1.1 and 2.0 specs have words "An allocatable array declared PRIVATE must have an allocation status of not currently allocated on entry to and on exit from the construct." I think your example violates that, but would appreciate clarification because this has caused issues for me too.

IanH

thanks.

The docs for my version state "The Intel compiler supports the OpenMP* Version 3.0 API specification.", but I do have a recent release. The test() subroutine does violate the condition you mention, however I think the 3.0 spec simply allowsallocated arrays and definesthe behaviour in this case (the copiesare allocated), so it is backward compatible (for unallocated arrays).

Don.

[zimmer__don]

Quoting - jimdempseyatthecove

Try something along the line of

[cpp]    SUBROUTINE TEST ( NX, NY )

    INTEGER, INTENT(IN) :: NX, NY
    INTEGER             :: I
    REAL, ALLOCATABLE   :: ARR(:)


!$OMP PARALLEL PRIVATE (ARR) COPYIN(ARR)
    ALLOCATE ( ARR(1:NY*NX) )
    ARR = 0.

!$OMP DO SCHEDULE (DYNAMIC,1)
    DO I=1, NY*NX
      ARR(I) = 42.
    END DO
     
    DEALLOCATE ( ARR )
!$OMP END PARALLEL
    END SUBROUTINE
[/cpp]

The COPYIN(ARR) is there to copy in the empty array descriptor.

Jim Dempsey

thanks Jim,

I thought COPYIN was only applicable to THREADPRIVATE? Anyway, the test_mod() function works ok without it.

Don.

[IanH]

Quoting - Don Zimmer

Quoting - IanH

...
The Intel Fortran help docs under the "OpenMP* Fortran Compiler Directives" page talk about supporting "Version 1.1 and most of Version 2.0"...

...
The docs for my version state "The Intel compiler supports the OpenMP* Version 3.0 API specification.", but I do have a recent release.
...

Actually I've now found the references to 3.0 too, in a bleedingly obvious spot. The 1.1 and 2.0 bit (which is in the language reference section rather than the optimising applications section) must just be an out of date topic. Looks like your point is rather valid!