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".
Related
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
When dealing with optional arguments in fortran I believe it's typical to branch using the present() intrinsic, i.e.:
subroutine foo(ii,jj)
implicit none
integer, intent(in) :: ii
integer, optional :: jj
if (present(jj)) then
! do something
else
! do something else
end if
end subroutine foo
My assumption (coming from a C++ world) is that present() is hopefully a compile-time construct, and that there won't be any associated runtime performance penalty. I expect that the compiler should be able to (should be required to?) optimise the if statement shown above away, depending on whether foo(ii) or foo(ii,jj) is called.
How is the present() intrinsic handled by compilers in practice? Does the fortran spec guarantee certain behaviour?
PRESENT is a runtime concept - to the extent that the presence of an argument may depend on aspects of the program that cannot be determined until runtime (based on input read from a file or similar).
The implementation of the equivalent of PRESENT in a C++ program would similarly be a runtime concept. Note that C++'s defaulted arguments feature is not quite the same concept as Fortran's optional arguments feature (though it could be part of an equivalent implementation).
Beyond compiler optimization cleverness, if you want compile time resolution of things similar to C++'s defaulted arguments or function overloading, then consider using multiple specific procedures behind a generic name, one variant of the specific with the "optional" argument, the other without.
That depends (what else did you expect? :-)
If you use gfortran with a recent version, and do a lot of work in at least one of the branches, and use LTO or put everything into one file, the compiler will clone the function for you (via constant propagation). Otherwise, probably not. If you want to find out if the procedure foo has been cloned, grep for foo.*constprop in the assembly file.
An alternative to one subroutine with an optional argument is two subroutines, one with the argument, and one without, sharing the same interface. I don't think there is a run-time cost for doing this as opposed to giving the two versions of the subroutine different names. Schematically, it looks like this:
interface foo
module procedure foo_1,foo_2
end interface foo
contains
subroutine foo_1(ii)
! some code
subroutine foo_2(ii,jj)
! some code
I am using gfortran (from gcc-4.8.1) to compile a .f90 source file, and encountered an error that says:
Error: Function 'inint' at (1) has no IMPLICIT type
I did a bit of search and found that a GNU website says [ININT]
This intrinsic is not yet implemented. The name is, however, reserved
as an intrinsic.
In a SGI documentation, it is said
ININT returns the nearest INTEGER*2 to its REAL*4 argument.
My questions are:
Is ININT a Fortran77/90/95/2003 standard function?
In gfortran, what's the proper/standard-compliant way of writing a replacement function for INIT?
I have never used ININT before, and it probably is not of any standard. Instead, I would recommend to use NINT (FORTRAN 77), which takes an optional KIND argument (Fortran 90):
RESULT = NINT(A [, KIND])
(Taken from the GCC docs)
Choose KIND to reflect INTEGER*2, whatever that is for your specific compiler... But while you're at it, try SELECTED_INT_KIND.
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
Suppose I have a subroutine which accepts two arrays as input. One is given intent(in) and the other is given intent(out). The latter is derived from the former in an arbitrary manner. However, what if I pass through the same actual argument for both dummy arguments? In general, the result will not be what was intended by the subroutine. See code snippet below.
The problem is, the compiler doesn't seem to care, even though I've given intent flags. I'm using Intel Visual Fortran Composer 12, with all diagnostics. Is there a better way of coding the subroutine, or some compiler option I'm missing, to make the code safer?
module foo
contains
subroutine sub_a()
implicit none
real::array(10,10)
call sub_b(array,array)
end subroutine
subroutine sub_b(array1,array2)
implicit none
real,intent(in)::array1(10,10)
real,intent(out)::array2(10,10)
!array2 is derived from array1 somehow
end subroutine
end module foo
This is called aliasing -- referring to the same item by two different names. In most cases this is not allowed in Fortran. Your example is not legal Fortran -- see http://software.intel.com/en-us/blogs/2009/07/10/doctor-fortran-in-ive-come-here-for-an-argument-side-2/, which has this specific case, of aliasing via the same actual argument used for two dummy arguments. Fortran compilers are not required to diagnose all violations of the rules of the language and this appears to be an example that the compiler is not recognizing.
Edit: aliasing is permitted. What is forbidden is changing the value of the dummy argument through the alias, here the other dummy argument. The rules are less restrictive for pointer and target arguments. The specific rules are described in "The Fortran 2003 Handbook" by Adams et al.
Putting parentheses around the argument that is intent(in) makes the code legal since you are effectively passing a copy:
call sub_b((array),array)