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.

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.