Re: GFortran - OpenMP problem with Windows XP memory


"Cirilo S. Bresolin" <cirilo.bresolin@xxxxxxxxx> wrote in message
news:95999025-2b18-4172-8783-b33e60e92a2e@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi!

I spend some time today studying the problem, but I didn't understand
if the problem is with gfortran or OpenMP or neither.
As suggested by Anony, using:

<code> double precision, save :: a(n,n), b(n,n)

c:\gfortran file.f95 -fopenmp</code>

worked well up to n=11169.


I assume you have 32-bit gfortran (because 64-bit gfortran for windows works
and also supports openMP, but has optimization problems. Possibly, not so
many people use 64-bit gfortran for windows presently). When n=11169, the
memory space for a(n,n) & b(n,n), double precision, requires about 2GB. That
almost reaches the limit of 32-bit memory address. The 32-bit memory address
put a limit here. For n --> bigger, you need 64-bit OS and 64-bit compiler.



....................................
that, as -fmax-stack-var-size, overwrites the -frecursive flag imposed
by -fopenmp flag.


A little confuse here. -fmax-stack-var-size does not overwrite -frecursive,
but set a stack size.



and Gfortran.info, as previusly previusly by Steven G. Kargl
<cite>`-fopenmp' implies `-frecursive', i.e., all local arrays will
be
allocated on the stack. When porting existing code to OpenMP, this
may lead to surprising results, especially to segmentation faults
if the stacksize is limited. </cite>


It may be better for you to pay attention on which variables are private and
which variables are shared. OpenMP manual focus on "private" and "shared"
variables. It is really unnecessary for you to pay attention which "local
variable" is on the stack. What you need to deal with is "private" and
"shared" veriables, not stack.

How to allocate a memory space for a variable is compiler's job. Compiler
should do that for you. In my personal opinion, gfortran fails to properly
allocate memory for variables. You can play the magic word "save" or set a
sufficient stack size, which is totally up to you.




.

Relevant Pages

  • Re: GFortran - OpenMP problem with Windows XP memory
    ... In my personal opinion, gfortran fails to properly ... sufficient stack size, which is totally up to you. ... The gfortran buglet* is that is also puts the local variables of the ... PROGRAM on the stack although it can be safely put in static memory. ...
    (comp.lang.fortran)
  • Re: gfortran and OpenMP
    ... Support for OpenMP in gfortran has been committed to GCC mainline. ... It fails at the link stage, with a message suggesting to me that it cannot find a thread-related function. ...
    (comp.lang.fortran)
  • Re: gfortran and OpenMP
    ... bartv@ciney:~/openmp$ gfortran -fopenmp sums.f95 ... For OpenMP the memory is put on the stack whereas the serial program ... static memory could be used as well as "y" ... Allow indirect recursion by forcing all local arrays ...
    (comp.lang.fortran)
  • Re: gfortran and OpenMP
    ... Support for OpenMP in gfortran has been committed to GCC mainline. ... your operating system have a working pthread library. ... previously with gfortran in serial mode and with other compilers in ...
    (comp.lang.fortran)
  • Re: GFortran run time error codes. Where to find them?
    ... GFortran generates for DE/ALLOCATE STAT and READ/WRITE IOSTAT specifiers ... Array reference out of bounds ... therefore I may assume they do not contain any bug. ... else which could cause memory problems besides allocatable arrays? ...
    (comp.lang.fortran)