[Patch, Fortran] PR42517: Bogus runtime error with -fopenmp -fcheck=recursion

[Tobias Burnus]

Janus Weil wrote:
> I recently noticed that -fcheck=recursion does not work together with
> OpenMP.

I am not sure whether on can call it -fcheck=recursion not working. If
you call the same procedure recursively or when you call it
simultaneously, you have the same problem: Static variables are shared.
Thus, strictly speaking, all procedures which can be called
simultaneously should be marked as RECURSIVE.

As this does not work, gfortran added -frecursive, which is enabled by
default and marks all procedures as recursive, i.e. all local variables
are located on the stack and not saved (unless explicitly told using the
im-/explictly given SAVE attribute).

> I think disabling the
> recursion check is most important for cases where -fopenmp is used
> together with -fcheck=all, since the other checks might still be
> useful.
>   

I would rather couple this with -frecursive (which is implied by -fopenmp);


Daniel Kraft wrote:
>   Yes, that's what TLS was made for; I hesitate to use the word "trivial"
> since it won't be, but conceptually it is: just create a __thread variable
> instead of an ordinary static one for the recursion check guard var.

I am not sure whether this is a sensible solution for this problem. As
written, the RECURSIVE attribute - and -frecursive - prevent the local
variables being in static memory, which is what matters for recursion /
parallel execution. Thus, checking, whether within a single thread a
function is called recursively or not, is kind of pointless.

There is one issue, where I am not completely sure how it should be
dealt with: SAVEd variables in parallel procedures - they are valid in
recursive procedures, but they can lead to surprising results, if one
does not take parallelization into account. (Which is a user not a
compiler problem.)

 * * *

As -fcheck=all is a strong argument, I think your patch should be
applied - but depending on using -frecursion and not on -fopenmp.

Tobias