forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

INTERFACE question

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
wahorger



Joined: 13 Oct 2014
Posts: 393
Location: Morrison, CO

PostPosted: Fri Jan 20, 2017 3:07 am    Post subject: INTERFACE question Reply with quote

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
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5042
Location: Salford, UK

PostPosted: Fri Jan 20, 2017 9:05 am    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 739

PostPosted: Fri Jan 20, 2017 1:22 pm    Post subject: Reply with quote

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
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 393
Location: Morrison, CO

PostPosted: Fri Jan 20, 2017 6:55 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 393
Location: Morrison, CO

PostPosted: Fri Jan 20, 2017 7:31 pm    Post subject: Reply with quote

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


[/code]
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5042
Location: Salford, UK

PostPosted: Sat Jan 21, 2017 1:32 pm    Post subject: Reply with quote

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
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 393
Location: Morrison, CO

PostPosted: Mon Jan 23, 2017 12:50 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5042
Location: Salford, UK

PostPosted: Mon Jan 23, 2017 12:17 pm    Post subject: Reply with quote

This has identified a bug in FTN95 that has now been fixed for the next release.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5042
Location: Salford, UK

PostPosted: Mon Jan 23, 2017 4:41 pm    Post subject: Reply with quote

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
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 393
Location: Morrison, CO

PostPosted: Mon Jan 23, 2017 10:43 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 1834
Location: Sydney

PostPosted: Thu Jan 26, 2017 2:40 am    Post subject: Reply with quote

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
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 393
Location: Morrison, CO

PostPosted: Thu Jan 26, 2017 3:55 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 1834
Location: Sydney

PostPosted: Thu Jan 26, 2017 5:17 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5042
Location: Salford, UK

PostPosted: Thu Jan 26, 2017 8:08 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
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