The source code I am working with was originally written for the Intel Fortran compiler so it has preprocessor directives such as
!DEC$ATTRIBUTES DLLEXPORT::MYDLL
!DEC$ATTRIBUTES STDCALL::MYSUBROUTINE
!DEC$ATTRIBUTES ALIAS: 'MYENTRYPOINT'::MYSUBROUTINE
How do I convert this to work with gfortran.
Mainly I want to be able to define and name entry points. Right now when I compile with gfortran every subroutine gets exposed as an entry point. Also the entry point name are all lower case with a underscore at the end.
If you place your routines into a module and put the statement PRIVATE at the top of the module, then PUBLIC :: name1, name2, only the procedures name1 and name2 will be visible outside of the module. This should follow through to a library into which you place object code containing the module. This has been supported since Fortran 90.
As already answered by #janneb, you can use the bind (C,name=X) approach to take complete control of the externally visible name of a procedure, overriding the Fortran name of the procedure. This is part of Fortran 2003 and is supported by numerous compilers for years. A possible issue with the bind(C) approach that it specifies that the calling convention of the routine should be that of C. If this is different from that Fortran and you wish to call these routines from Fortran the complexity increases. Then you would have to specify an interface to inform the calling Fortran routines that they are calling what looks like a C routine. Since people rarely care about the name visible to the linker unless they are calling from C, you might want the C calling convention?
Examples at Private function in Fortran and C/C++, FORTRAN, underscores, and GNU Autotools
GFortran supports some attributes, see
http://gcc.gnu.org/onlinedocs/gfortran/GNU-Fortran-Compiler-Directives.html#GNU-Fortran-Compiler-Directives
For changing the symbol name, you can use the bind(C, name=) specifier of ISO_C_BINDING, see e.g.
http://gcc.gnu.org/onlinedocs/gfortran/Interoperable-Subroutines-and-Functions.html#Interoperable-Subroutines-and-Functions
http://gcc.gnu.org/onlinedocs/gfortran/Interoperable-Global-Variables.html#Interoperable-Global-Variables
Related
To use a subroutine and allow the compiler to check
argument mismatch, one needs to place the defintion of that subroutine in a module, for which case, fortan creates an explicit interface for the calling unit to check argumetn mismatch etc.
For stand-alone subroutines that are not contained in a module, we say they have only "implicit interfaces" and no "explicit interfaces", so that the compiler can not check argument mismatch.
Why does not the compiler also create "explicit interfaces" for the stand-alone subroutines? What difficulties prevent the compiler from doing this?
When we are considering interfaces, we are not talking about some mythical object which may be implicit or explicit.
Consider the two main programs:
program main1
implicit none (external)
external sub
call sub
end program main1
and
program main2
implicit none (external)
interface
subroutine sub()
end subroutine sub
end interface
call sub
end program main2
These two main programs are (perhaps) concerned about the same external subroutine sub. main1 has an implicit interface for sub and main2 has an explicit interface for sub.
Whichever main program we are wondering about, the subroutine sub always has an explicit interface for itself:
subroutine sub()
implicit none (external)
call sub
end subroutine sub
I've just defined a (pretty terrible) subroutine called sub. I imagine that's going to be a popular name: next time you want to use that name (don't forget: external procedures are global entities) for an external procedure are you going to use the one I've just defined? If you aren't, how are you going to tell the compiler which sub you are talking about?
Resolution of which external subroutine sub is going to be used is often a problem for the linker, not the compiler. The compiler may never see a particular external procedure so cannot automatically generate for a program unit an explicit interface for an external procedure.1
That said, there are cases where a compiler will do some work for you:
program main3
implicit none (external)
external sub
call sub
end program main3
subroutine sub(x)
implicit none (external)
real x
end subroutine sub
(as a single file, or separate files, perhaps with specific compiling options) may well prompt your compiler to complain, just as though sub had an explicit interface inside main3.
1 An external procedure can also be defined by means other than Fortran. In such a case, the Fortran compiler doesn't need to even understand it, let alone worry about having to generate an explicit interface for it.
It simply the way the language works and have always worked since the inception in the 1950s and first standardization in 1960s.
It had little other choice back then, even though some other languages like Algol 68, or later Modula, pioneered the use of modules a decade or more later. Pascal, for example, relied on nesting.
Mind you, modules are a relatively new thing. C++ got them only a few years ago. Otherwise C (and C++) used to include files to allow the compiler to see headers from other source files by including everything into the current file. But implicit interfaces were also an option in original C.
In Fortran, the compilation units are individual program units, not source files. One can write or even automatically generate (e.g. the -gen-interfaces compiler option mentioned in the comments) interface blocks and include them using include files, but this approach is rarely recommendable.
Even though explicit interfaces would theoretically theoretically be possible without modules or included headers, such a concept does not really exist much in the programming world for traditional compiled languages.
The concept of explicit interface was introduced in Fortran 1990. It allows some new ways of calling more advanced forms of Fortran subprograms (array results, assumed shape, optional arguments,...). However it also allows checks that were not possible before. Enforcing such checks would break existing code. The success (and its lack) is to a large extent also based on backward compatibility. You cannot brake existing code so much - it would really be a lot.
Compilers will now often warn you that you are doing something not allowed, that the call of an external subprogram is not conforming, if you allow such warnings and if you enable or do not disable such warnings. But it will always remain a warning and it does not bring you the new possibilities. Legacy codes remain working.
These warnings are also possible at the linking stage, especially when link-time optimizations are used.
What does it mean when the intrinsic keyword is added to the use statement for a module, as in the following example?
use, intrinsic :: iso_c_binding
(From
7.1 Overview of Fortran interface, FFTW 3.3.6-pl1)
Does it specify that a module of that name provided with the compiler should be used, even if there is another module of the same name written by the user?
With use, intrinsic :: ... the intrinsic module is indeed chosen.
There is perhaps a slight subtlety in the question worth addressing. With regards to "a module of that name provided with the compiler should be used", this "should" doesn't indicate a preference but a strong requirement. That is, if there's no such intrinsic module then compilation cannot succeed. This shouldn't be a problem with iso_c_binding but compilers often offer their own non-standard intrinsic modules.
There is no way to say "use the intrinsic module if it's available, but the user-provided one if not".
In the documentation of the GNU Fortran compiler, for a specific intrinsic function, there is a standard. For example, CPU_TIME is an intrinsic procedure for which it is indicated that the standard is Fortran 95 and later. My question is about the meaning of this.
I understand the Fortran standard to be like a set of rules to follow for your code to be defined as standard-compliant (to Fortran 77,90,95,2003 or 2008). Does this mean that CPU_TIME can only be used with Fortran 95+? Actually, I already know the answer, I can use CPU_TIME within a Fortran 77 file with the .f extension without the compiler to complain, compiling with a Gfortran version > 5. Is that because the compiler is able to treat any standard encountered in a code? I am aware of the -std flag but how can I be sure that for instance a Fortran 77 code uses only intrinsic procedures for Fortran 77?
Short answer, you can not distinguish standard below f95 with gnu compilers. From f95 and above, you can use the option -std to force the compiler to consider features of standard above as errors.
Long answer:
The documentation of gnu compiler says this:
-std=std
Specify the standard to which the program is expected to conform, which may be one of ‘f95’, ‘f2003’, ‘f2008’, ‘gnu’, or ‘legacy’. The
default value for std is ‘gnu’, which specifies a superset of the
Fortran 95 standard that includes all of the extensions supported by
GNU Fortran, although warnings will be given for obsolete extensions
not recommended for use in new code. The ‘legacy’ value is equivalent
but without the warnings for obsolete extensions, and may be useful
for old non-standard programs. The ‘f95’, ‘f2003’ and ‘f2008’ values
specify strict conformance to the Fortran 95, Fortran 2003 and Fortran
2008 standards, respectively; errors are given for all extensions
beyond the relevant language standard, and warnings are given for the
Fortran 77 features that are permitted but obsolescent in later
standards. ‘-std=f2008ts’ allows the Fortran 2008 standard including
the additions of the Technical Specification (TS) 29113 on Further
Interoperability of Fortran with C and TS 18508 on Additional Parallel
Features in Fortran.
- `-std=f95` will consider features above f95 as errors
- `-std=f2003` will consider features above f2003 as errors
- `-std=f2008` will consider features above f2008 as errors
- etc.
You might want to check with other compilers.
Easy verification:, compile the following program (courtesy of Fortran wiki) with and without the option -std=f95 and see what happens.
module class_Circle
implicit none
private
real :: pi = 3.1415926535897931d0 ! Class-wide private constant
type, public :: Circle
real :: radius
contains
procedure :: area => circle_area
procedure :: print => circle_print
end type Circle
contains
function circle_area(this) result(area)
class(Circle), intent(in) :: this
real :: area
area = pi * this%radius**2
end function circle_area
subroutine circle_print(this)
class(Circle), intent(in) :: this
real :: area
area = this%area() ! Call the type-bound function
print *, 'Circle: r = ', this%radius, ' area = ', area
end subroutine circle_print
end module class_Circle
program circle_test
use class_Circle
implicit none
type(Circle) :: c ! Declare a variable of type Circle.
c = Circle(1.5) ! Use the implicit constructor, radius = 1.5.
call c%print ! Call the type-bound subroutine
end program circle_test
I am a newbie to Fortran. Please look at the code below:
c main program
call foo(2)
print*, 2
stop
end
subroutine foo(x)
x = x + 1
return
end
In some implementations of Fortran IV, the above code would print a 3. Why is that? Can you suggest an explanation?
How do you suppose more recent Fortran implementations get around the problem?
Help is very much appreciated. Thank You.
The program breaks the language rules - the dummy argument x in the subroutine is modified via the line x = x + 1, but it is associated with something that is an expression (a simple constant). In general, values that result from expressions cannot be modified.
That specific code is still syntactically valid Fortran 2008. It remains a programming error in Fortran 2008 - as it was in Fortran IV/66. This isn't something that compilers are required to diagnose. Some may, perhaps with additional debugging options, and perhaps not till runtime.
Because the program breaks the language rules anything could happen when you run the program. Exactly what depends on the code generated by the compiler. Compilers may have set aside modifiable storage for the value that results from the expression such that it internally looks like a variable (the program might print three and the program carries on), that modifiable storage might be shared across the program for other instances of the constant 2 (suddenly the value of 2 becomes three everywhere!), the storage for the value of the constant might in non-modifiable memory (the program may crash), the compiler may issue an error message, the program may get upset and sulk in its bedroom, the program might declare war on a neighbouring nation - it is a programming error - what happens is unspecified.
As of Fortran 90, facilities were introduced into the language to allow programmers to write new code that is practical for compilers to check for errors such as these (and in some cases compilers are required to check for errors if they are to be regarded as standard conforming).
For the code as presented, the main program and the subroutine are to be regarded as separately compiled - the main program is unaware of the details of the subroutine and vice versa (it is possible that the subroutine could be compiled long after the main program, on a different machine, with the outputs of the two being linked together at some later stage - without fancy link time behaviour or static analysis it is therefore not possible to resolve errors such as this). Language rules are such that when compiling the main program the compiler must implicitly assume the details of the interface of the subroutine based only on the way the subroutine is referenced - inside the main program the subroutine has an implicit interface.
Fortran 90 introduced the concept of an explicit interface, where the compiler is explicitly told what the interface of the subroutine in various ways, and can then check that any reference to the subroutine is consistent with that interface. If a procedure is a module procedure, internal procedure or intrinsic procedure - that interface is automatically realized, alternatively for external subprograms, procedure pointers, etc, the programmer can explicitly describe the interface using an interface block.
In addition, Fortran 90 introduced the intent attribute - a characteristic of a dummy argument of a procedure that is also then a characteristic of the interface for a procedure. The intent of the argument indicates to the compiler whether the procedure may define the argument (it also may implications for default initialization and component allocation status) and hence whether an expression could be a valid actual argument. x in subroutine foo would typically be declared INTENT(INOUT).
Collectively these new language features provide a robust defence against this sort of programming error when using compilers with a basic level of implementation quality. If you are starting with the language then it is recommended that these new features become part of your standard approach - i.e. use implicit none, all procedures should generally be module procedures or internal procedures, use external procedures only when absolutely required, always specify dummy argument intent, use free form source.
In my Fortran code I made the following call to the dnrm2 routine:
d = dnrm2(n, ax, 1)
Just a simple call that would return me a double precision result.
The question is, should I declare the function at the start of my script? I found that if I don't declare it, when I compile the code in 32 bit Windows, then the result is correct.
But if I compile the code in 64 bit Windows, then the result isn't be correct.
Why is this so? Must an external routine always be declared in Fortran?
If you don't correctly describe your subprograms (subroutines and functions) to a calling program, the compiler may not correctly call them. Fortran compiles each unit separately, so the compiler doesn't "know", by default, about the characteristics of other subprograms. There are several ways that you can describe/declare a subprogram in Fortran 90/95/2003.
The easiest and best method is to place your subprograms into a module and then "use" that module in the calling program. This automatically makes the interface known to the compiler and will enable the compiler to check the consistency of actual arguments (in the call) and dummy arguments in the subprogram. It will also make known the return type of a function. The various subprograms in a module have their interfaces known to each other.
You can also write an "interface" containing a subprogram declaration that matches the declarations of the actual subprogram. (This method can be very similar to the style of including header files in C.) This method is more work and prone to error because you have to manually maintain consistency between the actual subprogram and interface whenever changes are made. The interface method is useful when you don't have the code to the subprogram or the subprogram is written in a language other than Fortran.
Or you can simply declare a function name to specify the type-return of the function, but this won't give you any checking of the arguments. In my opinion this method is weaker since having the compiler check argument consistency eliminates a major class of programming mistakes.
I don't do Fortran, but in C, the size of a pointer and the size of a long int varies between 32 and 64 bit OS'es, but the size of an int does not. Perhaps the program is using ints to do pointer arithmetic?