============================================================================
authorlangou <langou@users.noreply.github.com>
Mon, 12 Jan 2009 05:17:21 +0000 (05:17 +0000)
committerlangou <langou@users.noreply.github.com>
Mon, 12 Jan 2009 05:17:21 +0000 (05:17 +0000)
commit3cff0c0c7d6f581bb14e645fbd5d035a53581446
treeb16f6163f51de9ac12a691dcb407c55cb5086ed0
parentdc20e8382624a09011f4f57fac2f0dd543a0522d
============================================================================
Bug in RFP routines xTFSM for N=1 independently reported by Jason and Julie.
============================================================================

See Jason's email DEC/27/2009: "Similar problem in xTFSM".
Jason used gfortran with -fbounds-check and got:
> At line 328 of file stfsm.f
> Fortran runtime error: Array reference out of bounds for array 'b', upper bound of dimension 1 exceeded (1 > 0)

Julie also observed the bug with MS Visual Studio.
See ticket http://icl.cs.utk.edu/trac/lapack-dev/ticket/46

The problem is the following. Sometimes in the RFP routines, we
call routines like for example
   DGEMM ( M, N, K, ... A( I, J), ...)
where M or N is 0 and A( I, J ) is out-of-bound.  The rationale was since M or
N is 0, DGEMM simply exits without doing anything, therefore the out-of-bound
A(I,J) is not an issue. Well, this is not Fortran correct.

In this commit, I have fix the problem for xTFSM. This is a fix. This is not
rocket-science and one can certainly do something more elegant ... This bug is
blocking Julie from porting on Windows so the matter was urgent.

Now RFP + ( gfortan -fbounds-check ) works fine.

TODO: find a cleaner way to fix this,

TODO: Unfortunately I believe there are other bugs like this one in other RFP
routines, always when N=1. See for example xPFTRF. I do not understand why the
TESTING with gfortran -fbounds-check do not trigger an error though ...
SRC/ctfsm.f
SRC/dtfsm.f
SRC/stfsm.f
SRC/ztfsm.f