- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
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
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
コピーされたリンク
8 返答(返信)
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
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.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
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
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
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
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
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.
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
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]
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
And don't forget to add a routine to deallocate t
Jim
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Quoting - jimdempseyatthecove
And don't forget to add a routine to deallocate t
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
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
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
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
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
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
