|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Fri Jan 20, 2017 3:07 am Post subject: INTERFACE question |
|
|
I've been using the INTERFACE definitions with no problem until I set the /DEFREAL_KIND to 2 as the compile option. Now, all of the floating point related interfaces generate an error. At the same time, I set the /DEFINT_KIND to 3, but the integer functions don't generate any errors.
The interfaces are:
Code: |
C --- type specific interface definitions for integers and floating points
interface SCIINP
subroutine sci2inp(R,C,IVAL,F,NDIG)
INTEGER R,C,F,NDIG
integer*2 IVAL
end
subroutine sci4inp(R,C,IVAL,F,NDIG)
INTEGER R,C,F,NDIG
integer*4 IVAL
end
end interface
interface scfinp
SUBROUTINE SCF4INP(R,C,FVAL,F,MAXDIG,NDIG)
REAL*4 fval
INTEGER R,C,F,NDIG,MAXDIG
end
SUBROUTINE SCF8INP(R,C,FVAL,F,MAXDIG,NDIG)
REAL*8 fval
INTEGER R,C,F,NDIG,MAXDIG
end
end interface
INTERFACE SCIOUT
subroutine sci2OUT(R,C,IVAL,NDIG)
INTEGER R,C,F,NDIG
integer*2 IVAL
end
subroutine sci4OUT(R,C,IVAL,NDIG)
INTEGER R,C,F,NDIG
integer*4 IVAL
END
END INTERFACE
INTERFACE SCFOUT
SUBROUTINE SCF4OUT(R,C,FVAL,MAXDIG,NDIG)
REAL*4 fval
INTEGER R,C,F,NDIG,MAXDIG
end
SUBROUTINE SCF8OUT(R,C,dVAL,MAXDIG,NDIG)
REAL*8 dval
INTEGER R,C,F,NDIG,MAXDIG
END
END INTERFACE
interface fcvt
logical function fcvt4(BUFF,IS,NDIG,ARES)
real*4 ares ! result
character*(*) buff
integer is,ndig
end
logical function fcvt8(BUFF,IS,NDIG,dRES)
real*8 dres ! result
character*(*) buff
integer is,ndig
end
end interface
interface icvt
logical function icvt2(BUFFER,IS,NDIG,IRES)
character*(*) buffer
integer is,ndig
integer*2 ires ! result
end
logical function icvt4(BUFFER,IS,NDIG,dRES)
character*(*) buffer
integer is,ndig
integer*4 dres ! result
end
end interface
interface FEET_TO_METERS
REAL*4 FUNCTION FEET_TO_METERS_4(VDATA,VFLAG)
REAL*4 VDATA
LOGICAL VFLAG
end
REAL*8 FUNCTION FEET_TO_METERS_8(dDATA,VFLAG)
REAL*8 dDATA
LOGICAL VFLAG
end
end interface
interface METERS_TO_FEET
REAL*4 FUNCTION METERS_TO_FEET_4(VDATA,VFLAG)
REAL*4 VDATA
LOGICAL VFLAG
end
REAL*8 FUNCTION METERS_TO_FEETS_8(dDATA,VFLAG)
REAL*8 dDATA
LOGICAL VFLAG
end
end interface
|
and the errors are:
Code: |
*** Specific procedure METERS_TO_FEETS_8 of type REAL(KIND=2) FUNCTION is too similar to METERS_TO_FEET_4 of type REAL(KIND=2)
FUNCTION for overload METERS_TO_FEET in module <number>. The arguments are too similar. (In include file
Z:\CMASTERF95\parametersandtypes.ins)
*** Specific procedure FEET_TO_METERS_8 of type REAL(KIND=2) FUNCTION is too similar to FEET_TO_METERS_4 of type REAL(KIND=2)
FUNCTION for overload FEET_TO_METERS in module <number>. The arguments are too similar.
*** Specific procedure FCVT8 of type LOGICAL(KIND=3) FUNCTION is too similar to FCVT4 of type LOGICAL(KIND=3) FUNCTION for
overload FCVT in module <number>. The arguments are too similar.
*** Specific procedure SCF8OUT of type SUBROUTINE is too similar to SCF4OUT of type SUBROUTINE for overload SCFOUT in module
<number>. The arguments are too similar.
*** Specific procedure SCF8INP of type SUBROUTINE is too similar to SCF4INP of type SUBROUTINE for overload SCFINP in module
<number>. The arguments are too similar.
5 ERRORS [<MAIN> FTN95/Win32 v8.05.0]
|
Any help would be appreciated. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7930 Location: Salford, UK
|
Posted: Fri Jan 20, 2017 9:05 am Post subject: |
|
|
For me this code on its own does not produce a compilation error even when I use an old version of the compiler.
Perhaps a context is required in order to demonstrate the issue. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1887
|
Posted: Fri Jan 20, 2017 1:22 pm Post subject: |
|
|
Do you have /ALT_kinds in FTN95.CFG, a makefile or build command script? Since the code that you showed has '*4' or '*8' following all instances of
'REAL', the option /DEFReal_kind should have no effect on the compilation.
On the other hand, you do use default-kind integer variables, so /DEFInt_kind should affect the compilation. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Fri Jan 20, 2017 6:55 pm Post subject: |
|
|
Paul,
Since you can't reproduce, I'll look at context related issues on my end to see if there is something unique. I'll post any results here. Thanks for looking.
I did try the compile with /DEFREAL_KIND 1, and there were NO errors.
I should have included this before. The command line arguments for the compile are:
Code: |
/Checkmate /persist /DEFINT_KIND 3 /DEFREAL_KIND 2 /silent /SAVE /ZEROISE /FPP /CFPP /WINDOWS /implicit_none /no_quit /wide_source
|
mejec4, there are NO default options in FTN95.cfg. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Fri Jan 20, 2017 7:31 pm Post subject: |
|
|
In PLATO, setting the DEFINT and DEFREAL options for the project appropriately, it causes the compilation error.
[/code] |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7930 Location: Salford, UK
|
Posted: Sat Jan 21, 2017 1:32 pm Post subject: |
|
|
I have tried using Plato and it still works OK for me.
Look at the local file called Buildlog produced by Plato to see what command line options it is using.
Also use /list to see what command line options are being processed by FTN95.
Otherwise you could send me a small project that illustrates the problem. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7930 Location: Salford, UK
|
Posted: Mon Jan 23, 2017 12:17 pm Post subject: |
|
|
This has identified a bug in FTN95 that has now been fixed for the next release. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7930 Location: Salford, UK
|
Posted: Mon Jan 23, 2017 4:41 pm Post subject: |
|
|
Correction: This is, in effect, an error in the program.
The effect of /defreal_kind 2 is to upgrade REAL*4 to REAL*8 and this apparently is by design. The result in this program is to break the code as reported.
My assumption (and perhaps yours) was that only default REAL should be upgraded to REAL*8.
I will leave this as needing investigation even if only to clarify the documentation. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Mon Jan 23, 2017 10:43 pm Post subject: |
|
|
Yes, actually, it was my assumption, similar to INTEGER now being interpreted at INTEGER*4 for /DEFINT_KIND.
Thanks for nailing this down! I'll make other plans to accomodate R*8!
Bill |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2555 Location: Sydney
|
Posted: Thu Jan 26, 2017 2:40 am Post subject: |
|
|
Bill,
It may simply be a personal style, but I would not consider using /DEFINT_KIND or /DEFREAL_KIND, as I consider it too dangerous if it can overriding REAL*8 or REAL*4 declarations.
Than being said, my ftn95.cfg file contains /INTL and /LOGL (and /ERROR_NUMBERS /IMPLICIT_NONE), although I think I have maintained this since using FTN77 (30 years ago !)
It would be 30 years plus since I needed to change REAL to default 64 bit/REAL*8, mainly with code from CDC/Cyber. I recall you referred to 300 code files, but explicitly defining the precision of REAL is an important documentation that should be updated.
John |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Thu Jan 26, 2017 3:55 am Post subject: |
|
|
John, you are correct that overriding the explicit declarations would be dangerous, but it would only affect the REAL declarations, just like the /DEFINT_KIND only affects those items typed as INTEGER. But, it doesn't work that way, so I'll abandon that line.
However, I am proceeding with the /DEFINT_KIND. Specifically because I have typed those items that must be I*2 or I*4, and the functions that deal with these data also have the word length hard coded. That said, that said, there are a lot of just plain INTEGER that are used, and those could be ither I*2 or I*4, and it wouldn't really matter.
The high precision math functions are all coded as R*8, and always have been. So no problem there!
The actual reason for the automatic declaration was to permit the equivalent of function overloading (like in C and C++). The INTEGER overloading worked fine, but the REAL did not, even though it was logically equivalent. It did work for explicitly typed variables and accomplished the function overloading without forcing the default float type. So, close.
Most of the code dates to around 1984-1994 (FTN 66 days for micro processor OS's), so bringing it kicking and screaming into the 21st century has been a long road. Almost there! And Silverfrost has been a wonderful tool set to use to get there!
Thanks for your interest,
Bill |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2555 Location: Sydney
|
Posted: Thu Jan 26, 2017 5:17 am Post subject: |
|
|
Paul,
You wrote: | The effect of /defreal_kind 2 is to upgrade REAL*4 to REAL*8 and this apparently is by design. The result in this program is to break the code as reported. |
I am confused by this comment. Does /defreal_kind 2 upgrade both "real(1)", "real*4" and "real" to real*8 or only "real" to real*8 ?
If it changes real*4, that could be misleading, although this is not a compiler option that I use.
Also, does/can /ALT_kinds change the instruction to /defreal_kind 8 ?
( Unfortunately, the value of kind was not defined in the standard. Because of the different real kind values in FTN95, compared to most other F95+ compilers, I nearly always use real*8, rather than real(2), real(8) or real(dp). It is amazing how many complaints I get about this. )
John |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7930 Location: Salford, UK
|
Posted: Thu Jan 26, 2017 8:08 am Post subject: |
|
|
John
Yes /DEFREAL_KIND 2 really does upgrade REAL*4 to REAL*8.
Here is some code that demonstrates this when compiled with these options.
Code: | integer*4 k4
integer(3) k3
real*4 x4
real(1) x1
print*, "integer*4 ", kind(k4)
print*, "integer(3)", kind(k3)
print*, "real*4 ", kind(x4)
print*, "real(x1) ", kind(x1)
end |
|
|
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
|