Silverfrost Forums

Welcome to our forums

INTERFACE question

20 Jan 2017 2:07 #18723

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:

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:

*** 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.

20 Jan 2017 8:05 #18724

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.

20 Jan 2017 12:22 #18729

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.

20 Jan 2017 5:55 #18730

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:

/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.

20 Jan 2017 6:31 #18731

In PLATO, setting the DEFINT and DEFREAL options for the project appropriately, it causes the compilation error.

[/code]

21 Jan 2017 12:32 #18735

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.

22 Jan 2017 11:50 #18742

Here's a ZIP file of the simple project that exhibits this behavior on my system.

https://drive.google.com/file/d/0B5fbkRqVCqoMeU9nb0Q3a2R3eEk/view?usp=sharing

23 Jan 2017 11:17 #18744

This has identified a bug in FTN95 that has now been fixed for the next release.

23 Jan 2017 3:41 #18745

Correction: This is, in effect, an error in the program.

The effect of /defreal_kind 2 is to upgrade REAL4 to REAL8 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.

23 Jan 2017 9:43 #18746

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

26 Jan 2017 1:40 #18759

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 REAL8 or REAL4 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

26 Jan 2017 2:55 #18760

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 I2 or I4, 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 I2 or I4, 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

26 Jan 2017 4:17 #18761

Paul,

Quoted from You The effect of /defreal_kind 2 is to upgrade REAL4 to REAL8 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)', 'real4' and 'real' to real8 or only 'real' to real8 ? If it changes real4, 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

26 Jan 2017 7:08 #18762

John

Yes /DEFREAL_KIND 2 really does upgrade REAL4 to REAL8.

Here is some code that demonstrates this when compiled with these options.

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
Please login to reply.