Add SYTRS2 routine - A BLAS 3 version of SYTRS
Add SYCONV routine: convert back and forth the factorization returned by SYTRF to be able to call SYTRS2.
Modify SYSV that now is calling SYTRS2 instead of SYTRS (and also SYCONV to convert and revert the factorization returned by SYTRF).
Modify testing to have TRS but also TRS2 tested in the LIN testing for SY.

The variable N0 in xLASQ3 is INPUT/OUTPUT. (The comments said INPUT.)

The bug report and bug fix are from William Gandler (NIH/CIT). The related
emails are on the mailing list dated as follows: October 16, 2009; April 23,
2010; May 01, 2010, May 03, 2010.

typo in comments spotted by Jim

.. fixed some comments ..

from comments from A. Buttari, CNRS, France, to Julien Langou on 01/20/2010

remove comment to not include xerbla and xerbla_array

Many comment fix for allowing C Wrapper to work on MATGEN

Add descriptions of the arguments work and uplo following Paul Roberts[NAG]'s comment sent to lapack@cs.utk.edu

Fix comment following Paul Roberts'email on lapack mailing-list
I was just looking at zgbsvxx.f from LAPACK 3.2.1 and I noticed a small
mistake in some of the argument descriptions. AB, AFB, B and X are all
down as DOUBLE PRECISION rather than COMPLEX*16.

Fix issue in testing suite found by Michael Chuvelev

Fix comments in ilaprec and remove some space in Makefile

   Following bug report and fix sent by Michael Chuvelev (Intel) on Fri, 2 Apr 2010 to "lapack@cs.utk.edu".
Issue in LAPACK 3.2.1 *la_{po,sy,he}rfsx_extended.f sources. For instanse, in sla_syrfsx_extended.f:

DY is described as
*     DY             (input) REAL array, dimension (N)
*     Workspace to hold the intermediate solution.

whereas N-by-NRHS array is referenced at DY due to the following statement (line 384):

            CALL SSYTRS( UPLO, N, NRHS, AF, LDAF, IPIV, DY, N, INFO )

This may lead to an outside memory corruption. I assume one RHS should be referenced here, because all the RHSs are considered individually in the loop by J. That is, substituting NRHS by 1:

            CALL SSYTRS( UPLO, N, 1, AF, LDAF, IPIV, DY, N, INFO )

should fix the issue. This is actual for any subroutine mentioned.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

"Bug" reported by Ondra Kamenik, confirmed by Julie Langou, fixed by Jim Demmel
and Guillaume Revy. See forum post 1783.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Fix problem in xTGEX2. The threshold value is too stringent and some matrices
are failing. Relax the threshold by a factor 2. More below.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

See: http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=1783
dgges issue >> by OndraKamenik >> Tue Mar 16, 2010 6:01 am

All,

I have the following problem with dgges. For version 3.1.1 and sooner, I get a
reasonable result, for version 3.2 and 3.2.1 I get info=n+2.

I am separating eigenvalues in the unit circle from one outside the unique
circle.

The two D and E matrices have relatively well separated null spaces, the
minimum angle is acos(0.97). However, if i calculate condition numbers of
E-lambda*D of lambda=[-1:0.01:1], they are quite bad.

The matrices are attached with a small c++ program which calls dgges and sorts
eigenvalues for a better comparison. There is also a Makefile, which links with
different version of lapack.

I use the reference blas.

My question is if it is a bug in Lapack introduced between 3.2. and 3.1.1 or
the matrix is just very bad and in version 3.1.1 I was just lucky to get a
reasonable solution.

Many thanks for any help.

Ondra Kamenik

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Much more conversation on mailing list and forum [ skipped ]

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Date: Wed, 31 Mar 2010 19:53:11 -0600
From: James Demmel

This bug was introduced by changing the routine that computes Householder
transformations in the last release of LAPACK from dlarfg to the new dlarfp,
which makes the diagonal of the R factor in QR nonnegative. The bug was a
failure (INFO = N+3) in the dgges routine for computing selected deflating
subspaces of a matrix pencil A - lambda*B. I will describe the bug, a quick
fix, and implications for the floating point debugging project that Guillaume
and others of us are working on.

The bug occurred in dtgex2, in the swapping of eigenvalues (adjacent 1x1 and/or
2x2 blocks on the diagonal of the generalized Schur form) in order to compute
a selected subspace. The swapping involves QR decompositions of  small (n <= 4)
matrices.

The code in dtgex2 performs two of its own internal correctness tests (a "weak"
one and a "strong" one) to see if the swapping has been performed stably. The
two tests compute a residual in slightly different ways. The weak test passed,
but the strong test  (which can be commented out by setting the internal
parameter WANDS to be .false.)  failed, leading to returning INFO = N+3.
However, it failed by exceeding the threshold THRESH only by a factor like 1.2
or less. THRESH is set to 10*macheps*dnorm, so if we changed the (probably
somewhat arbitrary) factor from 10 to 20, it would work. Or we could set WANDS
= false.

Since Bo's name is on this routine, his comments are particularly welcome.

Guillaume and I spent a while tracking this down, and will continue to find out
why dlarfp led to a (slightly!) larger residual than the old dlarfg.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Date: Thu, 1 Apr 2010 20:01:21 -0600
From: James Demmel <demmel@cs.berkeley.edu>

Actually, on reexamining the data, this example would be fixed by
changing 10 to 11,
but let's go with 20 to be on the safe side :) . I think it would be
most efficient
if Julie or you appropriately change the one line of code in DTGEX2:

      THRESH = MAX( TEN*EPS*DNORM, SMLNUM )

All versions (S/D/C/Z) have an analogous line of code with the same
constant TEN that I would change.

Sorry, I've lost track of the Mathworks bug report on dlarfp. Can you
remind me?

Thanks,
Jim

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Fix CMakeLists.txt only blas is exported, lapack needs to be exported as well. (From Bill Hoffman)

Fix comments to generate wrapper correctly

Correct bug0050 :: An extra argument after matrix A lines 348-249 in STFSM.f causes a crash of SGEMM call sent from Alexander Kobotov (Intel) on Wed, 3 Feb 2010 to lapack@cs.utk.edu

bug0049 :: output parameter GIVPTR stays uninitialized in case of quick exit (n.eq.0) or if the rank-1 modifier is small enough in *laed8 sent by Alexander Kobotov (Intel) on Wed, 3 Feb 2010 to lapack@cs.utk.edu

Fix bug0048-Hanging could occur in *gebal if a NaN is in input matrix sent by Alexander Kobotov(Intel) to lapack on Feb 3rd 2010

Fix bug0046-Incorrectly documented RWORK workspace in ZGESDD sent by user Zbigniew on Forum (topic 1779)

Take off comment to put xerbla back in BLAS lib

Fix buggy comments reported by Intel folowing Jim's recommendation

Shorten long lines

Add testversion and testieee as executables

Following Jim and Sven report,  sgeqpf and shseqr are computational routines.  slanv2 is an auxiliary routine

Some minor comments modifications

Add make.inc for ifort

Following a complain from John Tellefson (Salina, KS), added the make of the
variant library to the testing of the variants if the variant library is not
present.

Bug 0046 fixed.

author: Vasile Sima
committer: Julien Langou

Corrected LAPACK routines dlagv2 and slagv2 based on Vasile Sima (National
Institute for Research & Development in Informatics, Bucharest, Romania)'s
email to lapack@cs.utk.edu on Monday 25 January 2010.

> Specifically, the variable WI, which is used in the line 268 (close to the
> end), is not initialized (with ZERO) in the cases "A can be deflated" and "B
> is singular" (i.e., the code segments in the lines 138-144, 148-156, and
> 158-167).  The corrected version is included in the attached archive.

Polish some comments, etc.. for the C wrapper

Remove a trailing blank line at the end of dlarfp.f following Andy May (Cardiff
University) 12/31/09's comment.

Still working on there subroutines ...  I have added a variable SAVEALPHA, I am
not sure whether it is needed or not.  What I am pretty sure of, is that the
code is correct with, the previous code without may be correct as well ...
Anyway, I like it better like this.

Darned!!! I messed up with my commit r709!!!!

This is
            " ( 1 - CONJG( TAU ) ) * ( ALPHA ) = ABS( ALPHA ) "
that needs to be true so, indeed, the previous code was correct and r709 is a
mistake. (r710 is good.) So this commit rollbacks r709 and modifies a little
r710.

This is the relevant change. This is the bug fix for the MathWorks/PatQuillen's
bug in xLARFP. The fix seems to work her in Denver ...

After three irrelevant commit ( r706, r707, r708), this is the first relevant
modifications. I believe that in the complex case, when NORMX = ZERO but ALPHI
is not ZERO (i.e. ALPHA has a complex imaginary part), then TAU needs to be
such that:

            " ( 1 - TAU ) * ( ALPHA ) = ABS( ALPHA ) "

Since we have
            ALPHR = REAL( ALPHA )
            ALPHI = AIMAG( ALPHA )
            XNORM = DLAPY2( ALPHR, ALPHI )
The way to do this is to set TAU with

            TAU = CMPLX( ONE - ALPHR / XNORM, ALPHI / XNORM )

as opposed to

            TAU = CMPLX( ONE - ALPHR / XNORM, -ALPHI / XNORM )

(Note: XNORM is used as temporary variable here)

change SAFMIN with SMLNUM
change RSAFMN with BIGNUM

remove the comments on the constraints of TAU
this comment is true for xLARFG, it is not true anymore for xLARFP

start some modification of the xLARFP routines
modification 1: remove the comments starting with ! and start them with *

Correct a bug found by Ashutosh Mahajan from Mathematics and Computer Science Division of Argonne National Labs.
Email sent on Thu, 10 Dec 2009 16:53:57 to lapack@cs.utk.edu.

I think we have a bug in dstemr.f for the case when N is 2. The following
block:

392:                   IF (CS.NE.ZERO) THEN
393:                      ISUPPZ(2*M-1) = 1
394:                      ISUPPZ(2*M-1) = 2
395:                   ELSE
396:                      ISUPPZ(2*M-1) = 1
397:                      ISUPPZ(2*M-1) = 1
398:                   END IF

should really be (note lines 394, 397):

392:                   IF (CS.NE.ZERO) THEN
393:                      ISUPPZ(2*M-1) = 1
394:                      ISUPPZ(2*M) = 2
395:                   ELSE
396:                      ISUPPZ(2*M-1) = 1
397:                      ISUPPZ(2*M) = 1
398:                   END IF

similarly the block:
415:                IF (SN.NE.ZERO) THEN
416:                   IF (CS.NE.ZERO) THEN
417:                      ISUPPZ(2*M-1) = 1
418:                      ISUPPZ(2*M-1) = 2
419:                   ELSE
420:                      ISUPPZ(2*M-1) = 1
421:                      ISUPPZ(2*M-1) = 1
422:                   END IF
423:                ELSE

should really be (note lines 418, 421):

415:                IF (SN.NE.ZERO) THEN
416:                   IF (CS.NE.ZERO) THEN
417:                      ISUPPZ(2*M-1) = 1
418:                      ISUPPZ(2*M) = 2
419:                   ELSE
420:                      ISUPPZ(2*M-1) = 1
421:                      ISUPPZ(2*M) = 1
422:                   END IF
423:                ELSE

Correct a bug found by Ashutosh Mahajan from Mathematics and Computer Science Division of Argonne National Labs.
Email sent on Fri, 11 Dec 2009 14:51:07 to lapack@cs.utk.edu.

Subject: [Lapack] bug in dsyevr.f when N = 1

when dsyevr is called with N=1, then it returns without setting up ISUPPZ values.

331:       IF( N.EQ.1 ) THEN
...
342:          IF( WANTZ )
343:      $      Z( 1, 1 ) = ONE
344:          RETURN
345:       END IF

It should rather do

IF( WANTZ )
    Z( 1, 1 ) = ONE
    ISUPPZ(1) = 1
    ISUPPZ(2) = 1
END IF

 some more typos

typo in comments

Fix bug0038 - dgelsd waas not returning iwork size

Bug report from Michael Chuvelev from Intel on DSYEVR.

======================================================================================
Date: Wed, 14 Oct 2009 02:42:06 -0600
From: "Chuvelev, Michael" <michael.chuvelev@intel.com>
To: "lapack@cs.utk.edu" <lapack@cs.utk.edu>
Subject: [Lapack] VL,   VU are referenced in lapack-3.2.1 dsyevr even if range.ne.'V'

Hello,

dsyevr contains this code (lines 360-361):

      VLL = VL
      VUU = VU

which means VL, VU is accessed regardless of RANGE.

Whereas this issue is fixed in ssyevr, for instance (lines 364-367):

      IF (VALEIG) THEN
         VLL = VL
         VUU = VU
      END IF

Best regards,

Michael.
======================================================================================

Correct problem reported by Kevin Wadleigh to keep compilers from optimizing NAN6 = NAN5*0.0

Date: Tue, 29 Sep 2009 06:17:06 -0600
From: "Chuvelev, Michael"
Subject: [Lapack] Bug in lapack-3.2.1/TESTING/EIG/zdrvgbx.f

 Hi,

please pay attention to the printing format 9998 misuse in zdrvgbx.f:

                              WRITE( NOUT, FMT = 9998 )'ZGBSVXX', FACT,
     $                             TRANS, N, KL, KU, IMAT, 7,
     $                             RESULT( 7 )
...

9998 FORMAT( ' *** In ZDRVGB, LAFB=', I5, ' is too small for N=', I5,
     $      ', KU=', I5, ', KL=', I5, /
     $      ' ==> Increase LAFB to at least ', I5 )

This would possibly lead to a segmentation fault in case of errors in zgbsvxx.

The same issue concerns other precisions too.

Best regards,

Michael.

 Fix bug0038 see out of range element access in DLASET when using DGELSS (forum topic 1582)

Commit Julien's proposed change for bug0019

remove extra definition

Fix whitespace comments detected from parser

Fix bug0023: SROTMG and DROTMG uses deprecated Fortran ASSIGN statement and assigned GOTO statement, actually fixed ROTM also

 Fix ifort flags just for Unix

 Fix variables used

 Use try_compile to look for the timing routine

Add conf file for submitting machine to LAPACK Dashboard

Better solution as we set NONE as default...WINDOWS build run great...

Need the NONE for Windows...

Add CMAKE support to LAPACK

Fixed comments on factorization in refinement routines. Found when coding in C++

In refinement routines, err_bnds initialization if-else statements should be if statements, found when coding in C++

thru -> through

fixed the variants_testing Makefile problem

Bug report sent by Alexander V. Kobotov (from Intel) on Mon, 6 Apr 2009 to "lapack@cs.utk.edu".
"c(he/sy)equb: no slamch in external lists and lsame, intrinsics not described"

[[ I did not really want to commit the previous commit, this is the follow-up commit ... ]]

Bug report sent by Alexander V. Kobotov (from Intel) on Mon, 6 Apr 2009 to "lapack@cs.utk.edu".

"(d/s)tgsen.f: iwork(1) always referenced: line 455: iwork( 1 ) = LIWMIN,
documentation says that if IJOB=0 it shouldn't, so NULL pointer causes a
sigfault."

(There is indeed the same problem for the WORK array and the IWORK array in the
complex routines.)

I have changed the header of the routines ctgsen.f, dtgsen.f, stgsen.f, and
ztgsen.f. A Fortran array needs to be of size at least 1. So IWORK is of size
at least 1. It was indeed written in the header of the routine:
"IWORK (workspace/output) INTEGER array, dimension (MAX(1,LIWORK))"
So since IWORK is of size at least 1, there is no reason not to reference it.
When there is a workspace query with IJOB.EQ.0, WORK(1) and IWORK(1) are both
set to 1.

Bug report sent by Alexander V. Kobotov (from Intel) on Mon, 6 Apr 2009 to "lapack@cs.utk.edu".

"(d/s)tgsen.f: iwork(1) always referenced: line 455: iwork( 1 ) = LIWMIN,
documentation says that if IJOB=0 it shouldn't, so NULL pointer causes a
sigfault."

There is indeed the same problem for array work.

I have changed the header of the routines ctgsen.f, dtgsen.f, stgsen.f, and
ztgsen.f. No matter what an array needs to be of size at least 1. So
IWORK is of size at least 1. It was written in the header of the routine:
"IWORK   (workspace/output) INTEGER array, dimension (MAX(1,LIWORK))"
So since IWORK is of size at least 1, there is no reason not to reference it.
When there is a workspace query with IJOB.EQ.0, IWORK(1) is set to 1.

Bug report sent by Alexander V. Kobotov (from Intel) on Mon, 6 Apr 2009 to "lapack@cs.utk.edu".
"(c/z)geesx: no lwork=-1 branch at all, info = -15 is returned while doing lquery."
I noticed that the S and D version where not exiting after WORKSPACE query as well.
Thanks Alexander. Bug corrected.

Patch from Lawrence Mulholland (NAG) on Wednesday May 6th 2009.
See forum: http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=1408.
Thanks Lawrence.

Bug reported by Julie Langou on Th. 04/30/09 thanks to the Intel Fortran
compiler on Windows.  I messed up the workspace types needed by CPOT01 and
ZPOT01, they need to be REAL (or DOUBLE PRECISION) and not COMPLEX (or DOUBLE
COMPLEX). Everything works fine on my machine with these changes. Julien.

Big commit before 3.2.1 release.
Those are just cosmetic changes to update version number and various other minor change.

Some debug write statements were present in slafts.f and dlafts.f => removed.

Updated documentation for EPIR routines. Changed ERRS_{N,C} variable names. Other cosmetic changes.

fix bug :: in DGESDD, workspace query gives a value smaller than the minimal value given in the header to run the routine

    o reported by  Guy Bencteux on Sat Dec 06 2008
    o see forum topic 846 : https://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=846

remove a min(M,N) in the minimal workspace formula when JOBZ='O' and  JOBZ = 'S' or 'A'.

Note Julie on minimal value:
Case: M > N

IF( M > N*5.0D0  ) THEN
PATH 1 -> FOR JOBZ=N : MINWORK = 7*N + N
PATH 2 -> FOR JOBZ=O: MINWORK = 5*N*N + 7*N
PATH 3 -> FOR JOBZ=S: MINWORK = 4*N*N + 7*N
PATH 4 -> FOR JOBZ=A:  MINWORK = 4*N*N + 7*N

IF M>N (but not too large)
PATH 5 -> FOR JOBZ=N : MINWORK = MAX(7*N,M) + 3*N
PATH 6 -> FOR JOBZ=O: MINWORK = 3*N + MAX (M,4*N*N + 4*N)
PATH 7 -> FOR JOBZ=S : MINWORK = 3*N + MAX (M,3*N*N + 4*N)
PATH 8 -> FOR JOBZ=A :  MINWORK = 3*N + MAX (M,3*N*N + 4*N)

GENERAL FORMULA FROM THE TWO CASES WHEN M>N
FOR N LWORK >= 3*N + max (M,7*N)
FOR O LWORK >= 3*N + max (M,5*N*N + 4*N) [instead of 3*N*N + max (M,5*N*N + 4*N) ]
FOR S ET A LWORK >= 3*N + max(M,4*N*N + 4*N) [instead of 3*N*N + max(M,4*N*N + 4*N) ]

Add xSYEQUB bibliographic reference citing Livne & Golub.

Reference: Livne, O.E. and Golub, G.H., "Scaling by Binormalization",
Numerical Algorithms, vol. 35, no. 1, pp. 97-120, January 2004.
DOI 10.1023/B:NUMA.0000016606.32820.69
Tech report version: http://ruready.utah.edu/archive/papers/bin.pdf

Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>

Fix ZLARFP and CLARFP optimizations when the vector is zero.

The x == zero branch ignored complex alphas.  The code still
functioned, but it scaled the entire zero vector.  Now that I think of
it, I should scan upwards for the scaling, too.  That will be a
separate enhancement patch; this is just the bug fix.

This patch also fixes an accidental precision shortening in ZLARFP,
which used CMPLX in the dead branch.

Reported by Igor Zhuravlov on the LAPACK web goo thingy, currently at
  http://icl.cs.utk.edu/lapack-forum/viewtopic.php?t=924
Also lead to finding a related (but different) error in the LAWN and
(accepted, still in editing) SISC paper.

Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>

The description of LDA in the header was number 8 in the header, while
LDA is the 4th argument in the interface.
=>
Rearrange the header accordingly.

Change routines to xLARFP that were missed in the first round.

Thanks to Michael Chuvelev <michael.chuvelev@intel.com> for noting
that the following routines still called xLARFG rather than xLARFP:
  cgeqpf.f   slaqp2.f   claqp2.f  claqps.f   clatrz.f   ctzrqf.f

Bug reported in message
<A43BE3D8E247E440AF3477B3CDCB0A694A132639@irsmsx504.ger.corp.intel.com> .

Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>

Return SCALE = ONE in xTRSYL for zero-dimension matrices.

I doubt if LAPACK is consistent about zero-dim matrices, but it's
worth a shot.  Plenty of discussion about their semantics on the
GNU Octave development lists.

Reported by Vasile Sima <vsima@ici.ro> in message
<1575.193.230.3.167.1235984292.squirrel@webmail.ici.ro>.

Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>

Only touch Q in {d,s}tgsen.f if WANTQ is true.

Reported by Daniel Waggoner <dwaggoner@frbatlanta.org> in message
<49AA2617.4060900@frbatlanta.org>.

Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>

Restructured loops in {c,z}la_yyrcond_{x,c} and {s,c,d,z}la_yyamv to do less comparisons.

Should call {c,z}la_heamv, not {c,z}la_syamv, from {c,z}la_porfsx_extended.

Modified {c,z}syequb to use 2*N WORK rather than 3*N.

Added Jasons patches to bring work and rwork down to 2*N in the complex refinement routines.

cgesvxx and zgesvxx need at least 3*N WORK space after changes from last bug fix

Fixed WORK/RWORK bug in complex iterative refinement routines.

Fix scaling in the transpose case of extra-precise refinement.

The row-scaling factors need passed in the transpose case.  Apparently,
none of our release tests include ill-scaled matrices.

Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>

==============================================================================
Patch from Christof Voemel, ETH Zurich.
==============================================================================
I would like to make a small change  in dlarrd/slarrd/_larrd.f.base so that the
code deals better with certain matrices from Godunov.

Could you please replace in those files the lines, after label 40,
            GL = GL - FUDGE*SPDIAM*EPS*IN - FUDGE*PIVMIN
            GU = GU + FUDGE*SPDIAM*EPS*IN + FUDGE*PIVMIN

by
            GL = GL - FUDGE*TNORM*EPS*IN - FUDGE*PIVMIN
            GU = GU + FUDGE*TNORM*EPS*IN + FUDGE*PIVMIN

(Exchange SPDIAM to TNORM).
==============================================================================

Set ithresh to 10, not 100. Removed la_linrx_max_n_errs.

Fixed typos and variable types in testing files.

Added the rest of the extra precise iterative refinement testing.

Fix out of bound access in LIN TESTING with XBLAS found with -fcheck-bounds with gfortran.
"Error in DLA_GBAMV.f line 226: forrtl: severe (408): fort: (2): Subscript #1 of the array AB has value 2 which is greater than the upper bound of 1"

Reported in http://icl.cs.utk.edu/trac/lapack-dev/ticket/45

Following a out-of-bound complaint by gfortran

Modify size in declaration of DX and DY.
It was set to 1, and 5 or N in the comments !!!!!
Put * in the declaration and N in the comments

This routine may need to be double-checked.

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