- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
module foo
type someType
logical :: flag = .false.
end type someType
end module foo
program omp_flush_issue
use foo
implicit none
type(someType) :: myType
!$omp flush(myType%flag)
end program omp_flush_issue
Compiling with Intel® Fortran Compiler 2025.0.0 [Intel(R) 64]...
omp_flush_issue.f90
C:\test\omp_flush_issue\omp_flush_issue\omp_flush_issue.f90(23): error #5082: Syntax error, found '%' when expecting one of: ) ,
C:\test\omp_flush_issue\omp_flush_issue\omp_flush_issue.f90(23): error #6404: This name does not have a type, and must have an explicit type. [FLAG]
compilation aborted for C:\test\omp_flush_issue\omp_flush_issue\omp_flush_issue.f90 (code 1)
As a hack fix, you can call a subroutine with (myType%flag) then issue the flush directive on the reference to the variable.
Jim Dempsey
コピーされたリンク
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Example:
...
#if 0
!$omp flush(myContext%ACCvalid)
do while(.not.myContext%ACCvalid)
!$omp flush(myContext%ACCvalid)
end do
#else
call omp_flush_hack(myContext%ACCvalid)
#endif
...
subroutine omp_flush_hack(myACCvalid)
logical :: myACCvalid
!$omp flush(myACCvalid)
do while(.not.myACCvalid)
!$omp flush(myACCvalid)
end do
end subroutine omp_flush_hack
Jim Dempsey
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
At OpenMP 6.0 spec "5.2.1 OpenMP Argument Lists -> Restrictions -> Fortran" it is written that "Unless otherwise specified, a variable that is part of an aggregate variable must not be a variable list item or an extended list item" so the compiler issues the error on your first case.
Gfortran also provides similar compilation error:
$ gfortran -fopenmp -c test.f90
test.f90:10:16:
10 | !$omp flush(myType%flag)
| 1
Error: Unexpected junk after $OMP FLUSH statement at (1)
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
(unless I am missing something) this restriction is totally unnecessary. I suspect this is a committee disagreement as opposed to technical issue.
An alternate work around is
...
associate(kludge=>myType%flag)
!$omp flush(kludge)
do while(.not.kludge)
!$omp flush(kludge)
end do
end associate
...
FWIW the above can be used where some team members, but not all, need a synchronization point and where !$omp barrier/single cannot be used.
A potential issue with member variable within a UDT is:
If the UDT has (BIND(C) .OR. SEQUENCE) .AND. (the member variable is not naturally aligned .AND. falls across cache line boundary)
then, potentially, the entire variable might not get flushed.
This restriction means thread shared and modifiable variables cannot be within UDT types. Overly restrictive IMHO
Jim Dempsey
