Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
The Intel sign-in experience is changing in February to support enhanced security controls. If you sign in, click here for more information.
27557 Discussions

Segfault with ifx with openmp, recursion and allocatable

martinmath
Beginner
175 Views

The following code and variations of it often but not always abort with a segfault if compiled with option -qopenmp in Linux. Using valgrind I always see invalid reads and sometimes invalid writes and conditional jumps depending on uninitialised data, depending on the code variation I run.

Without command line option -qopenmp, everything looks fine. However, note that there is no parallel region. Traceback by valgrind points to the memory allocator.

Anyway, in order to get invalid reads (writes...), I also need recursion and a local variable with allocatable component. Interestingly, if I put the local variable tmp in a block section (and the code of the subroutine as well, obviously) then it works without complains from valgrind.

As I mentioned I have tried some variants, all of which failed. In particular I have tried it with a character(len=:), allocatable variable and some character actions. I actually see this problem in recursive parser code, where it always crashs at some point. This looks like a big show-stopper for any modern code which uses openmp, where recursion and allocatable components are common.

 

module mod

implicit none
public

type :: t
   integer, dimension(:), allocatable :: a
end type t

contains

recursive subroutine rec(c, n, x)
   integer, dimension(:), intent(in) :: c
   integer, intent(in) :: n
   type(t), intent(out) :: x
   type(t) :: tmp
   if (n > 0) then
      call rec(c, n-1, tmp)
      x%a = tmp%a
      x%a(n) = x%a(n) + 1
   else
      x%a = c
   end if
end subroutine rec

end module mod


program alloc_rec

use mod
implicit none

type(t) :: s
call rec([1,2,4], 2, s)
print *,s%a

end program alloc_rec

 

0 Kudos
8 Replies
jimdempseyatthecove
Black Belt
155 Views

While this is a compiler bug, see if the following changes resolve the issue:

 

   type(t), automatic, :: tmp

 

Note, automatic is (supposed to be) implicit with -qopenmp and/or recursive procedures.

Older Fortran standards (older versions of Intel's Fortrans), for non -qopenmp and/or recursive procedures, implicitly had UDT's and arrays SAVE.

IIF this corrects the problem, then it is likely that there is an improper IF (...) THEN ... ELSE ... ENDIF in the compiler code. IOW it is erroneously making the UDT's  static.

Please report back if this corrects the problem.

 

Jim Dempsey

martinmath
Beginner
147 Views

Thanks for the suggestion. With the block statement there is a work around. Anyway I was just checking out ifx and there are still too many bugs with more modern language features. But it looks promising.

Ron_Green
Moderator
139 Views

  I am investigating the bug.

Ron_Green
Moderator
138 Views

actually, @jimdempseyatthecove  you can change tmp to save to work around the issue

 

type(t), save :: tmp

 

still, appears to be a bug that you have to do that with IFX.  I'm checking with our OMP architect on this issue.  

IFX has to allow OMP offload so, yes, -qopenmp takes different code paths in IFX than IFORT.  IFX took a wrong turn at Albuquerque. 

JohnNichols
Valued Contributor II
130 Views

Albuquerque 2000.

I went there once for four days.  Starting raining as I landed, taxi driver said never rains here, four days later as I got on the plane it was still raining, taxi driver on way to airport said never seen this before. 

London 1969

Sir, we have never known a period of 3 weeks without rain to my father, wonderful weather. 

Never trust a weatherman, statistically they are wrong about 30% of the time. 

 

jimdempseyatthecove
Black Belt
102 Views

>>...you can change tmp to save to work around the issue

No, Ron, it is the opposite. The point is to force tmp (actually the array descriptor for tmp) to be stack allocated.

My suspicion is the error is induced in the user's program by the array descriptor for tmp being (implicitly) SAVE as would be for the older implementations of Fortran, and by explicitly tagging it with automatic (unnecessary with newer versions of Fortran) is a means to workaround this bug.

Jim Dempsey

 

Ron_Green
Moderator
119 Views

Bug ID is CMPLRLLVM-43741


Steve_Lionel
Black Belt Retired Employee
97 Views

Marking the variable AUTOMATIC has no effect on where the compiler allocates its descriptor.

Reply