variables in blocks in subroutines are nonlocal?

[Ulrich_M_]

Hi,

The program below exits with "error" on my machine. It looks as if the variable r in the block is shared by the openmp loop, but it surely shouldn't be?

Thank you,

UM

program mfort
	implicit none

	integer	:: i
	real	:: x(1000)=[(i,i=1,1000)], y(1000)

		
!$omp parallel do 
	do i=1,1000
		call sub(x(i),y(i))
	enddo

	contains
	
	subroutine sub(x,y)
		real	:: x,y,z
		integer	:: i
		
		block
			real	:: r
			r=x
			z=0
			do i=1,1000
				z=z+cos(real(i))			! waste some time
			enddo
			if(r .ne. x) then
				print *,"error"
				stop
			endif
			y=r+z
		end block
	end subroutine
	
end program

[jimdempseyatthecove]

What version of the compiler? And what were the command line options?

Jim Dempsey

[Steven_L_Intel1]

I can reproduce this, but I will caution that OpenMP does not define the behavior here since it barely acknowledges Fortran 2003 and does not discuss how the BLOCK construct is handled. That said, this ought to work and I will let the developers know. Issue ID is DPD200408259. Thanks.

[Ulrich_M_]

Ok, thanks. But just to be clear: you are saying that as soon as I use openmp parallelization, then I should stay away from any Fortran 2003 or 08 language extensions? This is a serious constraint for the development of modern scientific computing software, and I didn't see Intel acknowledge this in its documentation/advertisement, etc.

In any event, precise guidance what is/what is not supported concerning openmp and Fortran 2003/08 would be very helpful. Thank you again.

UM

[Steven_L_Intel1]

The OpenMP standard is lacking in information about use of F2003 features, including BLOCK and PDTs. This example is even more problematic, with an "orphan, contained subroutine" outside the parallel region. You can find the OpenMP standard at openmp.org.

[Steven_L_Intel1]

We found that the compiler is allocating R statically, which it shouldn't do if /Qopenmp is in effect (since that implies /recursive). As a workaround, add , AUTOMATIC to the declaration of R (this is an extension).

[jimdempseyatthecove]

Steve,

Can you ask (and reply) if for non-contained procedures if BLOCK scalars are (incorrectly) static?

(This would make BLOCK's in general incompatible with OpenMP as well as in recursively used procedures.)

Jim

[Steven_L_Intel1]

It's a peculiarity only when /Qopenmp is specified, but happens even if not a contained procedure. BLOCK is not supported by the OpenMP standard at this time. It works fine in an ordinary recursive procedure when OpenMP is not used.

[jimdempseyatthecove]

Let me clarify my question

Assume you have a recursive subroutine that is called by the main thread of a program that is compiled with /Qopenmp. This subroutine is never called from within a parallel region. Is then the BLOCK contained scalar variable r static?

IOW, for the time being, are we required to attribute all BLOCK local variables with AUTOMATIC? (assuming the procedure is indeed called recursively)?

Jim Dempsey

[Steven_L_Intel1]

If you compile with /Qopenmp, then any variables declared in a BLOCK need to have the AUTOMATIC attribute added (if the block can be entered recursively or simultaneously.

[jimdempseyatthecove]

OK,

If this behavior ends up being standard behavior, then can you add to the documentation in bold that BLOCK declared variables including scalar are implicitly SAVE.

This makes the default/(option specified) behavior of BLOCK declared variables inconsistent with procedure declared variables.

BTW this explains why when I used BLOCK in an OpenMP program that the results got trashed.

Jim Dempsey

[Lorri_M_Intel]

The "declared variables are implicitly SAVE" behavior is a bug, so ... no documentation required.

Using the AUTOMATIC keyword *now* is a workaround until we resolve the problem.

[Steven_L_Intel1]

I expect the bug to be fixed in Update 1 to Parallel Studio XE 2017.