This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

F2018 and recursive procedures


Hi,

Fortran 2018 changed how procedures without an explicit RECURSIVE
attribute are handled; now they behave as if RECURSIVE is specified.
There is a new attribute NON_RECURSIVE that the programmer can use to
mark a procedure that may not be called recursively.

While I don't know the motivations for this change, I do think it
makes sense for a number of reasons. 1) As Fortran gains other modern
features, programmers are becoming used to a more modern style, which
in many cases may include using recursion. 2) Indirect recursion can
be difficult to detect in the general case, so always assuming that
recursion might happen is safer 3) Multi-threading is becoming more
common, not only via OpenMP but also Fortran libraries being called
from other languages. Multi-threading is of course not the same as
recursion, but presents similar issues wrt. putting automatic
variables in static memory.

GFortran currently decides where to place automatic (local) variables
in a slightly idiosyncratic way. By default, local variables go on the
stack until a threshold specified by -fmax-stack-var-size (default
32768, is that bytes or number of elements?), above which they are
placed in static memory (as if the SAVE attribute were specified).
This behavior can be changed by -fno-automatic, which places
everything in static memory, mostly for dusty deck code, or by
-frecursive which puts everything on the stack regardless of size
(implied by -fopenmp).

So for -std=f2018 (and thus also -std=gnu) the behavior must be
changed so that -frecursive is the default. However, I think we should
go a step further and get rid of -frecursive and -fmax-stack-var-size.
Or to be specific, do nothing for -frecursive, and print a warning
message saying that they no longer have any effect for -fno-recursive
and -fmax-stack-var-size. I'm not proposing to change -fno-automatic
in any way.

Alternatively, one could modify -fmax-stack-var-size to work like the
-heap-arrays option in Intel Fortran, that is, allocate variables
larger than the size limit on the heap rather than in static memory.
Personally, I'm not really fond of that; if the user wants to allocate
on the heap she/he should use allocatable variables and not magic
compiler switches.

As for NON_RECURSIVE, I propose that it should not affect placing of
automatic variables, just generate an error if we detect at compile
time that it's being called recursively. So viewing it this way it
would be more a documentation feature than something which would
affect code generation.

Thoughts?

-- 
Janne Blomqvist


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]