views:

66

answers:

3

I am refreshing openmp a bit, and got into this weird situation. Shaved off the bunch, I created this minimal trivial case that shows the issue

program ex2
    implicit none
    integer, parameter :: n=10000000
    integer :: i
    real :: x(n)

    do i=1,n
        x(i) = 0.0d0
    enddo

end program

with no flags specified, gfortran 4.3.4 on the mac (10.6) compiles, and the program executes correctly.

However, if I enable openmp with -fopenmp, the program terminates with segmentation fault. No code get executed, apparently, as it crashes immediately. As you see, openmp is never used in the code to parallelize anything. I tried to modify the stack size, both with ulimit the -fmax-stack-var-size, and in any case, ten millions reals is not what I define a big array.

What am I doing wrong ?

A: 

Here's a dim attempt at an answer: does the openmp flag move the array from the stack to the heap ? And if so, what impact might that have ?

High Performance Mark
+2  A: 

Yes, openmp typically changes how memory is allocated. A previous discussion: http://stackoverflow.com/questions/2867680/openmp-in-fortran/2867851

Searching on the web, I found http://homepage.mac.com/eric.c/hpc/contents/documentation/How%20to%20increase%20the%20stack%20size%20on%20Mac%20OS%20X.pdf

gfortran-mp-4.3 -fopenmp ex2.f90 -Wl,-stack_size,0x40000000,-stack_addr,0xf0000000 -o ex2.exe

fixed the problem on my Mac.

M. S. B.
It works for me, but only by removing the -stack_addr specification. I get a segment overlap between the page zero segment and the stack segment. I guess that specifying the stack_size and that's it will leave the stack address arranged by the compiler.
Stefano Borini
+1  A: 

I agree to M.S.B. It's a common stack size problem. I'd recommend to allocate the x-field on the heap. I also try to avoid use arrays alloacted on the stack (as in your case stack-wise allocation happens for all local variables) completely. This prevents several nasty bugs like subroutines starting to malfunction at a certain problem size, or problems with a different stack size at another machine. Also from my experience allocation and deallocation on the heap does not cause a significant run-time overhead.

FFox