Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Novice

variables in blocks in subroutines are nonlocal?

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

 

0 Kudos
12 Replies
Highlighted

What version of the compiler?

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

Jim Dempsey

0 Kudos
Highlighted

I can reproduce this, but I

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.

Retired 12/31/2016
0 Kudos
Highlighted
Novice

Ok, thanks. But just to be

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

0 Kudos
Highlighted

The OpenMP standard is

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.

Retired 12/31/2016
0 Kudos
Highlighted

We found that the compiler is

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).

Retired 12/31/2016
0 Kudos
Highlighted

Steve,

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

0 Kudos
Highlighted

It's a peculiarity only when

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.

Retired 12/31/2016
0 Kudos
Highlighted

Let me clarify my question

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

0 Kudos
Highlighted

If you compile with /Qopenmp,

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.

Retired 12/31/2016
0 Kudos
Highlighted

OK,

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

0 Kudos
Highlighted

The "declared variables are

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.

 

0 Kudos
Highlighted

I expect the bug to be fixed

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

Retired 12/31/2016
0 Kudos