OpenMP constraint on do loops inside a task construct

[IanH]

As my basic arithmetic is getting a bit shaky I thought I'd write a little program to ensure I can still count from 1 to 10, relying on old-fashioned rote-learning through repetition. I then decided to parallelise my program with OpenMP - time is money, after all.

But with the following the compiler complains about a dodgy EXIT statement in the inner-most DO loop:

[fortran]PROGRAM CountInParallel !$ USE OMP_LIB IMPLICIT NONE INTEGER :: itask INTEGER :: i !**** !$OMP PARALLEL DEFAULT(NONE) PRIVATE(itask) ! One thread defines twenty tasks. !$OMP SINGLE DO itask = 1, 20 ! The task is to count up to ten. !$OMP TASK PRIVATE(i) i = 1 DO IF (i > 10) EXIT ! error #7566 here !$ IF (.TRUE.) THEN !$OMP CRITICAL(some_output) !$ PRINT *, omp_get_thread_num(), itask, i !$OMP END CRITICAL(some_output) !$ ELSE PRINT *, itask, i !$ END IF i = i + 1 END DO !$OMP END TASK END DO !$OMP END SINGLE !$OMP END PARALLEL END PROGRAM CountInParallel
[/fortran]I don't think its whinging is justified - from my reading of the OpenMP spec that sort of restriction exists for loop constructs but not for task constructs. Thoughts?

(The docs that come with 12.0.4 don't have the parentheses in the syntax of the !$OMP CRITICAL directive - see ms-help://MS.VSCC.v80/intel.forprodocs/intel.fprocompilerdocs/main_for/optaps/common/optaps_par_dirs.htm under VS2005's doc explorer)have slightly incorrect syntax for the

[IanH]

From reading the OpenMP 3.0 spec the itask variable inside the task for the previous example would have had an "implicitly determined data sharing attribute" of first private (because it was private in a surrounding construct) and the output is consistent with this. But if that data sharing attribute is made explicit with a FIRSTPRIVATE clause then ifort 12.0.4 gives some unexpected results.

(The following works around the EXIT statement issue through use of DO WHILE (..)).

[fortran]PROGRAM CountInParallelDeluxe
  !$ USE OMP_LIB
  IMPLICIT NONE
  INTEGER :: itask
  INTEGER :: i  
  !****
  !$OMP PARALLEL DEFAULT(NONE) PRIVATE(itask)  
  ! One thread defines twenty tasks.
  !$OMP SINGLE
  DO itask = 1, 20
    ! The task is to count up to ten.
    !$OMP TASK PRIVATE(i) FIRSTPRIVATE(itask)
    i = 1
    DO WHILE (i <= 10)                         
      !$ IF (.TRUE.) THEN
      !$OMP CRITICAL(some_output)
      !$   PRINT *, omp_get_thread_num(), itask, i
      !$OMP END CRITICAL(some_output)
      !$ ELSE
      PRINT *, itask, i
      !$ END IF
      i = i + 1
    END DO
    !$OMP END TASK
  END DO
  !$OMP END SINGLE
  !$OMP END PARALLEL
END PROGRAM CountInParallelDeluxe
  [/fortran]

Some digging into detail (looking at the LOC's of the various itask's etc) makes me think that the 12.0.4 compiler is getting confused, but I quite happily admit that I have no idea what I'm doing here!

Thoughts ** 2 ?

[pbkenned1]

Hello Ian,
Both of your examples appear to be Intel OpenMP compiler bugs. We'll investigate and follow up.
Thank you,
Patrick
Intel Developer Support

[pbkenned1]

The tracking number for the defect illustrated by the first example is DPD200171019. Its title is 'ifort 12.0 rejects EXIT statement on nested DO loop in !$OMP PARALLEL region'. I'll keep this thread updated wth updates from compiler engineering.

Patrick

[pbkenned1]

The tracking number for the defect illustrated by the second example is DPD200171025. Its title is 'ifort 12.0 corrupts explicit FIRSTPRIVATE variable on !$OMP TASK directive'.

Patrick Kennedy
Intel Developer Suport

[pbkenned1]

DPD200171019 and DPD200171025 are still being investigated by compiler engineering. Neither issue is resolved in Composer XE update #6 (i.e., the 12.1 compiler).

Patrick

[pbkenned1]

DPD200171019 is resolved in Intel® Fortran Composer XE 2013 (http://software.intel.com/en-us/intel-composer-xe). DPD200171025 is still under investigation. Patrick