Compiler error GET_IM_INFO@

Hello,

the following code results in a compiler error for both the 32 bit and the 64 bit version of ftn95 version 8.60.

      SUBROUTINE MYSUB (IERR)
      INCLUDE <WINDOWS.INS>
      INTEGER*4 IERR
      INTEGER*4 IERR4
      character*256 MYFILENAME
      character*64 myformat
      integer n
      PARAMETER(n=32)
      integer width(n),height(n),nb_colours(n)
      integer nb_images
      CALL GET_IM_INFO@(MYFILENAME,
     *width(n),height(n),nb_colours(n),
     *nb_images,myformat,IERR)
      end

The problem is the 7th parameter of subroutine GET_IM_INFO@ (IERR). Compiling this code results in the following error messages:

[FTN95/x64 Ver. 8.60.0 Copyright (c) Silverfrost Ltd 1993-2019]
                ...
0011)       CALL GET_IM_INFO@(MYFILENAME,
0012)      *width(n),height(n),nb_colours(n),
0013)      *nb_images,myformat,IERR)
*** The seventh argument of GET_IM_INFO@ is passed as a reference that should
    not be a constant nor an expression
    1 ERROR  [<MYSUB> FTN95 v8.60.0]
*** Compilation failed

. No object file is generated.

If parameter ierr is substituted by ierr4 when calling GET_IM_INFO@ then the compilation is successful and the corresponding object file is generated for both the 32 bit and the 64 bit version of ftn95 (version 8.60).

Moreover if using version 8.50 of ftn95 then the erronious code above compiles successfully for both the 32 and 64 bit version of ftn95.

Regards, Dietmar

That is very strange. If the error number is 1244 then it will be the false report described in the ClearWin+ part of this forum.

I plan to take a look at it anyway.

There was no clearwin.ins argument checking in v8.50.

The error number is indeed 1244 and this is a false error message coming from the new argument checking for clearwin.ins routines.

In this context the checking works correctly with the variable IERR4 which is local. You can use a local variable as a temporary fix until the next release of FTN95 or you can use one of the methods given in https://forums.silverfrost.com/Forum/Topic/3676. Or, as a last resort, stay with v8.50 until a new FTN95 is released.

Paul,

thanks for your hint, I'm fine with /ignore 1244 and this works.

Related to this I observed another similar problem:

      INCLUDE <WINDOWS.INS>
      INTEGER SAMPLES                                      
      PARAMETER (SAMPLES=16)
      INTEGER*2 LEFT(SAMPLES), RIGHT(SAMPLES)
      INTEGER*4 IERR      
      IERR=PLAY_SOUND@(LEFT,RIGHT,SAMPLES)      
      end

Compiling this with ftn95 version 8.60 and option /ignore 1244 results in error messages mentioned below and does not produce an object file:

*** The first argument of PLAY_SOUND@ must be of INTEGER(KIND=2) type, not
    INTEGER(KIND=2)
*** The second argument of PLAY_SOUND@ must be of INTEGER(KIND=2) type, not
    INTEGER(KIND=2)
    2 ERRORS  [<main program> FTN95 v8.60.0]
*** Compilation failed

. For ftn95 version 8.51 compilation was successful. Regards, Dietmar

Dietmar, I suspect that the 8.60 bug will be seen even if you leave out /ignore 1244 when compiling your seven line subroutine, because the error number for arguments of the incorrect kind is 1240. It may be worthwhile for you to specify /ignore 1240 as an additional option with the 8.60 compiler (personal edition not yet made available).

Yes the error number to ignore is 1240.

The fault is in the new clearwin.ins and the interface for PLAY_SOUND@ (and RECORD_SOUND@). These should contain REFA2 and not REF2. The 'A' is for array and the '2' is for INTEGER(2).

Reverting to an old clearwin.ins (which uses only REF and VAL and does no checking) also 'fixes' this fault.

Thanks for your quick help, Paul, mecej4,

adding options

/ignore 1244 /ignore 1240

to the ftn95 options used in the compile in question helped and made the object file be generated as excpected.

Regards, Dietmar

'/ignore 1240 1244' also works.