[Bug fortran/54247] New: OpenMP code fails at execution in AMD Interlagos

[Bug fortran/54247] New: OpenMP code fails at execution in AMD Interlagos

[longb at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54247

             Bug #: 54247
           Summary: OpenMP code fails at execution in AMD Interlagos
    Classification: Unclassified
           Product: gcc
           Version: 4.7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: longb@cray.com


> cat test.f90
!  derived from OpenMP test omp31f/F31_A_16_1.F90
!    based on Example A.16.1f, p. 213 lines 1-19 in OpenMP API Ver 3.1.
program F31_A_16_1
   use omp_lib
   implicit none
   integer, parameter :: ITERATIONS = 2**17 ! Adjustable parameter
   integer(kind=omp_lock_kind) :: lock
   integer :: count_something_useful = 0, count_something_critical = 0

   call omp_set_num_threads(16)
   call omp_set_dynamic(.false.)
   call omp_init_lock(lock)

!$omp parallel
!$omp single
   call foo(lock, ITERATIONS)
!$omp end single
!$omp end parallel

   if(count_something_useful /= ITERATIONS .or. &
      count_something_critical /= ITERATIONS) then
      write (6, '(*(G0))') ' FAIL - ', &
         '(count_something_useful,count_something_critical) == (', &
         count_something_useful, ',', count_something_critical, &
         '), expected (', ITERATIONS, ',', ITERATIONS, ')'
   end if

contains
   ! from OpenMP 3.1 Example A.16.1f
   subroutine foo ( lock, n )
      use omp_lib
      integer (kind=omp_lock_kind) :: lock
      integer n
      integer i
      do i = 1, n
        !$omp task
          call something_useful()
          do while ( .not. omp_test_lock(lock) ) 
            !$omp taskyield
          end do
          call something_critical()
          call omp_unset_lock(lock)
        !$omp end task
      end do
   end subroutine

   subroutine something_useful()
      !$omp atomic update
      count_something_useful = count_something_useful+1
   end subroutine something_useful

   subroutine something_critical
      ! isn't necessary to protect with atomic update, as invocations of this
      ! subroutine are protected by a lock
      count_something_critical = count_something_critical+1
   end subroutine something_critical

end program F31_A_16_1


> ftn -fopenmp test.f90
> ilrun -n1 -d16 ./a.out
 FAIL - (count_something_useful,count_something_critical) == (131072,131070),
expected (131072,131072)
Application 8535547 resources: utime ~6s, stime ~1s
> mcrun -n1 -d16 ./a.out
Application 8535554 resources: utime ~0s, stime ~1s

The code triggers a FAIL trap on interlagos processors, but not on the previous
generation Magny-Cours AMD chips.

Command explanation:

ilrun -n1 -d16

--> Execute on a node with Interlagos processors, 1 node, 16 threads

mcrun -n1 -d16

--> Execute on a node with Magny-Cours processors, 1 node, 16 threads  [2
sockets in SMP node]

ftn

--> wrapper for Cray systems to get the "right" (we hope) set of libraries and
default options for the current compilation environment.  For the gcc
environment, the options implied are here are COLLECT_GCC_OPTIONS='-u'
'pthread_mutex_trylock' '-fno-second-underscore' '-march=bdver1' '-static' '-v'
'-fopenmp'

[Bug fortran/54247] OpenMP code fails at execution in AMD Interlagos

[longb at cray dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54247

Bill Long <longb at cray dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Bill Long <longb at cray dot com> 2012-08-13 20:38:33 UTC ---
Our internal OpenMP gurus spotted that in line 36 the

!$omp task

should be 

!$omp task default(shared)


With that change, the code executes correctly on Interlagos nodes.  

Conclusion is that there is a bug in the OpenMP 3.1 examples, so still
potentially useful information.  But the initial complaint is not valid.