Page 1 of 1

omp_get_num_threads behavior under gcc and Intel

PostPosted: Wed Sep 05, 2018 7:40 am
by Fortran
All,

This might be a FAQ, but my search-fu failed to find an answer. Namely I have a program:
Code: Select all
program test

   use omp_lib
   implicit none

   integer :: i

   !$omp parallel do default(none) private(i)
   do i = 1, omp_get_num_threads()
      write (*,*) i
   end do
   !$omp end parallel do

end program test

that has two different behaviors under GNU and Intel Fortran. With Intel:
Code: Select all
(1734) $ ifort --version
ifort (IFORT) 18.0.3 20180410
Copyright (C) 1985-2018 Intel Corporation.  All rights reserved.

(1735) $ ifort -qopenmp test.F90
(1736) $ env OMP_NUM_THREADS=4 ./a.out
           2
           1
           3
           4

and with gfortran:
Code: Select all
(1738) $ gfortran --version
GNU Fortran (GCC) 8.1.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

(1739) $ gfortran -fopenmp test.F90
(1740) $ env OMP_NUM_THREADS=4 ./a.out
           1

I suppose my question is: Are both correct (a la "processor-dependent" in the Fortran standard)? Is one more correct than the other?

Re: omp_get_num_threads behavior under gcc and Intel

PostPosted: Thu Sep 06, 2018 10:44 am
by bsteinb
This seems to be a bug in gfortran. If you split up the combined parallel do construct into a do construct nested inside a parallel construct you get the same behaviour as with the Intel compiler:

Code: Select all
   !$omp parallel
   !$omp do
   do i = 1, omp_get_num_threads()
      write (*,*) i
   end do
   !$omp end do
   !$omp end parallel


An equivalent C program compiled with gcc also reproduces the Intel compiler results (both with the combined construct and the pair of nested constructs).

The OpenMP API 4.5 states in section 2.11 that combined constructs should be semantically equivalent to the nested pair.