Bug 54247 - OpenMP code fails at execution in AMD Interlagos
Summary: OpenMP code fails at execution in AMD Interlagos
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.7.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-13 19:59 UTC by Bill Long
Modified: 2012-08-13 20:38 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bill Long 2012-08-13 19:59:47 UTC
> 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'
Comment 1 Bill Long 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.