OpenMP bug?

[Piergiorgio_Alotto]

Hi!
the following program segfaults after being compiled with ifort -openmp (v. 11.1) on both macs and Linux

program test
implicit none
integer,allocatable,dimension(:)::ivar
integer i,itot
allocate(ivar(5000))
itot=0
!$omp parallel do default(none) private(ivar) shared(itot)
do i=1,5000
ivar(i)=i
!$omp atomic
itot=itot+ivar(i)
enddo
!$omp end parallel do
deallocate(ivar)
write(6,*) itot
end

the same works if compiled with gfortran and pgi.
Any ideas?
Best regards,
Pier

[Piergiorgio_Alotto]

Dear Kevin,
I am running under Mac OS X 10.6.5

ifort -V -openmp test.f90

Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20100203 Package ID: m_cprof_p_11.1.084
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.
Intel Fortran 11.1-2692

export OMP_NUM_THREADS=2
./a.out
allocated 0 -1
allocated 0 0
allocated 0 0
allocated 1 0
allocated 1 1

so the Mac version appears to be older in date (20100203) but newer in version (084) with respect to Linux...
I will try to upgrade and see if the problem persists
Thanks a lot for having investigated the matter!

[Kevin_D_Intel]

Thank you for the clarification. I confirmed it produces incorrect results on Mac OS X 10.4.x with Xcode 3.2.2 andifort 11.1.084 and that it also appears fixed in ifort 11.1.089.

I also confirmed this is not related to the ifort/icc and Xcode 3.2.2 linker compatibility issue and that -use-asm has no effect. Reproducing this on Linux also confirms that. It appears there was perhaps an OpenMP defect with ifort from what I see. Ido nothave a specific internal report that I can relate the behavior to.

If you can upgrade to at least ifort 11.1.089, I believe that should resolve the issue.


Confirmed the test case behaves with 11.1.089:

$ ifort -V -openmp u78716.f90

Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20100806 Package ID: m_cprof_p_11.1.089
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.

Intel Fortran 11.1-2755
@(#)PROGRAM:ld PROJECT:ld64-97.2

$ export OMP_NUM_THREADS=2
$ OMP_NUM_THREADS=2
$ ./a.out
allocated 0 -1
allocated 0 0
allocated 0 0
allocated 1 -1
allocated 1 1
15

[jimdempseyatthecove]

>>if the list item is allocated, the new list item will have an initial state of allocated

Correct, I simply provided a reproducer that showed more detail regarding the problem.

Regarding "unable to use reduction" (should be posted as a different thread)

It would be nice if the OpenMP standard has (maybe it does have) a means to determine the iteration control variables. The purpose being to be able to determin: first iteration, last iteration, number of iterations (or stride).

!$omp parallel do
do i=iFrom, iTo, iStep

The current specification makes variable i local to the parallel region
I am suggesting that it would be nice if the programmer could determine theslices equivilent to the iFrom, iTo

Since many loops use literal constants a declaration of some sort needs to be provided

**** pseudo code with new feature recommendation
!$omp parallel do doprivate(iFrom, iTo) ...
do i=1,100
! i is currently private and has iteration point for this thread
! iFrom is private and has iteration start for this thread
! iTo is private and has iteration endfor this thread
...
if(i .eq. iTo) then
!$omp critical
...
!$omp end critical
endif
end do

Note, by providing a new type of private, you can also determine the iteration pointat any nest level (assuming variables of those nest levels are visible).

Jim Dempsey

[Kevin_D_Intel]

For the record, there was an earlier report of this issue opened with Development (internal tracking id noted below) that was fixed in the 11.1 update 7 (11.1.089 - Mac OS, 11.1.073 - Linux)

(Internal tracking id: DPD200150643)