Internal compiler error with lock/unlock

[Arjen_Markus]

Hello,

I have run into an ICE with the program below. The compiler version I use is: Intel Fortran 12.0.3 under Linux. The program may not be correct, but the compiler does not give any message, except for the ICE.

Regards,

Arjen

-----

! primes_coarrays.f90 --

! Determine the first 1000 primes - using coarrays

!

program primes_coarrays

use, intrinsic :: iso_fortran_env, only: lock_type

implicit none

type(lock_type), codimension

:: primes_lock

integer, dimension(2), codimension

:: range

integer, dimension(1000), codimension

:: prime

integer, codimension

:: number_primes

logical, codimension

:: new_results

logical, codimension

:: new_task

logical, codimension

:: ready

ready = .false.

new_results = .false.

new_task = .false.

number_primes = 0

range(2) = 0

!

! Create tasks in image 1 and handle them in all images

!

do while ( .not. ready )

if ( this_image() == 1 ) then

call add_task

endif

call get_task

enddo

write(*,'(10i5)') prime

contains

!

! Subroutine to post a new task (consisting of a

! range of integers in which to look for primes)

!

! Loop over the images to see which one wants a

! new task

!

subroutine add_task

integer :: i

do i = 1,num_images()

if ( .not. new_task ) then

range(1) = range(2) + 1

range(2) = range(2) + 100

range = range[1]

new_task = .true.

endif

enddo

end subroutine add_task

!

! Subroutine to get a task and search for

! primes inside the new range

!

subroutine get_task

integer, dimension(100) :: new_prime

integer :: lower

integer :: upper

logical :: isprime

logical :: got_task

integer :: np

integer :: i

integer :: j

integer :: residue

integer :: maxindex

got_task = .false.

np = 0

if ( new_task ) then

lower = range(1)

upper = range(2)

new_task = .false.

got_task = .true.

endif

if ( got_task ) then

write(*,*) 'Range: ',lower, upper, this_image()

do i = lower,upper

isprime = .true.

do j = 2,int(sqrt(real(i)))

residue = mod(i,j)

if ( residue == 0 ) then

isprime = .false.

exit

endif

enddo

if ( isprime ) then

np = np + 1

new_prime(np) = i

endif

enddo

endif

!

! Now put the results in image 1

!

if ( got_task ) then

lock( primes_lock )

maxindex = min( size(prime) - number_primes[1], np )

prime(number_primes+1:number_primes+maxindex)[1] = &

new_prime(1:maxindex)

number_primes[1] = number_primes[1] + maxindex

ready[1] = number_primes[1] >= size(prime)

unlock( primes_lock )

endif

end subroutine get_task

end program primes_coarrays

[Arjen_Markus]

Jim,

no luck: the same result.

Regards,

Arjen

[jimdempseyatthecove]

Arjen,

What happens with

program HelloCoarrays
write(*,*) "Hello world from ", this_image()
end program HelloCoarrays

(compile for co-arrays)


Does the above hang on exit too?

Jim

[Arjen_Markus]

Hi Jim,

no, that works okay. Hm, maybe I should reduce my program to the point
where it does correctly finish (at the expense of doing even less useful things)

I will let yyou know how I fare with that.

Regards,

Arjen

[Arjen_Markus]

I have experimented with a reduced version of the program, but nothing definite transpires.
The preliminary conclusion I think I can formulate is that it is the number of updates to the
prime array that is causing this. When I limited that (losing lots of information), it did finish
when all threads finished.

For the time being I can investigate an alternative solution - have thread 1 do all the updating.

Regards,

Arjen

[jimdempseyatthecove]

Try this: at the very end of the program insert

if(this_image() == 1) then
read(*,'(A)') line ! wait for user input
endif
end program yourProgramNameHere

add/reuse some character variable for line

then run the program but do not enter the text. i.e. let the program hang waiting for input.
In a seperate window run your favorite utility to see what is running on the system, in particular do you see one image running or multiple images running. The seperate images should have exited. If they have exited, then go back to the waiting image and press Return. See if this exits the program.

What I am asking you to check for is if there is a exit sequencing problem. If this seems to work then consider replacing the read with a call sleepqq(100) or some time interval long enough for the other images to exit.

Hopefully this will provide you with a work around until Intel can fix the problem.

If it doesn't work and the time difference is significant, the I suggest adding code at the end to get your process ID then issue a KILL process of that ID. A rather nasty way of working around the problem.

Jim Dempsey

[Arjen_Markus]

Hi Jim,

what I see is that even though the threads reach the STOP statement, except for thread 1 that is
waiting for the input, all remain active.

As this is an example, not a critical thing, I will leave this version for the moment and see if my alternative
has more of a chance to work.

Regards,

Arjen

[Steven_L_Intel1]

The internal compiler error has been fixed in our sources. I expect the fix to appear in a compiler later this year.