|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sat Mar 07, 2020 11:15 am Post subject: Compiler gets confused by unUSEd module procedure |
|
|
FTN95 8.51 fails to compile some of the files in Lapack95, a large package available from Netlib. I have narrowed down the problem, and find that the presence of unUSED overlaid module procedures in a module declaration file confuses the compiler into rejecting perfectly valid code.
File lapint.F90 contains two modules.
Module APACK contains overlaid routines SDTSVB and DDTSVB that differ only in the size of reals, and are both called by the interface name NEW_DTSVB. The module also contains a routine with the interface name PERR.
Module BPACK contains diferent versions of SDTSVB and DDTSVB, but one of the arguments, B, which was 2-dimensional in APACK, is now a 1-dimensional array.
File ddts.f90 uses only PERR from APACK and OLD_DTSVB from BPACK.
Compile as follows:
Code: | ftn95 /Cfp /define USE_NEW 1 lapint.F90
ftn95 ddts.f90
[FTN95/Win32 Ver. 8.51.0 Copyright (c) Silverfrost Ltd 1993-2019]
0013) CALL OLD_DTSVB(N,NRHS,DL,D,DU,B,LDB)
*** No matching specific procedure for generic overloaded name OLD_DTSVB
1 ERROR [<NEW_DDTSVB> FTN95 v8.51.0]
*** Compilation failed |
To see that there is no bug, run the code through Gfortran:
Code: | gfortran -DUSE_NEW -c lapint.F90 ddts.f90 |
The module file, lapint.F90:
Code: | MODULE APACK
INTERFACE PERR
SUBROUTINE XERBLA(NAME)
CHARACTER(LEN=*), INTENT(IN) :: NAME
END SUBROUTINE XERBLA
END INTERFACE PERR
#ifdef USE_NEW
INTERFACE NEW_DTSVB
SUBROUTINE SDTSVB(N,NRHS,DL,D,DU,B,LDB)
INTEGER, PARAMETER :: WP = KIND(1.0E0)
REAL(WP), INTENT(INOUT) :: DL(*), D(*)
REAL(WP), INTENT(IN) :: DU(*)
REAL(WP), INTENT(INOUT) :: B(LDB,*)
INTEGER, INTENT(IN) :: N, NRHS, LDB
END SUBROUTINE SDTSVB
SUBROUTINE DDTSVB(N,NRHS,DL,D,DU,B,LDB)
INTEGER, PARAMETER :: WP = KIND(1.0D0)
REAL(WP), INTENT(INOUT) :: DL(*), D(*)
REAL(WP), INTENT(IN) :: DU(*)
REAL(WP), INTENT(INOUT) :: B(LDB,*)
INTEGER, INTENT(IN) :: N, NRHS, LDB
END SUBROUTINE DDTSVB
END INTERFACE NEW_DTSVB
#endif
END MODULE APACK
MODULE BPACK
INTERFACE OLD_DTSVB
SUBROUTINE SDTSVB(N,NRHS,DL,D,DU,B,LDB)
INTEGER, PARAMETER :: WP = KIND(1.0E0)
REAL(WP), INTENT(INOUT) :: DL(*), D(*)
REAL(WP), INTENT(IN) :: DU(*)
REAL(WP), INTENT(INOUT) :: B(*)
INTEGER, INTENT(IN) :: N, NRHS, LDB
END SUBROUTINE SDTSVB
SUBROUTINE DDTSVB(N,NRHS,DL,D,DU,B,LDB)
INTEGER, PARAMETER :: WP = KIND(1.0D0)
REAL(WP), INTENT(INOUT) :: DL(*), D(*)
REAL(WP), INTENT(IN) :: DU(*)
REAL(WP), INTENT(INOUT) :: B(*)
INTEGER, INTENT(IN) :: N, NRHS, LDB
END SUBROUTINE DDTSVB
END INTERFACE OLD_DTSVB
END MODULE BPACK |
The second file, ddts.f90, has to be put into a follow-on post. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sat Mar 07, 2020 11:16 am Post subject: |
|
|
The second file, ddts.f90:
Code: | SUBROUTINE NEW_DDTSVB(DL,D,DU,B)
USE BPACK, ONLY: OLD_DTSVB
USE APACK, ONLY: PERR
IMPLICIT NONE
INTEGER, PARAMETER :: WP = KIND(1.0D0)
REAL(WP), INTENT(INOUT) :: DL(:), D(:), B(:)
REAL(WP), INTENT(IN) :: DU(:)
INTEGER :: N, NRHS, LDB
INTRINSIC MAX, SIZE
LDB = MAX(1,SIZE(B,1))
N = SIZE(D)
NRHS = 1
CALL OLD_DTSVB(N,NRHS,DL,D,DU,B,LDB)
CALL PERR('DDTSVB')
END SUBROUTINE NEW_DDTSVB |
-----------------
Once again I noticed this annoying habit of the forum software. In a long post such as this, after composing and clicking on Preview, I see the whole message and proofread it, then click on Submit. Then, I see the tail of the post was cut off. I have made a habit of saving the whole post in a text file before trying to post anything, so that I do not have to recreate the cut-off part from memory. What is annoying is the unpredictability of what happens between Preview and Submit. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Mon Mar 09, 2020 9:05 am Post subject: |
|
|
mecej4
Thank you for the bug report. I have logged it for investigation. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Wed Mar 25, 2020 9:32 am Post subject: |
|
|
This failure has now been fixed for the next release of FTN95. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Wed Mar 25, 2020 12:00 pm Post subject: |
|
|
Thank you. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|