Mismatch of subroutine declarations in Lapack 3.8.0 in testing #334

Activity

1. Dichloromethane commented on Apr 19, 2019

   

   Dichloromethane

   on Apr 19, 2019

   Last edited by Dichloromethane

   Author

   More actions

   An example of what is wrong: In cerrst.f, there is

        CALL CHEEVX_2STAGE( '/', 'A', 'U', 0, A, 1,
    $                0.0D0, 0.0D0, 0, 0, 0.0D0,
    $                M, X, Z, 1, W, 1, RW, IW, I3, INFO )
   

   and in cheev_2stage.f,

     SUBROUTINE CHEEV_2STAGE( JOBZ, UPLO, N, A, LDA, W, WORK, LWORK,
    $                         RWORK, INFO )
   

   • .. Scalar Arguments ..
     CHARACTER          JOBZ, UPLO
     INTEGER            INFO, LDA, LWORK, N
     

   There is a mismatch in the third argument, where a character 'U' is passed to an
   integer argument, N.

   [Edit: I looked at the wrong routine here.]
2. langou commented on Apr 19, 2019

   

   langou

   on Apr 19, 2019

   Contributor

   More actions

   Hi @Dichloromethane

   Be careful between CHEEV_2STAGE and CHEEVX_2STAGE. This is not the same interface. I did not have time to review too much. I wanted to point this out. CHEEVX_2STAGE has RANGE in between JOBZ and UPLO in the interface.

         SUBROUTINE CHEEVX_2STAGE( JOBZ, RANGE, UPLO, N, A, LDA, VL, VU,
        $                          IL, IU, ABSTOL, M, W, Z, LDZ, WORK,
        $                          LWORK, RWORK, IWORK, IFAIL, INFO )
   

   Your help in fixing this issue is much appreciated!
   Julien.
3. Dichloromethane commented on Apr 20, 2019

   

   Dichloromethane

   on Apr 20, 2019

   Author

   More actions

   OK, let's try to get this correct this time :-)

   The caller has

        CALL CHEEVX_2STAGE( '/', 'A', 'U', 0, A, 1,
    $                0.0D0, 0.0D0, 0, 0, 0.0D0,
    $                M, X, Z, 1, W, 1, RW, IW, I3, INFO )
   

   and the callee has

     SUBROUTINE CHEEVX_2STAGE( JOBZ, RANGE, UPLO, N, A, LDA, VL, VU,
    $                          IL, IU, ABSTOL, M, W, Z, LDZ, WORK,
    $                          LWORK, RWORK, IWORK, IFAIL, INFO )
   

   C...
   REAL ABSTOL, VL, VU

   The seventh and eight arguments (VL and VU) are declared as REAL dummy arguments,
   but the actual arguments passed are 0.0D0 (double). This "works" for IEEE, because of
   the bit pattern of all zeros for both single and double zero.

   DLASET is called from cchkst2stg.f with

           CALL DLASET( 'Full', N, 1, ZERO, ZERO, SD, 1 )
   

   with

     REAL               ZERO, [...]
     PARAMETER          ( ZERO = 0.0E0, [...]
   

   and has

     SUBROUTINE DLASET( UPLO, M, N, ALPHA, BETA, A, LDA )
   
     DOUBLE PRECISION   ALPHA, BETA
   

   so a REAL is passed to a DOUBLE precision argument. Apart from being a standard
   violation, this can easily lead into trouble because (putting on my implementer's hat
   here) the argument is passed via a pointer, and a pointer to a REAL points to a
   memory location which is only guaranteed to hold four bytes of null bytes, and the
   rest of the memory, which is accessed as a double, can contain garbage. The
   pointer can also be misaligned on targets which require eight-byte alignment for
   DOUBLE precision.

   zscal is a BLAS routine which has

     SUBROUTINE ZSCAL(N,ZA,ZX,INCX)
   
     COMPLEX*16 ZA
     INTEGER INCX,N
   

   • ..
     

   • .. Array Arguments ..
     COMPLEX*16 ZX(*)
     

   which is called from zdrvls.f with

                                CALL ZSCAL( NCOLS*NRHS,
    $                                       ONE / DBLE( NCOLS ), WORK,
    $                                       1 )
   

   in effect passing a double precision value to a complex dummy argument.
   This effectively randomizes the real part; again, the code depends on luck
   to do anything useful.

   I suspect the other cases are similar - just looking at the definition should be
   enough.

   (This makes me wonder a bit why Lapack is stuck with FORTRAN 77 - style
   argument lists. Fortran 90+ compilers have been around for some time, and
   putting these routines in modules would have caught all these errors).
4. Dichloromethane commented on Apr 20, 2019

   

   Dichloromethane

   on Apr 20, 2019

   Last edited by Dichloromethane

   Author

   More actions

   The ZLANSY / ZTSQR01 issue looks like a compiler bug: If I remember correctly,
   it is legal to pass a complex array to a real dummy argument, if it is done F77-style.
   I'll dig through the standard and open a gfortran PR for this, it it applies.

   [Edit] This is not a compiler bug, this is indeed illegal code (see below).
5. Dichloromethane commented on Apr 20, 2019

   

   Dichloromethane

   on Apr 20, 2019

   Author

   More actions

   zpot02 vs. zchkhe_aa_2stage is also a double complex variable being passed to
   a double precision work array. Again, this should not be flagged (but it would be
   trivial to shut up the warning).
6. Dichloromethane commented on Apr 20, 2019

   

   Dichloromethane

   on Apr 20, 2019

   Author

   More actions

   Same thing with the complex/ real work arrays for zlange being called by ztsqr01 and
   zchkaa calling zchkhe_aa_2stage.

   Looking at the F2018 standard again, it seems that the code is illegal after all.

   15.5.2.4 Ordinary dummy variables

   1 The requirements in this subclause apply to actual arguments that correspond to nonallocatable nonpointer dummy data objects. [which is the case here].

   2 The dummy argument shall be type compatible with the actual argument.

   and 7.3.2.3 has

   5 A nonpolymorphic entity is type compatible only with entities of the same declared type.

   So, all the cases flagged in this report are indeed errors. No need to submit a PR, then.
7. julielangou

   added

   Related: Testing

   on Jul 11, 2019
8. langou

   closed this as completedin #1027on Jun 20, 2024