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.

Would you mind checking if #8 solves this?

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 OpenMathLib/OpenBLAS#2098 and with the recursion levels in GBTRF OpenMathLib/OpenBLAS#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))):

ReLAPACK/src/dgbtrf.c

Line 107 in d24495f

const int n1 = MIN(DREC_SPLIT(*n), *kl);

Instead of disabling the BR recursion, we might want to crossover to unblocked for small kl instead

ReLAPACK/src/dgbtrf.c

Lines 85 to 89 in d24495f

    
           if (*n <= MAX(CROSSOVER_DGBTRF, 1)) { 
        
               // Unblocked 
        
               LAPACK(dgbtf2)(m, n, kl, ku, Ab, ldAb, ipiv, info); 
        
               return; 
        
           }

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 - Reference-LAPACK/lapack#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.

	if (*n <= MAX(CROSSOVER_DGBTRF, 1)) {
	// Unblocked
	LAPACK(dgbtf2)(m, n, kl, ku, Ab, ldAb, ipiv, info);
	return;
	}