Fortran Force 2.0

[Emmaline]

UntilI 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...

With gfortran, you can use the compiler option -fimplicit-none. This advantage is that this will catch variables that you forgot to explicitly type even if you forgot to include implicit none. Most other compilers have a similar option.

What a plain "real" means is up to the compiler -- if you have specific requirements, it is best to use a more specific declaration. The best way is to define a parameter with the selected real kind intrinsic and use that -- for a similar discussion see Fortran: integer*4 vs integer(4) vs integer(kind=4)

Let's talk about floating point arithmetic. The problem is that (ss mentioned here) MATLAB constructs both the double-precision (or double) and the single-precision (or single) data types according to IEEE Standard 754 but Fortran standard doesn't require it's default and double precision real's to conform this standard. As you can see the standard document even use another name (default real, not single-precision).

So it might be the source of bugs. The precision is lost somewhere, some variable becomes equal to 0.0 instead of being slightly bigger/smaller the 0.0 and then you divide by this value (which is exactly 0.0). Well, it can freeze the program.

Note (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) or real(kind=8) with gfortran rather than the real*4 or real*8 syntaxes. I've moved away from setting the real or integer size using command-line flags and instead use an integer, parameter :: REAL_SIZE variable 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 the selected_real_kind routine)

Now I had to reuse and modify it to make it work in Linux with gfortran. Gfortran is in fact a f90 compiler but it worked with just some minimum changes and some additional flags. However I'm having problems with the missing SAVE statements. Some COMMON structures are not SAVEd, some are, and it seems to depend on the platform (Windows/Linux) and gfortran version.

I have a large LEGACY FORTRAN program that I am trying to compile in Visual Studio 2008 and am getting errors with type mismatch between actual and dummy arguments. The type mismatch is intentional and has compiled without error for 20 years+ with Sun Fortran's f77 compiler and executes flawlessly.

To anticipate your initial response, let me say that I DO NOT want to rewrite the code; it is huge. I just want to find what options/switches, etc that will force the compiler to use legacy fortran semantics and compile the code as written without errors.

I have included a greatly simplified sample snipit of code at the end of this message to help illustrate the code that is giving the errors. I know that this is not recommended coding practice and that there are probably new fortran language features that make this approach unnecessary today. Again, I just want to force the compiler to accept the intentional type mismatches. The program works just fine this way.

I have reduced the number of arguments in the snipit belowto 3 for simplicity. The actual program has 65 arguments which in the called subroutine SUBMAN have various different types including REAL*8, REAL*4, and INTEGER*4.

But isn't there a problem with the character arguments? I have a routine that needs to handle character string records aas well as real & integer. Two of them actually;: one to read and write the two kinds of records and one to perform any one of several conversions from character strings containing numbers to real or integer, vicee-versa and everything in between. The latter is needed to process hundrsds of variables and thousands of records of varying mode elements unknown until execution. It's the length of character strings passed at the end that do me in, so I've had to find creative solutions to get around the involving wasteful extra steps and duplicate routines.

If there were a way to allow a dummy character string argument to accept an actual binary argumentwithout theroutiine getting fatally mixed up by the hidden arguments fora particular routineit would be nice.

Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

Specify the layout used by the source file. The free form layoutwas introduced in Fortran 90. Fixed form was traditionally used inolder Fortran programs. When neither option is specified, the sourceform is determined by the file extension.

This option causes all intrinsic procedures (including the GNU-specificextensions) to be accepted. This can be useful with -std= toforce standard-compliance but get access to the full range of intrinsicsavailable with gfortran. As a consequence, -Wintrinsics-stdwill be ignored and no user-defined procedure with the same name as anyintrinsic will be called except when it is explicitly declared EXTERNAL.

Some code contains calls to external procedures with mismatchesbetween the calls and the procedure definition, or with mismatchesbetween different calls. Such code is non-conforming, and will usuallybe flagged with an error. This options degrades the error to awarning, which can only be disabled by disabling all warnings via-w. Only a single occurrence per argument is flagged by thiswarning. -fallow-argument-mismatch is implied by-std=legacy.

A BOZ literal constant can occur in a limited number of contexts instandard conforming Fortran. This option degrades an error conditionto a warning, and allows a BOZ literal constant to appear where theFortran standard would otherwise prohibit its use.

Enable special treatment for lines beginning with d or Din fixed form sources. If the -fd-lines-as-code option isgiven they are treated as if the first column contained a blank. If the-fd-lines-as-comments option is given, they are treated ascomment lines.

Other flags enabled by this switch are:-fdollar-ok -fcray-pointer -fdec-char-conversions-fdec-structure -fdec-intrinsic-ints -fdec-static-fdec-math -fdec-include -fdec-blank-format-item-fdec-format-defaults

Obsolete flag. The purpose of this option was toenable legacy math intrinsics such as COTAN and degree-valued trigonometricfunctions (e.g. TAND, ATAND, etc...) for compatability with older code. Thisoption is no longer operable. The trigonometric functions are now either part of Fortran 2023 or GNU extensions.

Set column after which characters are ignored in typical fixed-formlines in the source file, and, unless -fno-pad-source, through whichspaces are assumed (as if padded to that length) after the ends of shortfixed-form lines.

By default fixed-form lines have spaces assumed (as if padded to that length)after the ends of short fixed-form lines. This is not done either if-ffixed-line-length-0, -ffixed-line-length-none orif -fno-pad-source option is used. With any of those optionscontinued character constants never have implicit spaces appendedto them to fill out the line.

Set the default integer and logical types to an 8 byte wide type. This optionalso affects the kind of integer constants like 42. Unlike-finteger-4-integer-8, it does not promote variables with explicitkind declaration.

Set the default real type to an 8 byte wide type. This option also affectsthe kind of non-double real constants like 1.0. This option promotesthe default width of DOUBLE PRECISION and double real constantslike 1.d0 to 16 bytes if possible. If -fdefault-double-8is given along with fdefault-real-8, DOUBLE PRECISIONand double real constants are not promoted. Unlike -freal-4-real-8,fdefault-real-8 does not promote variables with explicit kinddeclarations.

Set the default real type to an 10 byte wide type. This option also affectsthe kind of non-double real constants like 1.0. This option promotesthe default width of DOUBLE PRECISION and double real constantslike 1.d0 to 16 bytes if possible. If -fdefault-double-8is given along with fdefault-real-10, DOUBLE PRECISIONand double real constants are not promoted. Unlike -freal-4-real-10,fdefault-real-10 does not promote variables with explicit kinddeclarations.

Set the default real type to an 16 byte wide type. This option also affectsthe kind of non-double real constants like 1.0. This option promotesthe default width of DOUBLE PRECISION and double real constantslike 1.d0 to 16 bytes if possible. If -fdefault-double-8is given along with fdefault-real-16, DOUBLE PRECISIONand double real constants are not promoted. Unlike -freal-4-real-16,fdefault-real-16 does not promote variables with explicit kinddeclarations.

Set the DOUBLE PRECISION type and double real constantslike 1.d0 to an 8 byte wide type. Do nothing if thisis already the default. This option prevents -fdefault-real-8,-fdefault-real-10, and -fdefault-real-16,from promoting DOUBLE PRECISION and double real constants like1.d0 to 16 bytes.

Promote all INTEGER(KIND=4) entities to an INTEGER(KIND=8)entities. If KIND=8 is unavailable, then an error will be issued.This option should be used with care and may not be suitable for your codes.Areas of possible concern include calls to external procedures,alignment in EQUIVALENCE and/or COMMON, generic interfaces,BOZ literal constant conversion, and I/O. Inspection of the intermediaterepresentation of the translated Fortran code, produced by-fdump-tree-original, is suggested.

Promote all REAL(KIND=M) entities to REAL(KIND=N) entities.If REAL(KIND=N) is unavailable, then an error will be issued.The -freal-4- flags also affect the default real kind and the-freal-8- flags also the double-precision real kind. All otherreal-kind types are unaffected by this option. The promotion is alsoapplied to real literal constants of default and double-precision kindand a specified kind number of 4 or 8, respectively.However, -fdefault-real-8, -fdefault-real-10,-fdefault-real-10, and -fdefault-double-8 take precedencefor the default and double-precision real kinds, both for real literalconstants and for declarations without a kind number.Note that for REAL(KIND=KIND(1.0)) the literal may get promoted andthen the result may get promoted again.These options should be used with care and may not be suitable for yourcodes. Areas of possible concern include calls to external procedures,alignment in EQUIVALENCE and/or COMMON, generic interfaces,BOZ literal constant conversion, and I/O and calls to intrinsic procedureswhen passing a value to the kind= dummy argument. Inspection of theintermediate representation of the translated Fortran code, produced by-fdump-fortran-original or -fdump-tree-original, is suggested.

3a8082e126