So far, we have accepted no routines that do not also include a row-major equivalent, both for BLAS and for LAPACK. We hope to continue this. There are as yet only a few users of the row-major LAPACK/BLAS that I am aware of, but I believe that this is a chicken/egg problem.
Some people insist on using row-major arrays in C, but if they have access to a BLAS/LAPACK that supports it, they find the performance is no better than what they get with simple loops, or that it is calling the col-major in a naive way, and cutting the problems size they can solve in half by copying. Therefore, people with row-major bias don't call the stuff 'cause it doesn't help them, and the problem continues.
It is my belief, therefore, that good-quality row-major stuff must be produced before significant demand will appear. If I'm wrong, I guess we'll someday drop support for row-major, but I don't think this will be the case over a long enough time line.
Therefore, despite it being a hassle, having a good quality row-major implementation is critical for getting an LAPACK routine into ATLAS. For many routines, since we have row-major BLAS, the algorithm stays the same, and only some pointer arithmetic need be changed.
Other routines in LAPACK (GETRF is one) have a built in algorithmic bias towards column-major (in GETRF, this is doing row-pivoting), and another algorithm with the same stability and usage characteristics should be employed for row-major (eg., column-pivoting, for GETRF).
Clint Whaley 2012-07-10