bug with ifort + openmp : allocatable array not allocated after allocation 
Author Message
 bug with ifort + openmp : allocatable array not allocated after allocation

The following code should allocate an allocatable shared array inside
the parallel construct using SINGLE clause. It generates a run time
error with ifort 10.1:

forrtl: severe (408): fort: (8): Attempt to fetch from allocatable
variable USEDD when it is not allocated

It *IS* allocated at the end of the routine RESIZE, only something
gets screwed up on the return . It is allocated inside the SINGLE
region, so no double allocation. The problem is gone if the call to
resize is replaced by explicit inlining of the routine (uncomment the
commented lines and do not call RESIZE). The problem will also go away
if the RESIZE routine is present -and called from - directly the main
file. Looks like an obvious bug to me. Any comments to open my eyes?
Thanks -- Dominik

main file:

PROGRAM NS3T
  USE NS3T10
  IMPLICIT NONE
  CALL SETUP_A
END PROGRAM NS3T

separate file:
MODULE NS3T10
USE OMP_LIB
IMPLICIT NONE

CONTAINS

SUBROUTINE SETUP_A
  INTEGER, DIMENSION(:), ALLOCATABLE :: USEDD
  INTEGER :: NTH=1, MYID=1
!$OMP PARALLEL DEFAULT(SHARED) PRIVATE(NTH, MYID)
  NTH = OMP_GET_NUM_THREADS()
  MYID = OMP_GET_THREAD_NUM()
!$OMP SINGLE
  PRINT *, NTH, MYID
  CALL RESIZE(USEDD,1)
!  IF(ALLOCATED(USEDD)) DEALLOCATE(USEDD)
!  ALLOCATE(USEDD(1))
  PRINT *, ALLOCATED(USEDD)
  USEDD = 0
  PRINT *, USEDD
!$OMP END SINGLE
!$OMP   END PARALLEL
END SUBROUTINE SETUP_A

SUBROUTINE RESIZE(V,S)
  INTEGER, DIMENSION(:), ALLOCATABLE, INTENT(INOUT) :: V
  INTEGER, INTENT(IN) :: S
  IF(ALLOCATED(V)) DEALLOCATE(V)
  ALLOCATE(V(S))
  PRINT *, 'RESIZE : ', S
END SUBROUTINE RESIZE

END MODULE NS3T10



Wed, 22 Dec 2010 03:18:23 GMT  
 bug with ifort + openmp : allocatable array not allocated after allocation

Quote:
> ? INTEGER, DIMENSION(:), ALLOCATABLE, INTENT(INOUT) :: V

Hi,

When I compiled your code with  /stand:f95 option,
the above line produced the following warning:

Warning: Allocatable dummy arguments is an extension of Standard
F95.   [V]

Maybe that's the problem?

Roman



Wed, 22 Dec 2010 06:35:16 GMT  
 bug with ifort + openmp : allocatable array not allocated after allocation

Hi,

Your code seems to work if the array is already allocated
before entering the parallel region:

SUBROUTINE SETUP_A
  INTEGER, DIMENSION(:), ALLOCATABLE :: USEDD
  INTEGER :: NTH=1, MYID=1

  allocate(USEDD(1))   !!!

!$OMP PARALLEL DEFAULT(NONE) SHARED(USEDD) PRIVATE(NTH, MYID)
!$  NTH = OMP_GET_NUM_THREADS()
!$  MYID = OMP_GET_THREAD_NUM()

!$OMP SINGLE
!$  PRINT *, NTH, MYID
  CALL RESIZE(USEDD, 5)

  PRINT *, ALLOCATED(USEDD)
  USEDD = 0
  PRINT *, USEDD
!$OMP END SINGLE
!$OMP   END PARALLEL

END SUBROUTINE SETUP_A



Wed, 22 Dec 2010 07:14:51 GMT  
 bug with ifort + openmp : allocatable array not allocated after allocation
Hi, thanks for the comment. Yes indeed, the problem is the allocation
inside the parallel region. I looked through the OpenMP specifications
and did not find a requirement that allocatable arrays can not be
allocated there...
-- Dominik


Quote:
> Hi,

> Your code seems to work if the array is already allocated
> before entering the parallel region:

> SUBROUTINE SETUP_A
>   INTEGER, DIMENSION(:), ALLOCATABLE :: USEDD
>   INTEGER :: NTH=1, MYID=1

>   allocate(USEDD(1))   !!!

> !$OMP PARALLEL DEFAULT(NONE) SHARED(USEDD) PRIVATE(NTH, MYID)
> !$  NTH = OMP_GET_NUM_THREADS()
> !$  MYID = OMP_GET_THREAD_NUM()

> !$OMP SINGLE
> !$  PRINT *, NTH, MYID
>   CALL RESIZE(USEDD, 5)

>   PRINT *, ALLOCATED(USEDD)
>   USEDD = 0
>   PRINT *, USEDD
> !$OMP END SINGLE
> !$OMP   END PARALLEL

> END SUBROUTINE SETUP_A



Wed, 22 Dec 2010 15:49:01 GMT  
 bug with ifort + openmp : allocatable array not allocated after allocation
Hmm, that is interesting, didn't know that, thanks. However, the thing
works without OpenMP. In addition, emitting such warning means that
the compiler is aware of the situation and handles it. So it makes me
even more confident it is a bug. -- Dominik


Quote:
> >   INTEGER, DIMENSION(:), ALLOCATABLE, INTENT(INOUT) :: V

> Hi,

> When I compiled your code with  /stand:f95 option,
> the above line produced the following warning:

> Warning: Allocatable dummy arguments is an extension of Standard
> F95.   [V]

> Maybe that's the problem?

> Roman



Wed, 22 Dec 2010 15:51:52 GMT  
 bug with ifort + openmp : allocatable array not allocated after allocation
I mean, bug in the compiler. -- Dominik


Quote:
> Hmm, that is interesting, didn't know that, thanks. However, the thing
> works without OpenMP. In addition, emitting such warning means that
> the compiler is aware of the situation and handles it. So it makes me
> even more confident it is a bug. -- Dominik


> > >   INTEGER, DIMENSION(:), ALLOCATABLE, INTENT(INOUT) :: V

> > Hi,

> > When I compiled your code with  /stand:f95 option,
> > the above line produced the following warning:

> > Warning: Allocatable dummy arguments is an extension of Standard
> > F95.   [V]

> > Maybe that's the problem?

> > Roman



Wed, 22 Dec 2010 15:56:06 GMT  
 bug with ifort + openmp : allocatable array not allocated after allocation
Hi again,

The thing will work if the array is POINTER and not ALLOCATABLE.

Citation from Metcalf:

"In fortran 95, the undefined allocation status cannot occur. On
return from a
subprogram, an allocated allocatable array without the save attribute
is automat-
ically deallocated if it is local to the subprogram, and it is
processor dependent as
to whether it remains allocated or is deallocated if it is local to a
module and is
accessed only by the subprogram."

That explains it perfectly, what I am doing is simply wrong. There is
no bug in the compiler, only a misleading inconsistency: it worked
very long in the serial code and failure with OpenMP was somewhat non-
obvious. BTW. this pointer/allocations stuff is so much cleaner in C.

Thanks Roman for helping me get on the right track.

-- Dominik


Quote:
> I mean, bug in the compiler. -- Dominik


> > Hmm, that is interesting, didn't know that, thanks. However, the thing
> > works without OpenMP. In addition, emitting such warning means that
> > the compiler is aware of the situation and handles it. So it makes me
> > even more confident it is a bug. -- Dominik


> > > >   INTEGER, DIMENSION(:), ALLOCATABLE, INTENT(INOUT) :: V

> > > Hi,

> > > When I compiled your code with  /stand:f95 option,
> > > the above line produced the following warning:

> > > Warning: Allocatable dummy arguments is an extension of Standard
> > > F95.   [V]

> > > Maybe that's the problem?

> > > Roman



Wed, 22 Dec 2010 16:35:14 GMT  
 bug with ifort + openmp : allocatable array not allocated after allocation
well final 2 cents: intent(inout) suggests the array remains allocated
after return, and is so in a serial code, so this really the
compiler's inconsistency. --DS


Quote:
> Hi again,

> The thing will work if the array is POINTER and not ALLOCATABLE.

> Citation from Metcalf:

> "In Fortran 95, the undefined allocation status cannot occur. On
> return from a
> subprogram, an allocated allocatable array without the save attribute
> is automat-
> ically deallocated if it is local to the subprogram, and it is
> processor dependent as
> to whether it remains allocated or is deallocated if it is local to a
> module and is
> accessed only by the subprogram."

> That explains it perfectly, what I am doing is simply wrong. There is
> no bug in the compiler, only a misleading inconsistency: it worked
> very long in the serial code and failure with OpenMP was somewhat non-
> obvious. BTW. this pointer/allocations stuff is so much cleaner in C.

> Thanks Roman for helping me get on the right track.

> -- Dominik


> > I mean, bug in the compiler. -- Dominik


> > > Hmm, that is interesting, didn't know that, thanks. However, the thing
> > > works without OpenMP. In addition, emitting such warning means that
> > > the compiler is aware of the situation and handles it. So it makes me
> > > even more confident it is a bug. -- Dominik


> > > > >   INTEGER, DIMENSION(:), ALLOCATABLE, INTENT(INOUT) :: V

> > > > Hi,

> > > > When I compiled your code with  /stand:f95 option,
> > > > the above line produced the following warning:

> > > > Warning: Allocatable dummy arguments is an extension of Standard
> > > > F95.   [V]

> > > > Maybe that's the problem?

> > > > Roman



Wed, 22 Dec 2010 17:03:58 GMT  
 bug with ifort + openmp : allocatable array not allocated after allocation
.. and compiling with -std03 produces no warning,.. unfortunately I
don't have access to specifications of 2003 standard to confirm if
such practice is allowed.


Quote:
> well final 2 cents: intent(inout) suggests the array remains allocated
> after return, and is so in a serial code, so this really the
> compiler's inconsistency. --DS


> > Hi again,

> > The thing will work if the array is POINTER and not ALLOCATABLE.

> > Citation from Metcalf:

> > "In Fortran 95, the undefined allocation status cannot occur. On
> > return from a
> > subprogram, an allocated allocatable array without the save attribute
> > is automat-
> > ically deallocated if it is local to the subprogram, and it is
> > processor dependent as
> > to whether it remains allocated or is deallocated if it is local to a
> > module and is
> > accessed only by the subprogram."

> > That explains it perfectly, what I am doing is simply wrong. There is
> > no bug in the compiler, only a misleading inconsistency: it worked
> > very long in the serial code and failure with OpenMP was somewhat non-
> > obvious. BTW. this pointer/allocations stuff is so much cleaner in C.

> > Thanks Roman for helping me get on the right track.

> > -- Dominik


> > > I mean, bug in the compiler. -- Dominik


> > > > Hmm, that is interesting, didn't know that, thanks. However, the thing
> > > > works without OpenMP. In addition, emitting such warning means that
> > > > the compiler is aware of the situation and handles it. So it makes me
> > > > even more confident it is a bug. -- Dominik


> > > > > >   INTEGER, DIMENSION(:), ALLOCATABLE, INTENT(INOUT) :: V

> > > > > Hi,

> > > > > When I compiled your code with  /stand:f95 option,
> > > > > the above line produced the following warning:

> > > > > Warning: Allocatable dummy arguments is an extension of Standard
> > > > > F95.   [V]

> > > > > Maybe that's the problem?

> > > > > Roman



Wed, 22 Dec 2010 17:31:41 GMT  
 bug with ifort + openmp : allocatable array not allocated after allocation
I just found on the INTEL page:

http://www.intel.com/support/performancetools/fortran/sb/cs-007846.htm

that allocatable dummy arguments are OK in fortran 2003.

So : a clear compiler bug.


Quote:
> .. and compiling with -std03 produces no warning,.. unfortunately I
> don't have access to specifications of 2003 standard to confirm if
> such practice is allowed.


> > well final 2 cents: intent(inout) suggests the array remains allocated
> > after return, and is so in a serial code, so this really the
> > compiler's inconsistency. --DS


> > > Hi again,

> > > The thing will work if the array is POINTER and not ALLOCATABLE.

> > > Citation from Metcalf:

> > > "In Fortran 95, the undefined allocation status cannot occur. On
> > > return from a
> > > subprogram, an allocated allocatable array without the save attribute
> > > is automat-
> > > ically deallocated if it is local to the subprogram, and it is
> > > processor dependent as
> > > to whether it remains allocated or is deallocated if it is local to a
> > > module and is
> > > accessed only by the subprogram."

> > > That explains it perfectly, what I am doing is simply wrong. There is
> > > no bug in the compiler, only a misleading inconsistency: it worked
> > > very long in the serial code and failure with OpenMP was somewhat non-
> > > obvious. BTW. this pointer/allocations stuff is so much cleaner in C.

> > > Thanks Roman for helping me get on the right track.

> > > -- Dominik


> > > > I mean, bug in the compiler. -- Dominik


> > > > > Hmm, that is interesting, didn't know that, thanks. However, the thing
> > > > > works without OpenMP. In addition, emitting such warning means that
> > > > > the compiler is aware of the situation and handles it. So it makes me
> > > > > even more confident it is a bug. -- Dominik


> > > > > > >   INTEGER, DIMENSION(:), ALLOCATABLE, INTENT(INOUT) :: V

> > > > > > Hi,

> > > > > > When I compiled your code with  /stand:f95 option,
> > > > > > the above line produced the following warning:

> > > > > > Warning: Allocatable dummy arguments is an extension of Standard
> > > > > > F95.   [V]

> > > > > > Maybe that's the problem?

> > > > > > Roman



Wed, 22 Dec 2010 20:47:42 GMT  
 bug with ifort + openmp : allocatable array not allocated after allocation
the problem does not occur if optimization is switched on. bug bug
bug.


Quote:
> I just found on the INTEL page:

> http://www.intel.com/support/performancetools/fortran/sb/cs-007846.htm

> that allocatable dummy arguments are OK in fortran 2003.

> So : a clear compiler bug.


> > .. and compiling with -std03 produces no warning,.. unfortunately I
> > don't have access to specifications of 2003 standard to confirm if
> > such practice is allowed.


> > > well final 2 cents: intent(inout) suggests the array remains allocated
> > > after return, and is so in a serial code, so this really the
> > > compiler's inconsistency. --DS


> > > > Hi again,

> > > > The thing will work if the array is POINTER and not ALLOCATABLE.

> > > > Citation from Metcalf:

> > > > "In Fortran 95, the undefined allocation status cannot occur. On
> > > > return from a
> > > > subprogram, an allocated allocatable array without the save attribute
> > > > is automat-
> > > > ically deallocated if it is local to the subprogram, and it is
> > > > processor dependent as
> > > > to whether it remains allocated or is deallocated if it is local to a
> > > > module and is
> > > > accessed only by the subprogram."

> > > > That explains it perfectly, what I am doing is simply wrong. There is
> > > > no bug in the compiler, only a misleading inconsistency: it worked
> > > > very long in the serial code and failure with OpenMP was somewhat non-
> > > > obvious. BTW. this pointer/allocations stuff is so much cleaner in C.

> > > > Thanks Roman for helping me get on the right track.

> > > > -- Dominik


> > > > > I mean, bug in the compiler. -- Dominik


> > > > > > Hmm, that is interesting, didn't know that, thanks. However, the thing
> > > > > > works without OpenMP. In addition, emitting such warning means that
> > > > > > the compiler is aware of the situation and handles it. So it makes me
> > > > > > even more confident it is a bug. -- Dominik


> > > > > > > >   INTEGER, DIMENSION(:), ALLOCATABLE, INTENT(INOUT) :: V

> > > > > > > Hi,

> > > > > > > When I compiled your code with  /stand:f95 option,
> > > > > > > the above line produced the following warning:

> > > > > > > Warning: Allocatable dummy arguments is an extension of Standard
> > > > > > > F95.   [V]

> > > > > > > Maybe that's the problem?

> > > > > > > Roman



Thu, 23 Dec 2010 05:17:40 GMT  
 bug with ifort + openmp : allocatable array not allocated after allocation


Quote:
> The following code should allocate an allocatable shared array inside
> the parallel construct using SINGLE clause. It generates a run time
> error with ifort 10.1:

> forrtl: severe (408): fort: (8): Attempt to fetch from allocatable
> variable USEDD when it is not allocated

> It *IS* allocated at the end of the routine RESIZE, only something
> gets screwed up on the return . It is allocated inside the SINGLE
> region, so no double allocation. The problem is gone if the call to
> resize is replaced by explicit inlining of the routine (uncomment the
> commented lines and do not call RESIZE). The problem will also go away
> if the RESIZE routine is present -and called from - directly the main
> file. Looks like an obvious bug to me. Any comments to open my eyes?
> Thanks -- Dominik

Ifort is a good compiler. Try gfortran which is free.
I copy your program into file Domel.f90, and run on a dual processors. Num
of threads = 2, id = 0. The output is as follows:

C:\TEMP\fortran>gfortran -fopenmp Domel.f90 -o Domel.exe

C:\TEMP\fortran>Domel
           2           0
 RESIZE :            1
 T
           0



Thu, 23 Dec 2010 09:28:17 GMT  
 bug with ifort + openmp : allocatable array not allocated after allocation
Yes, I already tried (version 4.2.1). I can not compile simplest
programs:

gfortran -fopenmp -g -o /tmp/NS3T10_MAIN_TEST1.o -c
NS3T10_MAIN_TEST1.f90

NS3T10_MAIN_TEST1.f90:26.3:

END SUBROUTINE SETUP_A
  1
Error: Unexpected END statement at (1)
NS3T10_MAIN_TEST1.f90:28:

But I am sure it would work, when compiled. I have just compiled this
code on SUN with the SUN studio fortran and it works fine.
Intel's ifort will also work if NOT compiled with NO optimization. So
the bottom line for me is: ifort has a bug in implementing 2003
standard with allocatable arrays as dummy arguments in openmp.

-- Domel


Quote:


> > The following code should allocate an allocatable shared array inside
> > the parallel construct using SINGLE clause. It generates a run time
> > error with ifort 10.1:

> > forrtl: severe (408): fort: (8): Attempt to fetch from allocatable
> > variable USEDD when it is not allocated

> > It *IS* allocated at the end of the routine RESIZE, only something
> > gets screwed up on the return . It is allocated inside the SINGLE
> > region, so no double allocation. The problem is gone if the call to
> > resize is replaced by explicit inlining of the routine (uncomment the
> > commented lines and do not call RESIZE). The problem will also go away
> > if the RESIZE routine is present -and called from - directly the main
> > file. Looks like an obvious bug to me. Any comments to open my eyes?
> > Thanks -- Dominik

> Ifort is a good compiler. Try gfortran which is free.
> I copy your program into file Domel.f90, and run on a dual processors. Num
> of threads = 2, id = 0. The output is as follows:

> C:\TEMP\fortran>gfortran -fopenmp Domel.f90 -o Domel.exe

> C:\TEMP\fortran>Domel
>            2           0
>  RESIZE :            1
>  T
>            0



Thu, 23 Dec 2010 15:38:36 GMT  
 bug with ifort + openmp : allocatable array not allocated after allocation

-|The following code should allocate an allocatable shared array inside
-|the parallel construct using SINGLE clause. It generates a run time
-|error with ifort 10.1:
-|
-|forrtl: severe (408): fort: (8): Attempt to fetch from allocatable
-|variable USEDD when it is not allocated
-|
-|It *IS* allocated at the end of the routine RESIZE, only something
-|gets screwed up on the return . It is allocated inside the SINGLE
-|region, so no double allocation. The problem is gone if the call to
-|resize is replaced by explicit inlining of the routine (uncomment the
-|commented lines and do not call RESIZE). The problem will also go away
-|if the RESIZE routine is present -and called from - directly the main
-|file. Looks like an obvious bug to me. Any comments to open my eyes?
-|Thanks -- Dominik
-|
-|main file:
-|
-|PROGRAM NS3T
-|  USE NS3T10
-|  IMPLICIT NONE
-|  CALL SETUP_A
-|END PROGRAM NS3T
-|
-|separate file:
-|MODULE NS3T10
-|USE OMP_LIB
-|IMPLICIT NONE
-|
-|CONTAINS
-|
-|SUBROUTINE SETUP_A
-|  INTEGER, DIMENSION(:), ALLOCATABLE :: USEDD
-|  INTEGER :: NTH=1, MYID=1
-|!$OMP PARALLEL DEFAULT(SHARED) PRIVATE(NTH, MYID)
-|  NTH = OMP_GET_NUM_THREADS()
-|  MYID = OMP_GET_THREAD_NUM()
-|!$OMP SINGLE
-|  PRINT *, NTH, MYID
-|  CALL RESIZE(USEDD,1)
-|!  IF(ALLOCATED(USEDD)) DEALLOCATE(USEDD)
-|!  ALLOCATE(USEDD(1))
-|  PRINT *, ALLOCATED(USEDD)
-|  USEDD = 0
-|  PRINT *, USEDD
-|!$OMP END SINGLE
-|!$OMP END PARALLEL
-|END SUBROUTINE SETUP_A
-|
-|SUBROUTINE RESIZE(V,S)
-|  INTEGER, DIMENSION(:), ALLOCATABLE, INTENT(INOUT) :: V
-|  INTEGER, INTENT(IN) :: S
-|  IF(ALLOCATED(V)) DEALLOCATE(V)
-|  ALLOCATE(V(S))
-|  PRINT *, 'RESIZE : ', S
-|END SUBROUTINE RESIZE
-|
-|END MODULE NS3T10

I may be missing the boat again, but...

Moving the main program to the end of the code and removing the
phrase: separate file:

the program compiles with V10.1 of Ifort (under Linux):


Version 10.1


domel.f90(37): (col. 8) remark: OpenMP DEFINED REGION WAS PARALLELIZED.
domel.f90(37): (col. 8) remark: LOOP WAS VECTORIZED.
domel.f90(10): (col. 7) remark: OpenMP DEFINED REGION WAS PARALLELIZED.
domel.f90(19): (col. 3) remark: LOOP WAS VECTORIZED.

When run with one procesor the output is:

           1           0
 RESIZE :            1
 T
           0

Regards.
Skip Knoble



Fri, 24 Dec 2010 20:30:35 GMT  
 bug with ifort + openmp : allocatable array not allocated after allocation

Quote:

>The following code should allocate an allocatable shared array inside
>the parallel construct using SINGLE clause. It generates a run time
>error with ifort 10.1:

>forrtl: severe (408): fort: (8): Attempt to fetch from allocatable
>variable USEDD when it is not allocated

I can reproduce this bug - it happens only if you ask for the optional
"pointer checking" feature (-check pointer, implicit in -C) as well as OpenMP.
The array actually is allocated but the code that is triggered by the pointer
checking feature is evidently looking in the wrong place.  We'll fix it.

The workaround is to not use the -check pointer feature.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
  http://softwareforums.intel.com/
Intel Fortran Support
  http://support.intel.com/support/performancetools/fortran
My Fortran blog
  http://www.intel.com/software/drfortran



Fri, 24 Dec 2010 22:22:21 GMT  
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. allocatable array *not* equivalent to dynamic allocation?

2. ifort + openmp + fftw problem

3. Allocatable arrays not permitted in F90 structures!

4. allocatable vs non-allocatable arrays

5. Allocatable array of allocatable defined types?

6. ubound on dummy, allocated array not correct?

7. OpenMP error with allocatable component

8. openMP: threadprivate not effected and function variables not passed

9. F90: ?: how to allocate ALLOCATABLE, PRIVATE component?

10. Unallocated Allocatable as Dummy Argument to be Allocated inside Subroutine

11. re-allocating an allocatable

12. automatic arrays vs. allocated arrays

 

 
Powered by phpBB® Forum Software