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

[Tobias Burnus <burnus at net-b dot de>]

On 29.12.2009 22:47, Dave Korn wrote:
> Tobias Burnus wrote:
>
>   
>> Thus, checking, whether within a single thread a
>> function is called recursively or not, is kind of pointless.
>>     
> Am I missing some definition here?  AFAIK there's no other way a function
> can "recurse" except within a single context of execution.  Two different
> threads calling the same function at the same time isn't recursion, it's
> re-entrance.
>   

True, but in both cases you get in trouble if you have a local variable
in static memory - it does not matter whether it gets overwritten due to
(true) recursion or due to re-entrance. Remember that parallelization is
beyond the Fortran 2003 standard - as is OpenMP. Thus how re-entrance
with OpenMP should be treated is completely left to the compiler vendor.
One could simply (mis?)use the RECURSIVE attribute for this purpose or
simply ensure for all procedures that local variables do not end up in
static memory. gfortran has chosen the latter in line with other
compilers and has called the option -frecursion, which is implied by
-fopenmp.

Additionally, the manual currently states that -fopenmp implies
-frecursion (i.e. marking all procedures are recusive) - thus one can
argue that a __thread-based recursion check should always succeed.

In conclusion: I think a __thread check is not helpful. Additionally, I
think the change should be done for -frecursion and not only for -fopenmp.

Tobias