Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

Call back Process fortran

Hello,

We have a call back process developped in fortran with compaq 32 bits compiler.

This call back process (called CBPROC) is defined as a routine and is used as dummy argument (integer ) by the other routines.

When we perform migration to intel compiler 64 bits , the compilation fails

We tried to define CBPROC as an integer  function

We changed different compilation options and diagnostics : this allows compilation but execution fails

Best regards

V

 

0 Kudos
7 Replies
Highlighted
Valued Contributor II

Can you show us some code

Can you show us some code that reproduces the problem? Callback routines (or functions) have been a part of Fortran for a long time and there are various possibilities (both within the standard and outside, by means of common extensions). Your description does not give us the details we need to diagnose the problem.

0 Kudos
Highlighted
Black Belt

As Arjen said, we need to see

As Arjen said, we need to see the code, but here is one guess: one of your routines has a CALL to another routine with CBPROC as an argument, but the calling routine does not have CBPROC declared as EXTERNAL.

0 Kudos
Highlighted

Thanks for your replies.

Thanks for your replies.

External has already be tried too, but unsuccessfull.

Here is initial Compaq code :

 

 SUBROUTINE COMPUT(PROCID,Cbproc,ICODE)

C
 !dec$ ATTRIBUTES DLLEXPORT::COMPUT
 !dec$ ATTRIBUTES ALIAS :'Compute'::COMPUT

C     .. Local Scalars ..
 use dflib
 use kernel32

      INTEGER*4 CBPROC,ICODE
      CHARACTER*24 PROCID
C     ..
C     .. External subroutines ..
      EXTERNAL TEST
 external SETMSG
 external CFILES
 external FFILES


 integer date_time(8)
 character (len=12) rclock(3)
 Character*255 MSG

 CALL TEST(PROCID ,CbProc,ICODE)

      IF (ICODE.EQ.9) THEN 
  KCLOSE =1
  ICODE = 7
  CALL FFILES
  MSG="CALCULATION STOPPED BY USER"
  CALL SETMSG(ICODE,MSG,PROCID,CBproc)
  ELSEIF(ICODE.EQ.3) THEN
   ICODE = 5
   MSG="CALCULATION STOPPED WITH ERROR"
   CALL SETMSG(ICODE,MSG,PROCID,CBproc)
 END IF
 

 CALL CFILES(KCLOSE)

 END

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

      SUBROUTINE SETMSG(ICODE,MSG,PROCID,CBPROC)
C
C     Called by Fortran
C     for transmit message to VisualBasic
C     --------------------------------------------
 use dfcom
 use dfport
 

 integer*4 cbproc
     ! Scalar Arguments ..
      INTEGER ICODE
      CHARACTER*255 MSG
 CHARACTER*24 PROCID

 pointer (p1,i_str_out)
 integer*2 i_str_out(255)

 pointer (p2,j_str_out)
 integer*2 j_str_out(24)


 p1=ConvertStringToBSTR(MSG)
 p2=ConvertStringToBSTR(PROCID)

 WRITE(22,20200) ICODE,MSG
 IF (ICODE.NE.9) THEN
  CALL CBPROC(p2,ICODE,p1)
 END IF
 
 CALL SysFreeString(p1)
 CALL SysFreeString(p2)


C     ..
20200 FORMAT(1X,I2,A255)
      END

 

 

0 Kudos
Highlighted
Valued Contributor II

Right, in that code CBPROC is

Right, in that code CBPROC is both an integer (not a function returning an integer!) and a subroutine. I am not sure I can unravel this all (not right now anyway), but I would declare CBPROC as EXTERNAL and not as an integer. You do use the EXTERNAL statement but unless I overlook it, not for CBPROC.

 

0 Kudos
Highlighted
Black Belt

It is a bit humorous to

It is a bit humorous to declare a subroutine (which is similar to a C function of type void) as INTEGER, but I guess the compiler just ignores that type attribute when it sees a CALL statement to that subroutine.

There is still insufficient information to even detect that a problem exists. I assume that you have other code with the bodies of subroutines TEST, CFILES and FFILES that you will use to build the DLL. The code shown is accepted by IFort 17.0.6 without complaint. So, where is the problem?

0 Kudos
Highlighted
Valued Contributor II

well if I am reading this

well if I am reading this correctly passing the function name as a callback you would be passing the address of the function which will be 64 bits address not a 32 bit integer as you have declared it.

0 Kudos
Highlighted
Black Belt

Quote:andrew_4619 wrote: well

andrew_4619 wrote:
 well if I am reading this correctly passing the function name as a callback you would be passing the address of the function which will be 64 bits address not a 32 bit integer as you have declared it. 

Regardless of the size of the argument (INTEGER*1 or REAL*16), what is passed on the stack for that argument is its address, which is always the same size (32 bits for a 32 bit EXE/DLL, 64 for a 64-bit EXE/DLL). It is the callee's job to read the value at that address as a single-byte integer or 16-byte real and process the value appropriately.

0 Kudos