LAPACK Archives

[Lapack] ScaLAPACK 2.0.1 bugs (fwd)


Thank you for reporting these bugs.  Item #5 has been fixed and committed to 
the ScaLAPACK SVN repository a few weeks ago.   For #6, I can look into this as 

It would be great if you would like to send your patches for the others - just 
email them directly to me.



---------- Forwarded message ----------
Date: Fri, 30 Mar 2012 13:57:16 -0500 (CDT)
From: Lee Killough <killough@Domain.Removed><mailto:killough@Domain.Removed>
To: scalapack@Domain.Removed<mailto:scalapack@Domain.Removed>
Cc: naromero@Domain.Removed<mailto:naromero@Domain.Removed>
Subject: ScaLAPACK 2.0.1 bugs

There are several bugs in ScaLAPACK 2.0.1:

1. pslaqr4.f and pdlaqr4.f, line 457:

                     CALL SGEMM( 'N', 'N', KLN, NH, NH, ONE,
     $                    A( KKROW+(ICOL-1)*LDA ), LDA, V, LDV, ZERO,
     $                    ZERO, WORK, KLN )

                     CALL DGEMM( 'N', 'N', KLN, NH, NH, ONE,
     $                    A( KKROW+(ICOL-1)*LDA ), LDA, V, LDV, ZERO,
     $                    ZERO, WORK, KLN )

There is an extra ZERO argument. It looks like someone wrapped the ZERO
argument to the next line, to limit the length of the line, but forgot
to remove it from the previous line. This call should never work, which
probably means it's untested.

2. psdlaiect.c pdlaiect.c need to be brought up to spec with ANSI-C
prototype declarations rather than K&R style. In particular, pdlachkieee_
is missing a return type in its declaration, and is thus presumed as
returning int, making the later "return;" statement invalid.

3. PBLAS/TESTING/p*blas*tst.f, PBLAS/TIMING/p*blas*tim.f: These
programs contain DATA statements for the named common block SNAMEC
inside of the main program. DATA statements for named common block
variables must only occur in BLOCK DATA units, not main programs,
subroutines or functions. Most compilers accept it anyway but it's
not valid Fortran. I have moved them to BLOCK DATA in my local copy.

4. PBLAS/TIMING/pcblas1tim.f, PBLAS/TIMING/pzblas1tim.f: The 'PCSSCAL '
and 'PDZSCAL ' strings each have an extra space in them, making the
initializer 8 characters instead of the declared length of 7.

5. The subroutines CMPIM2 and CMPCOL are multiply-defined in p?heevr.f
and p?syevr.f, meaning if more than one of those subroutines is called,
there will be multiple definition link errors. CMPIM2 and CMPCOL should
be moved out into a separate file.

6. I am investigating the root cause, but the xdgblu test fails on
BlueGene/Q in a way which suggests, but doesn't prove, that dlacpy() is
being called with overlapping source and destination, which may violate
the Fortran assumption of non-overlapping arguments. This will require
more investigation before I'm sure it's not simply a compiler bug.

I can send my patches if you want, since I've fixed all but #6.


Lapack mailing list

-------------- next part --------------
An HTML attachment was scrubbed...

<Prev in Thread] Current Thread [Next in Thread>

For additional information you may use the LAPACK/ScaLAPACK Forum.
Or one of the mailing lists, or