C calling Fortran using stdcall and CVF

C calling Fortran using stdcall and CVF

Imagen de Mike K

I am trying to build and debug some old libraries.  I have a C dll routine calling a Fortran routine from a static library.  The C dll is built using calling convention stdcall, and the Fortran routine is built using calling convention CVF.

The C routine calls the Fortran routine like this:

   dfoefr(&igdfno, fstring[0], iostat, &istats, llen[0]);
  
and the variables are typed as:
   long igdfno  
   char *filspc 
   long iostat
   long istats
   size_t llen[1]          (unsigned int - length of filspc)
  
The Fortran routine call list is:

 SUBROUTINE DFOEFR (IGDFNO, FILSPC, IOSTAT, ISTATS)  
 
and the variables are typed as:
 INTEGER IGDFNO
 CHARACTER*(*) FILSPC
 INTEGER IOSTAT
 INTEGER ISTATS

The first two executable lines of code in the Fortran routine are:
      IOSTAT = 0
      ISTATS = 0

I can build the entire solution and step into the Fortran routine up to the 2nd executable line.  If I try to step further the program does not crash, but it jumps back to the GUI.

Rebuilding the libraries using default calling conventions is not an option since there are over 600 routines involved C calling Fortran and vice-versa, and stdcall written directly into the C code.

Suggestions?

Regards, Mike

publicaciones de 7 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de Steve Lionel (Intel)

If you are truly using the CVF convention, then you have a problem because that would expect the length of FILSPC to immediately follow the address in the argument list, whereas the C code you have puts it at the end. If you used /iface:stdref instead, then perhaps it would work better, though I see you are passing iostat by value so that too is a problem.

I wonder if the code you posted is not really representative of your actual application.

Steve
Imagen de Mike K

If I change the Fortran project to use /iface:stdref, the I get the errors like "error #5529: CHARACTER variable 'DESCR' has no length argument in routines with C or STDCALL attribute" each call list character variable in routines which are called by other routines in the library.

If I set the project to /iface:/cvf and set the routine  dfoefr to use /iface:strref , I get the error:

unresolved external symbol _DFOEFR@20 referenced in function _dfc_oefr@12

because the total call list byte length is incorrect.

Mike

 

Imagen de FortranFan

What happens if you use /iface:mixed_str_len_arg.  I think I'd to do that once with a legacy application.  Here's what Intel's help says:

Quote:

Intel User and Reference Guide wrote:

/iface:mixed_str_len_arg

Specifies argument-passing conventions for hidden-length character arguments. This option tells the compiler that the hidden length passed for a character argument is to be placed immediately after its corresponding character argument in the argument list.

This is the method used by Compaq Visual Fortran*. When porting mixed-language programs that pass character arguments, either this option must be specified correctly or the order of hidden length arguments must be changed in the source code. This option can be used in addition to other /iface options.

 

Imagen de Steve Lionel (Intel)

I was not suggesting that you change only one file. But you have inconsistencies between the CVF interface and the code you showed. Yes, if you use stdref then it downcases names, so you would also need /names:uppercase. But I think you need to step back and reevaluate what you have, because your description and paraphrase doesn't match the code you showed.

Steve
Imagen de Mike K

The only way I think I am going to be able to clean all of this up is to update the library code so that I can use the default calling conventions like all of the other C & Fortran code I manage. 

Thanks Steve

 

Imagen de Tim Prince

Quote:

Mike K wrote:

The only way I think I am going to be able to clean all of this up is to update the library code so that I can use the default calling conventions like all of the other C & Fortran code I manage. 

Thanks Steve

 

This looks right, the legacy options seem intended only for use where it isn't possible to update everything, and don't conveniently support ABI mixtures.

Inicie sesión para dejar un comentario.