============================================================================
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 ...

Fix some minors errors found while porting under Windows

Last round of modifications to the comments for the generation of the manpages

Merged revisions 609-614 via svnmerge from
https://jason@icl.cs.utk.edu/svn/lapack-dev/lapack/branches/SC08-release

........
  r609 | julie | 2008-12-16 17:17:52 -0500 (Tue, 16 Dec 2008) | 1 line

  Polish routines to fit the LAPACK framework and allow manpages generation
........
  r610 | langou | 2008-12-19 12:12:38 -0500 (Fri, 19 Dec 2008) | 30 lines

  bug reported on the forum
  https://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=854

  the complete thread is available at
  http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/635192e11beadb93#

  Tobias Burnus also sent us an email:

  > Hello,
  >
  > this was reported at
  > http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/635192e11beadb93#
  >
  > The problem is the line 47:
  >
  > 47:       IF( M.EQ.0 .OR. A(M, 1).NE.ZERO .OR. A(M, N).NE.ZERO ) THEN
  >
  > If M == 0 the one accesses A(0,1) which is invalid as the lower bound is 1
  > and not 0.
  >
  > Note: Contrary to C there is no left-to-right evaluation of expressions in
  > Fortran; the order is left to the compiler. One might assume that a smart
  > compiler does not evaluate "A(M,1)" if "M==0", however, there is nothing in
  > the standard guarantees this.
  >
  > If bounds checks are turned on (see post at the URL above), gfortran aborts
  > with an out-of-bounds error.
........
  r611 | julie | 2008-12-19 15:00:58 -0500 (Fri, 19 Dec 2008) | 5 lines

  Modify the formatting of the comments.
  Replace Note and Notes section by Further Details
  This allow the manpages to be generated corectly.
........
  r612 | julie | 2008-12-19 16:29:21 -0500 (Fri, 19 Dec 2008) | 3 lines

  Reformat the xblas routines comments to be able to generate the manpages

........
  r613 | julie | 2008-12-19 16:30:31 -0500 (Fri, 19 Dec 2008) | 1 line

  Update version number
........
  r614 | jason | 2008-12-27 09:44:45 -0500 (Sat, 27 Dec 2008) | 13 lines

  Fix non-short-circuited tests in ILAxL{C,R}.

  Fortran doesn't short-circuit logical operators, so the check that the leading
  dimension /= 0 may not prevent indexing into a 0-length array.

  Reported by "hes selex" in
    http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/635192e11beadb93
  and forwarded to the LAPACK maintainers by Tobias Burnus <burnus@net-b.de>.

  Chalk up more bugs found by gfortran's diagnostics!

Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Cc: Tobias Burnus <burnus@net-b.de>
........

XBLAS: Added gbmv2 (including test codes).

This routines computes the matrix product:

    y  <-  alpha * op(A) * (x_head + x_tail) + beta * y

where A is a general banded matrix.

XBLAS: Added hemv2 (including test codes).

This routines computes the matrix product:

  y  <-  alpha * A * (x_head + x_tail) + beta * y

where A is a complex Hermitian matrix.

XBLAS: Added symv2 (including tests).

symv2 performs

  y  <-  alpha * A * (x_head + x_tail) + beta * y

where A is a symmetric matrix.

XBLAS: Fix increment adjustment in do_test_axpby.

We need to double the increment for complex cases.

XBLAS: Fix bug in testgen_BLAS_[cz]dot2.

Wrong parameter was being passed to gen_y_to_cancel.
Should pass n_fix2+1 instead of k+1, since k and n_fix2
differ by factor of two for complex case.

XBLAS: Fix bug in testing/test-dot2/testgen_BLAS_[sd]dot2.

Scaling factor to compute x_tail was being rounded to integer,
and thus was producing all zeros for x_tail (and hence didn't
test whether *mv2 routines were looking at x_tail at all).

XBLAS: Removed unused variable x_vec in testing/test-symv/do_test_symv.c.

XBLAS: Make argument error return codes more specific in gbmv.

Should return -k if the k-th argument is in error, instead of just 0.

XBLAS: Fix lda check in gbmv.

For banded storage lda can be smaller than n or m.

XBLAS: Fix lda check in gemv.

We need to raise error if lda < m for column major format,
and lda < n for row major format.  Previously it was checking
for lda < leny.

Also test lda in do_test_gemv more carefully.

Move LAPACK trunk into position.