Problem with OpenMP

[MR]

Dear group,
this looks to me like a compiler bug, unless I'm missing something
obvious with OpenMP. The attached code compiles but gives a
segmentation fault at runtime (or a random behaviour depending on
OMP_NUM_THREADS).

Best regards,
Marco Restelli


ifort -openmp -o ompbug ompbug.f90
export OMP_NUMTHREADS=1
./ompbug
[... random numbers]
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
libpthread.so.0 00007FE20CC878AB Unknown Unknown Unknown
libiomp5.so 00007FE20D1DAEFA Unknown Unknown Unknown
forrtl: severe (174): SIGSEGV, segmentation fault occurred

ifort -V
Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20091012 Package ID: l_cprof_p_11.1.056
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.


module mod_m

implicit none

public :: t_m, new_tm

type t_m
integer, allocatable :: m(:)
end type t_m

contains

pure function new_tm(m_in) result(t)
type(t_m) :: t
integer, intent(in) :: m_in(:)

allocate( t%m(size(m_in)) )
t%m = m_in
end function new_tm

end module mod_m


program main

use mod_m, only: t_m, new_tm

implicit none

integer :: iv(3)
type(t_m) :: t

iv = (/ 1 , 2 , 3 /)

!$omp parallel shared(iv,t) default(none)

!$omp master

t = new_tm(iv)
write(*,*) "Value of t%m ", t%m

!$omp end master

!$omp end parallel

end program main

[TimP]

mr.f90(39): error #12145: function "NEW_TM" is called as subroutine
mr.f90(40): error #12172: dereference of pointer "T" which is possibly equal to
NULL set at (file:mr.f90 line:39)

appears to confirm a compiler bug

[MR]

Quoting - tim18

mr.f90(39): error #12145: function "NEW_TM" is called as subroutine
mr.f90(40): error #12172: dereference of pointer "T" which is possibly equal to
NULL set at (file:mr.f90 line:39)

appears to confirm a compiler bug

OK, thank you.

Regards,
Marco

[Martyn_C_Intel]

Marco,
As Tim implied, the derived type does not seem to be getting copied back to the caller correctly. You can see that, for example, by inserting write(*,*) "allocated t%m", allocated(t%m) immediately after the function call. The component m has not been allocated, so attempts to access it lead to a seg fault.
The issue has been escalated to the compiler developers. We'll let you know whena fix becomes available.

I was able to make your test case work by declaring t inside new_tm as allocatable, and then allocating it explicitly. I don't know whether this could be a more general workaround, but you might like to try.

[jimdempseyatthecove]

Marco,

As a work around try this

Jim Dempsey

[cpp]module mod_m

implicit none

public :: t_m, new_tm

type t_m
integer, allocatable  :: m(:)
end type t_m

contains

pure function new_tm(m_in) result(t)
type(t_m), pointer :: t
integer, intent(in) :: m_in(:)

allocate( t )
allocate( t%m(size(m_in)) )
t%m = m_in
end function new_tm

end module mod_m


program main
use omp_lib

use mod_m, only: t_m, new_tm

implicit none

integer :: iv(3)
type(t_m), pointer :: t

iv = (/ 1 , 2 , 3 /)

!$omp parallel shared(iv,t) default(none)

!$omp master

t => new_tm(iv)

!$omp end master
!$omp barrier
write(*,*) "Value of t%m ", t%m, "thread ", omp_get_thread_num()

!$omp end parallel

end program main
[/cpp]

[jimdempseyatthecove]

And don't forget to add a routine to deallocate t

Jim

[MR]

Quoting - jimdempseyatthecove

And don't forget to add a routine to deallocate t

Jim

Martyn, Jim,
thank you for your indications. I think that Jim's suggestion gets
very close to what I need to do, provided one is careful working with
pointers.

Regards,
Marco Restelli

[jimdempseyatthecove]

Marco

Don't be so worried about pointers. You should be taking care with all your programming not just the use of pointers. (same to be said for GOTO).

Jim Demspey

[Martyn_C_Intel]

Marco,
This issue has been fixed in an update to the 12.0 compiler, and also in the version 12.1 compiler. These are available for download from the Intel registration center.

Regards,
Martyn