Default KIND

[dajum]

I have tried setting the default KIND for integers and reals to be 8 bytes. But I have found that they aren't all treated as 8 bytes when I look at variables in the debugger. It seems that variables in common blocks have all been 8 bytes, but subroutine arguments seem to be treated as 4 byte integers. I really want the code to make everything 8 bytes without having to change all the variable declarations. Is that not possible? why are they not all 8 bytes?

Thanks,

Dave

[Steven_L_Intel1]

Example, please. Note that this option only changes the default kinds - if you explicitly say REAL*4 or INTEGER(4), it won't change those.

[dajum]

From this routine:

INTEGER FUNCTION SERCHN(KEY,ROOT,LLINK,RLINK,PSN,NNAMES)

CHARACTER*(*) KEY

INTEGER ROOT,Q,P,MTRCMP

INTEGER LLINK(1),RLINK(1),PSN(1)

CHARACTER*32 NNAMES(1)

C

All these integers are 4 bytes.
But in the main routine I declare these variables:

COMMON /TAPES1 / TNAMES(MXFILE)

COMMON /TAPES2 / TLLINK(MXFILE)

COMMON /TAPES3 / TRLINK(MXFILE)

COMMON /TAPES4 / TNUM(MXFILE)

COMMON /TAPES5 / TROOT , TTAPES

INTEGER TLLINK , TRLINK , TNUM , TROOT , TTAPES


Which I end up passing to the routine in question, and they are all 8 bytes.

Is this a problem with the arrays being declared with (1) in the function?

Dave

[Steven_L_Intel1]

Please show me a (small if possible) complete program that demonstrates the problem, along with the commands you use to build it. Please also show how you determined that some of the variables are four bytes. The dimension of the arrays in the function are not relevant.

You did compile all the sources with /integer_size:64, yes?

[dajum]

Yes I used /integer_size:64 (and it is interesting to note that the documentation refers to this as integer-size and not _). What size will the character string size that is automatically included after a string in an argument list be?

Dave

[Steven_L_Intel1]

The character length parameter is the size of an address: 32-bits on a 32-bit system, 64-bits on a 64-bit system. No switchea affect this.

For most of the switches, - and _ can both be used. Nowadays we tend to prefer -.

Can you provide a complete example that shows a problem?

[dajum]

In trying to reproduce in a small sample I found I couldn't reproduce it. So I went back to my huge project and found that the offending routines were in a library that didn't get recompiled when I changed the compilation flags. So I forced the recompilation and those routines now are all I*8 like they should be. But I still have a problem that I get a stack violation when I call a fortran routine from a C routine. I'm working to see why.

Dave

[dajum]

Can you tell me why the attached example gives a stack failure?

Thanks,

Dave

[Steven_L_Intel1]

In your declaration of modtrnwrap in the C code, you use "long" to declare the character length. As I noted above, this is correct for IA-32 but wrong for x64. Use "intptr_t" instead (and change the declaration of slen in haveThermalModel.)

Perhaps this is an opportunity to rework this code to use the C interoperability features from Fortran 2003. This won't allow you to use CHARACTER(*), but may end up cleaner in other ways. This is simply an option, not a requirement. Instead of passing the string length, the Fortran routine could scan the character array for a zero value.