I am linking some fortran code (f90) from matlab using mex and I am having matlab freeze occasionally.
In the past, I had freezing happening due to mismatch between data types (say integer*4 vs integer*8).
The code I am linking has many implicitly defined variables, so I am wondering if there is a hidden data type conflict that only occurs occasionally.
To rule out data type mismatch as the cause of the freeze, I would like to have the compiler requiring all variables to be explicitly declared.
Questions:
-
How do I get gfortran to require all variables to be explicitly declared at compile time? Failing that, is there any way to at least get warnings?
-
Is a “real” data type interpreted by gfortran as a specific kind in all architectures? If so, which one is it (real*4, real*8, …)?
-
Is there anyway to force gfortran to interpret the “real” data type as a specific kind, say “real*4”?
-
Any ideas on what makes the fortran code to freeze when called from a mex compiled routine in matlab (other than data type mismatches)?
Thanks for any help.
Until I figure this out I will be going through many lines of codes trying to list all implicitly defined variables.
Needless to say, I will be tremendously grateful to anyone who frees me from such a boring task…
Best,
G.
implicit none.real*4.-fdefault-real-8to force all variables declared asrealto be interpreted as areal*8Note (for writing more code, not necessarily trying to solve the current bug):
If you’re using Fortran 90 code, you can use
real(kind=4)orreal(kind=8)with gfortran rather than thereal*4orreal*8syntaxes. I’ve moved away from setting the real or integer size using command-line flags and instead use aninteger, parameter :: REAL_SIZEvariable to hold the appropriate number (I typically go for 4 or 8 because all the compilers I use support them, but if you want to be very portable you should use theselected_real_kindroutine)