Add gfortran -frecursive option from upstream and #1847

[brada4]

Most people assume thread-safety from single-threaded calls. This is not the case by default with gfortran. It is hinted already by LAPACK makefile.inc

[brada4]

Should fix #1847 thread safety issue

[martin-frbg]

I have been meaning to look up the reasoning behind the "only on 64bit Linux" note, for what looks more like a gfortran topic. (And I seem to remember some attempt to eliminate the need for it in Reference-LAPACK a while back).
There probably needs to be a similar change in cmake (fc.cmake ?) as well.

[brada4]

It is still there in reference lapack. Probably needs to be looked at while importing...

[hjbreg]

also discussed in #1690
also mentioned in lapack bug list and errata
http://www.netlib.org/lapack/bug_list.html
http://www.netlib.org/lapack/errata_from_342_to_350.html
and
http://wwwf.imperial.ac.uk/~mab201/20120814.html
https://web.stanford.edu/group/fan/S4/dev_info.html#lapack

[brada4]

@hjbreg OpenBLAS does not have alternative implementation of LAPACK, it just includes a copy of reference implementation. They use -frecursive with gfortran, and now so will we.

[martin-frbg]

Also discussed in http://icl.cs.utk.edu/lapack-forum/viewtopic.php?t=1930 - the one attempt to get rid of -frecursive in netlib was apparently based on a misunderstanding of the scope of the problem.

[brada4]

I think discussion there goes about gaming compiler allocating (bigger fixed size private) temporary arrays as global structures. Since there is no deep recursion in LAPACK they get allocated on the stack and we are fine.

[martin-frbg]

Yes, but the entire point of -frecursive is to keep gfortran from creating static storage for temporary arrays that it "thinks" are too big to put on the stack. (Which is probably why this is a gfortran-specific issue - just not limited to multithreaded builds and/or 64bit linux as the comment in Makefile.rule claims)

[brada4]

Exactly.... And in this issue we hit a problem that single-threaded build is presumed thread-safe, when it is not courtesy GCC.

[hjbreg]

Do not know why -frecursive was disabled by the commit 9d6f2b5 from #390

[martin-frbg]

Either he was using a different fortran compiler at that time (and got a warning about an unknown option) or he misjudged the consequences. Putting it in the middle of an unrelated changeset certainly did not help.