HPAC
Missing parameter in calls to XERBLA
Most routines (with the obvious exception of the f2c-converted xtrsyl_rec.c files) are missing the final (string length) argument in their call to XERBLA.
Looks good to me but I may not have time to run the lapack testsuite with a pure netlib+relapack build until next weekend.
No problem. I'm only maintaining this on the side, but if you find small things to change/fix, please let me know. Also, of course any pull requests are welcome :-)
Well, LAPACK testsuite suggests there are additional problems with the XSYTRF_ALLOW_MALLOC option https://github.com/xianyi/OpenBLAS/pull/2098 and with the recursion levels in GBTRF https://github.com/xianyi/OpenBLAS/pull/2099 but at the moment I barely find time to keep OpenBLAS going.
Regarding GBTRF: For small bandwidth kl that function translates into O(n/kl) deep tail recursion (instead of the desired O(log(n))):
https://github.com/HPAC/ReLAPACK/blob/d24495f875e5c6ee208b981b43b9b63b8bfcbba6/src/dgbtrf.c#L107
Instead of disabling the BR recursion, we might want to crossover to unblocked for small kl instead
https://github.com/HPAC/ReLAPACK/blob/d24495f875e5c6ee208b981b43b9b63b8bfcbba6/src/dgbtrf.c#L85-L89
Since kl is constant for the recursion, we could move that check to the non-recursive RELAPACK_dgbtrf above.
It would be even better if we could avoid the tail recursion and get back to O(log(n)), but I would need to get back to a whiteboard to figure out how/if that's possible.
Never mind my last suggestion: Since we want to do pivoting on the whole diagonal, we need to do tail recursion. But I suppose we could express that in a loop to avoid stack overflows.
Sorry for turning this into a general discussion ticket, but given that it is actually related to the originai topic - https://github.com/Reference-LAPACK/lapack/issues/339 (and linked gcc bug ticket) suggests there is a more widespread problem with (omitted) string length arguments in calls from C to Fortran. At first glance, this seems to also affect single-character arguments like the ubiquitous "U"/"L" or "N"/"T" with potentially bad effects on the stack in recursive calls.