- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page