openmp allocatable bug back?

Patrice_l_ · ‎09-15-2015

Hi,

Im running into another openmp problem, i cannot get any debug information out of it. I got a an "allocatable array is already allocated" but right before the allocatable the result of allocated() is false, gdb is giving me no stack information. without openmp everything works fine, in gcc with openmp no allocation problem, and this problem is also apparent with 1 thread.

It looks very similar to this one, but cant reproduce in simple case for now. https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/537701

The closest simple case i have is this one, multiple way of removing this bug, uncomment the print in the second task or remove the argument target of the subroutine, compiled with ifort -O0 -C -g -traceback -fopenmp :

module tata
implicit none
type t
double precision,dimension(:),allocatable :: f
end type
end module tata
program foo
use omp_lib
use tata
implicit none
type(t) :: f1
!$omp parallel
!$omp master
call toto(f1)
!$omp end master
!$omp end parallel
contains
subroutine toto(f)
use tata
class(t),target :: f
class(t),allocatable :: f1,f2
class(t),pointer :: temp

temp=>f
!$omp task default(shared) private(f1,f2)
print *,omp_get_thread_num()
allocate(f2,f1)
allocate(f1.f(10),temp.f(10))
f1.f=1d0
print *,f1.f
deallocate(f1,f2)
!$omp end task
!$omp task default(shared) private(f1,f2)
!print *,omp_get_thread_num()!,'here 2'  ! UNCOMMENT TO REMOVE BUG
!print *,allocated(f2),allocated(f1)
allocate(f2,f1)
allocate(f1.f(10))
f1.f=1d0
print *,f1.f
!$omp end task

!$omp taskwait
print *,'tototata'
end subroutine 
end program foo

Thanks.

Kevin_D_Intel · ‎09-15-2015

I read your forum title as meaning the bug you cited from the other thread that we reported as fixed in the 16.0 Beta was back in the 16.0 release. So, I tried a few variations with different compiler options using the 16.0 compiler and cannot reproduce a run-time about "allocatable array is already allocated". I’m not sure what the missing ingredient is.

$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.0.109 Build 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

$ ifort -O0 -C -g -traceback -fopenmp u593487.f90
$ export OMP_NUM_THREADS=1
$ ./a.out
           0
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000
 F F
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000
 tototata
 
 
$ ifort -O2 -fopenmp u593487.f90
$ export OMP_NUM_THREADS=1
$ ./a.out
           0
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000
 F F
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000
 tototata

Patrice_l_ · ‎09-15-2015

Hi,

The previous bug is fixed, but it looks very similar this time it is for omp task. here is what i have :

$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.0.109 Build 20150815
Copyright (C) 1985-2015 Intel Corporation. All rights reserved.

[plinel@mendel-master1 ~]$ ifort -O0 -C -g -traceback -fopenmp t.f90
[plinel@mendel-master1 ~]$ ./a.out
           0
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000
forrtl: severe (151): allocatable array is already allocated
Image              PC                Routine            Line        Source
a.out              0000000000421A87 Unknown               Unknown Unknown
a.out              0000000000404B20 foo_IP_toto_               36 t.f90
libiomp5.so        00002AAAAB069D3A Unknown               Unknown Unknown
libiomp5.so        00002AAAAB069559 Unknown               Unknown Unknown
a.out              0000000000403722 foo_IP_toto_               33 t.f90
a.out              000000000040329D MAIN__                     14 t.f90
libiomp5.so        00002AAAAB074BC3 Unknown               Unknown Unknown
libiomp5.so        00002AAAAB048847 Unknown               Unknown Unknown
libiomp5.so        00002AAAAB01C6C8 Unknown               Unknown Unknown
a.out              00000000004030C3 MAIN__                     12 t.f90
a.out              0000000000402EAE Unknown               Unknown Unknown
libc.so.6          00002AAAAB753AF5 Unknown               Unknown Unknown
a.out              0000000000402DA9 Unknown               Unknown Unknown
[plinel@mendel-master1 ~]$ ifort -O2 -fopenmp t.f90
[plinel@mendel-master1 ~]$ ./a.out
           0
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000        1.00000000000000        1.00000000000000
   1.00000000000000
forrtl: severe (151): allocatable array is already allocated
Image              PC                Routine            Line        Source
a.out              00000000004204A7 Unknown               Unknown Unknown
a.out              00000000004036CA Unknown               Unknown Unknown
libiomp5.so        00002AAAAB069D3A Unknown               Unknown Unknown
libiomp5.so        00002AAAAB069559 Unknown               Unknown Unknown
a.out              000000000040345E Unknown               Unknown Unknown
a.out              0000000000403141 Unknown               Unknown Unknown
libiomp5.so        00002AAAAB074BC3 Unknown               Unknown Unknown
libiomp5.so        00002AAAAB048847 Unknown               Unknown Unknown
libiomp5.so        00002AAAAB01C6C8 Unknown               Unknown Unknown
a.out              0000000000403027 Unknown               Unknown Unknown
a.out              0000000000402EAE Unknown               Unknown Unknown
libc.so.6          00002AAAAB54FAF5 Unknown               Unknown Unknown
a.out              0000000000402DA9 Unknown               Unknown Unknown
[plinel@mendel-master1 ~]$ uname -a
Linux mendel-master1 3.10.0-229.11.1.el7.x86_64 #1 SMP Thu Aug 6 01:06:18 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Patrice_l_ · ‎09-15-2015

Hi,

I mean the bug looks very similar but with omp task this time. I dont understand why you cannot reproduce it. here is what i have :

ifort -V
Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.0.109 Build 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

$ ifort -O0 -C -g -traceback -fopenmp t.f90 
$ ./a.out 
           0
   1.00000000000000        1.00000000000000        1.00000000000000     
   1.00000000000000        1.00000000000000        1.00000000000000     
   1.00000000000000        1.00000000000000        1.00000000000000     
   1.00000000000000     
forrtl: severe (151): allocatable array is already allocated
Image              PC                Routine            Line        Source             
a.out              0000000000421A87  Unknown               Unknown  Unknown
a.out              0000000000404B20  foo_IP_toto_               36  t.f90
libiomp5.so        00002AAAAB069D3A  Unknown               Unknown  Unknown
libiomp5.so        00002AAAAB069559  Unknown               Unknown  Unknown
a.out              0000000000403722  foo_IP_toto_               33  t.f90
a.out              000000000040329D  MAIN__                     14  t.f90
libiomp5.so        00002AAAAB074BC3  Unknown               Unknown  Unknown
libiomp5.so        00002AAAAB048847  Unknown               Unknown  Unknown
libiomp5.so        00002AAAAB01C6C8  Unknown               Unknown  Unknown
a.out              00000000004030C3  MAIN__                     12  t.f90
a.out              0000000000402EAE  Unknown               Unknown  Unknown
libc.so.6          00002AAAAB753AF5  Unknown               Unknown  Unknown
a.out              0000000000402DA9  Unknown               Unknown  Unknown
$ ifort -O2 -fopenmp t.f90 
$ ./a.out 
           0
   1.00000000000000        1.00000000000000        1.00000000000000     
   1.00000000000000        1.00000000000000        1.00000000000000     
   1.00000000000000        1.00000000000000        1.00000000000000     
   1.00000000000000     
forrtl: severe (151): allocatable array is already allocated
Image              PC                Routine            Line        Source             
a.out              00000000004204A7  Unknown               Unknown  Unknown
a.out              00000000004036CA  Unknown               Unknown  Unknown
libiomp5.so        00002AAAAB069D3A  Unknown               Unknown  Unknown
libiomp5.so        00002AAAAB069559  Unknown               Unknown  Unknown
a.out              000000000040345E  Unknown               Unknown  Unknown
a.out              0000000000403141  Unknown               Unknown  Unknown
libiomp5.so        00002AAAAB074BC3  Unknown               Unknown  Unknown
libiomp5.so        00002AAAAB048847  Unknown               Unknown  Unknown
libiomp5.so        00002AAAAB01C6C8  Unknown               Unknown  Unknown
a.out              0000000000403027  Unknown               Unknown  Unknown
a.out              0000000000402EAE  Unknown               Unknown  Unknown
libc.so.6          00002AAAAB54FAF5  Unknown               Unknown  Unknown
a.out              0000000000402DA9  Unknown               Unknown  Unknown

jimdempseyatthecove · ‎09-15-2015

Though this shouldn't be necessary, try replacing PRIVATE with FIRSTPRIVATE for the allocatable variables that are known to not be allocated.

I think what is happening PRIVATE(SomeAllocatableNotAllocated) is not copying in the "not currently allocated" status.

Jim Dempsey

Patrice_l_ · ‎09-15-2015

Yes, the same you suggested for the other bug. Now I want to make sure I'm not the only seeing this behavior since Kevin Daivs didnt reproduce the error.