fmax-stack-var-size, was: Re: OpenMP and local arrays
Asher Langton
langton2@llnl.gov
Fri Aug 3 17:06:00 GMT 2007
On 8/3/07, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
> On Fri, Aug 03, 2007 at 09:48:06AM -0700, Asher Langton wrote:
> > On 8/2/07, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
> > > On Wed, Aug 01, 2007 at 11:39:29AM -0700, Asher Langton wrote:
> > > >
> > > > To follow up on this: Mike Kumbera pointed out the
> > > > '-fmax-stack-var-size=' option. What do you all think about adding a
> > > > flag that sets gfc_option.flag_max_stack_var_size to -1? This should
> > > > be equivalent to ifort's '-auto' and pgf90's '-Mrecursive' options
> > > > (see trans-decl.c:gfc_can_put_var_on_stack () ). Then '-fopenmp'
> > > > would also set gfc_option.flag_max_stack_var_size to -1, and -- if
> > > > there's a demand for it -- we could add a '-frecursive' option that
> > > > does the same thing, which will allow indirect recursion to work
> > > > properly.
> > > >
> > >
> > > Given your program above and some testing I did locally, I think
> > > the above suggestion with -fmax-stack-var-size seems reasonable.
> > > I have no preference about a -frecursive option, but I also
> > > haven't given it much thought.
> >
> > The max-stack-var-size fix solves some problems we've seen when
> > compiling our codes with OpenMP. I'll put together a proper patch
> > today. I think there ought be some way to set this directly, but
> > maybe it'll be enough just to make '-1' a valid argument to
> > '-fmax-stack-var-size' and document this.
> >
>
> Asher,
>
> You can test for 'gfc_option.flag_openmp != 0' in
> options.c(gfc_post_options) and then (re)set the stack
> option.
>
>
> /* For thread private storage in an OpenMP code, we need
> to (not?) use the stack. */
> if (!gfc_option.flag_openmp)
> gfc_option.flag_max_stack_var_size = -1;
Okay, that'll be easy. For testing, I had just hacked a few lines
into gfc_handle_option, but I hadn't yet tracked down the proper way
to deal with conflicting options.
Thanks,
Asher
More information about the Fortran
mailing list