Can I compile Fortran 90 files with a Fortran 95 compiler? There seems to be a lot for Fortran 95 but not Fortran 90.
Yes, you can compile Fortran 90 programs with a Fortran 95 compiler. Actually, most of the compilers out there are now largely but not totally compliant with Fortran 2003. Unless you have unusual requirements, you are better off with a Fortran 95/2003/2008 compiler rather than a Fortran 90 only one. Fortran 95 is somewhat of a "bug fix" to Fortran 90 ... it was a modest update based upon the experience with actually using Fortran 90, which was a huge change from Fortran 77. For example, it is easier to have memory leaks in Fortran 90 ... in Fortran 95 local allocatable variables must be automatically deallocated upon exit from a subroutine so the programmer doesn't have to explicitly do the deallocation. In Fortran 90, if the deallocation wasn't explicitly coded, a memory leak was allowed to occur.
For a free compiler, recent versions of gfortran are quite good.
This one can:
NAGWare f95 Compiler Release 5.1
See also:
Clive Page's list of Fortran Resources
Michel Olagnon's Fortran 90 List
Related
Can I compile Fortran 90 files with a Fortran 95 compiler? There seems to be a lot for Fortran 95 but not Fortran 90.
Yes, you can compile Fortran 90 programs with a Fortran 95 compiler. Actually, most of the compilers out there are now largely but not totally compliant with Fortran 2003. Unless you have unusual requirements, you are better off with a Fortran 95/2003/2008 compiler rather than a Fortran 90 only one. Fortran 95 is somewhat of a "bug fix" to Fortran 90 ... it was a modest update based upon the experience with actually using Fortran 90, which was a huge change from Fortran 77. For example, it is easier to have memory leaks in Fortran 90 ... in Fortran 95 local allocatable variables must be automatically deallocated upon exit from a subroutine so the programmer doesn't have to explicitly do the deallocation. In Fortran 90, if the deallocation wasn't explicitly coded, a memory leak was allowed to occur.
For a free compiler, recent versions of gfortran are quite good.
This one can:
NAGWare f95 Compiler Release 5.1
See also:
Clive Page's list of Fortran Resources
Michel Olagnon's Fortran 90 List
I am new to Fortran and coding in general so I apologize if my terminology is not correct.
I am using a Linux machine with the gfortran compiler.
I am doing research this summer which involves me getting a program written in about 1980 working again. It is written in Fortran 77. I have all the code as well as some documentation about it.
In its current form it I am receiving a "IEEE_UNDERFLOW_FLAG IEEE_DENORMAL" error. My first thought is that this code was meant to be developed under a different environment/architecture.
The documentation states “This program was designed to run on the HARRIS computer system. It also can be run on VAX system if the single precision variables are changed into double precision variables both in the main code and the subroutine package.”
I have tried changing the single precision variables to double precision variables, but I may have done that wrong. If this is the correct thing to do any insight would be great.
I have also tried compiling the coding with -std=legacy and -m32. I receive the same error from this as well.
Any advice to get me going in the right direction would be greatly appreciated.
"IEEE_UNDERFLOW_FLAG IEEE_DENORMAL is signalling" is not that uncommon. It is NOT an error message.
The meaning is that there are denormal numbers generated when running the code.
It may be a hint about numerical problems in your code, but it is not an error per se. Probably it means that your program finished successfully.
Fortran in its latest edition requires that all floating point exceptions that are signalling be reported when a STOP statement is executed. See gfortran IEEE exception inexact BTW, that also means that your program is not being compiled as Fortran 77 but as Fortran 2003 or higher.
Note that even if you request the Fortran 95 standard by -std=f95 the note is still displayed, but it can be controlled by the -ffpe-summary=list flag.
The linked answer also says that a way to avoid these warnings is to not finish the program by a STOP statement, but by running till the END PROGRAM. If you have something like
STOP
END
or
STOP
END PROGRAM
in your code, just remove the STOP, it is useless, if not even harmful.
You may but you don't have to be successful in getting rid of that by using double precision. If there are numerical problems in the algorithms, they will stay there even with doubles. But they may become less apparent. Or they might not, it depends. You don't have to re-write your code for that, just use -fdefault-real-8 or -freal-4-real-8 or similar. Read more about these options in your gfortran manual. You could even try quadruple precision, but double should normally be sufficient for all reasonable algorithms.
I am quite new to fortran, and only write in fortran 95 and 2003. Now I have a program that is mainly written in 95, but it is completely in fortran 77 syntax and also contains some 77 functins.
Now I need the functionality in another program, but don't want to rewrite the whole program. My idea was to replace
program my_prog
with
module my_mod
subroutine my_prog()
The replacement does not seem to work. The compiler states, that the syntax from
subroutine my_prog()
is wrong. Does anyone have some experiance with the topic, or knows if it is even possible to implement the code without rewriting it?
The correct syntax for a module subroutine sub is
module name_of_the_module
use whatever
implicit none
!some variables and interfaces
contains
subroutine sub
!here is the code of your subroutine
end subroutine sub
end module name_of_the_module
Otherwise, it should be noted, that you can call the code in FORTRAN 77 from a newer code. It is (with some exceptions) still a valid Fortran 2008 code, just in an old style. The only exception is you cannot mix free and fixed source format in one source file. That may also be your problem.
The best thing to do is to make the old functions and subroutines to conform also to the free source format (see "intersection format" here) and place them into a module as I showed above.
Merely packaging a subroutine into a module may work in some cases but it may not work in others.
There are some features of Fortran 77 that have been declared obsolete now. You have several options.
Compiler switches: Many compilers provide compile time switches to compile legacy code. This depends on compiler to compiler and may change in the future
Use tools: There are tools that people have written that allow you to convert f77 code into f90/95. For this see:
http://www.atmos.illinois.edu/courses/atms391-sp11/Fortran-converters.html
Update source manually: Some people have used floating point variables in do-loops. This may be hard using automatic tools discussed above. In such cases where legacy statements like (goto) are present you may have to work manually. For this see the following link:
http://www.cisl.ucar.edu/zine/96/fall/articles/3.f90.conversion.html
http://iprc.soest.hawaii.edu/users/furue/improve-fortran.html
In the long run it will pay that you go through the code manually line-by-line and make the changes yourself. This is the most portable solution.
I'm trying to make a Fortran 77 wrapper for C++ code. I have not found information about it.
The idea is to use from functions from a lib that is written in C++ in a Fortran 77 progran.
Does anyone know how to do it?
Thanks!
Lawrence Livermore National Laboratory developed a tool called Babel for integrating software written in multiple languages into a single, cohesive application. If your needs are simple you can probably just put C wrapper on your C++ code and call that from Fortran. However, if your needs are more advanced, it might be worth giving Babel a look.
Calling Fortran from C is easy, C from Fortran potentially tricky, C++ from Fortran may potentially become ... challenging.
I have some notes elsewhere. Those are quite old, but nothing changes very rapidly in this sort of area, so there may still be some useful pointers there.
Unfortunately, there's no really standard way of doing this, and different compilers may do it slightly different ways. Having said that, it's only when passing strings that you're likely to run into major headaches. The resource above points to a library called CNF which aims to help here, mostly by providing C macros to sugar the bookkeeping.
The short version, however is this:
Floats and integers are generally easy -- an integer is an integer, more or less.
Strings are hard (because Fortrans quite often store these as structures, and very rarely as C-style null-terminated arrays).
C is call-by-value, Fortran call-by-reference, which means that Fortran functions are always pointer-to-value, from C's point of view.
You have to care about how your compiler generates symbols: compilers often turn C/Fortran symbol foo into _foo or foo_ or some other variant (see the compiler docs).
C tends not to have much of a runtime, C++ and Fortran do, and so you have to remember to link that in somehow, at link time.
That's the majority of what you need to know. The rest is annoying detail, and making friends with your compiler and linker docs. You'll end up knowing more about linkers than you probably wanted to.
Why the variables are not initializing to zero in fortran 2003 when compared with f90?
I have a variable in a function from a file. its initialized to 0. I want to use it another function then it shows a garbage value. even for global variables also. Is there any option I need to set for fortran 2003 compiler?
You could try using -zero or /Qzero -- these will initialize local scalars to zero -- but you really should be explicitly setting initial values. Depending on the compiler to do it for you is, as you have found out, a good way to introduce bugs. Note that the option names may be different for different compilers. The ones mentioned are for Intel Visual Fortran.
We experienced this moving from Compaq Visual Fortran to Intel Visual Fortran. Notwithstanding his lack of familiarity with Fortran compilers, the entire post left by Workshop Alex is correct--you shouldn't rely on the compiler setting initial values. The Standard doesn't say variable values should automatically be set. Even if it did, relying on this compiler behavior is risky.
Compaq Visual Fortran automatically initializes variables. Other compilers do not. Your code needs to be fixed. You can only do that by initializing all your variables.
John
I'm unfamiliar with any Fortran compiler but I do know that in general, most compilers won't initialize global and local variables. Initialization should always be done in code. You should not rely on the compiler to do this for you.
The garbage you're seeing is probably from the stack or memory heap. Some compilers will fill the heap with zero's when allocating memory which could explain why some compilers will seem to initialize variables with 0. They haven't actually initialized anything, they're just using a memory area that happened to be filled with zero's...
There is no difference between Fortran 90 and Fortran 2003 in initialisation of variables. All valid Fortran 90 code is valid Fortran 2003, and should give the same result (except for very few obscure corner-cases where what was compiler-dependant behaviour is now specified by the standard; this is not one of those).
Now, as to why you could see a difference, it's hard to say without knowing what your compilers are, and what your code does exactly. I strongly suspect you were relying on compiler-dependant behaviour, and it broke when you changed compiler.