Preprocessors and use association - module

In summary, is it possible to access via use association a preprocessor directive defined in a Fortran module?
Context
I use preprocessor statements to define subroutines to print warning and error messages. For example, I use the following module/subroutine, in the file errors.f, to print warning messages
module errors
use, intrinsic :: iso_fortran_env, only : error_unit=>stderr
implicit none
contains
!> Print formatted warning message.
subroutine warn_print( file, line, mesg )
implicit none
character(len=*), intent(in) :: file
integer, intent(in) :: line
character(len=*), intent(in) :: mesg
write(stderr,'(a,a,a,i4,a,a)') "WARNING::", file, ":", line, ": ", mesg
end subroutine warn_print
end module errors
and, in a separate file errors.h, I use the above module and define a preprocessor macro
use errors
#define warn( text )warn_print(__FILE__,__LINE__,text)
I then #include the file errors.h in whichever file/module I wish to use the warning print routine which allows me to simply write
call warn("Some warning message")
and the compiler will automatically include the file and line number at which the warning message was called.
Question
The use of #include 'errors.h' is rather idiosyncratic in Fortran code and it hides the use of the errors module. Ideally I would prefer to define the above preprocessor in the errors module itself. However, then when using that module, this preprocessor directive is not available to the program/module which uses this module.
Is there a way to make a preprocessor directive accessible via use association?
The only other way I can think of doing it is to just have the errors module and define the preprocessor directive in my call to the compiler (using, for example, the -D flag with ifort). Any suggestions for any alternative way of achieving the above would be greatly appreciated.

No, it is simply not possible, since the preprocessing and the compilation stages are completely separate one from each other and the C preprocessor does not know anything about the Fortran USE statement.
I use to #include 'config.h' (from autoconf) in most of my .F90 sources, without problems.

This may not be what you are looking for, but if you are using ifort, you can use traceback functionality to achieve something similar (a bit more powerful, but also more ugly), e.g.
program tracetest
call sub(5)
write(*,*) '=== DONE ==='
end program tracetest
subroutine sub(n)
use ifcore
integer :: n
character(len=60) :: str
write(str,*) '=== TROUBLE DETECTED: n =',n ! code -1 means "do not abort"
call tracebackqq(str,-1)
end subroutine sub
Then, compile with -traceback to see the source file, line, and stack trace. The stack trace and line may be obscured because of inlining; to avoid that, you can specify -traceback -O0 to get smth like this:
=== TROUBLE DETECTED: n = 5
Image PC Routine Line Source
a.out 0000000000473D0D Unknown Unknown Unknown
a.out 0000000000472815 Unknown Unknown Unknown
a.out 0000000000423260 Unknown Unknown Unknown
a.out 0000000000404BD6 Unknown Unknown Unknown
a.out 0000000000402C14 sub_ 12 tracetest.f90
a.out 0000000000402B18 MAIN__ 2 tracetest.f90
a.out 0000000000402ADC Unknown Unknown Unknown
libc.so.6 000000323201EC5D Unknown Unknown Unknown
a.out 00000000004029D9 Unknown Unknown Unknown
=== DONE ===
Alternatively, if want to keep the optimizations, and also want to see the correct line (12), you can compile with (for example) -fast -traceback -debug all,inline_debug_info. Something similar may be available in other compilers, but I am not sure.

Related

I use Simply Fortran, but cannot include modules there [duplicate]

This question already has an answer here:
The mysterious nature of Fortran 90 modules
(1 answer)
Closed 2 years ago.
I have written the following Fortran Code in the System called "Simply Fortran":
program math2
use prec, only: print_kind_info
implicit none
call print_kind_info
end program math2
module prec
implicit none
integer, parameter :: dp = selected_real_kind(P=10,R=30)
integer, parameter :: sp = selected_real_kind(P=5,R=15)
integer, parameter :: dp_alt = kind(0.d0)
public :: dp, sp, print_kind_info
private
contains
! Subroutine comes here
subroutine print_kind_info()
real(sp) :: sing_prec
real(dp) :: double_prec
print*,'Single precision is kind ',sp
print*,'Double precision is kind ',dp
print*,'Kind of double precision number is ',dp_alt
end subroutine print_kind_info
end module prec
However, the module which I call 'prec' is not found. More precisely, the error message is the following:
use prec, only: print_kind_info
1
Fatal Error: Can't open module file 'prec.mod' for reading at (1): No such file or directory
compilation terminated.
Error(E42): Last command making (build\prec.o) returned a bad status
Error(E02): Make execution terminated
* Failed *
What I have to do that the module (see above code) is recognized properly? It is recognized in File Outline, but it is not inside the "module" folder. And I really don't have a plan here what to do. Moreover I have no experience with the Makefile environment (this BASHrc-like things I am not familar with).
Simply said: The problem is that the compiler doesn't know the module prec.mod at is defined after the main program but is used already in the main program.
So first define the module and after that the main program.
Better would be to place the module in a separate files and the main program in another file and compile these (in the right order) and link everything together.

Fortran .mod file doesn't update when compiling [duplicate]

I am working with GFortran and CodeBlocks but I'm having an issue about Modules and Multiple files.
i keep getting this error:
Fatal Error: Can't open module file 'mesh.mod' for reading at (1): No such file or directory
For some reason, GFortran is not building the 'mesh.mod' file.
This problem does not occur when I put all the code in a single .f90 file.
Bellow is an example of code that this error happens.
main.f90
MODULE MESH
IMPLICIT NONE
INTEGER :: IMAX,JMAX,NMAX
REAL(8), ALLOCATABLE :: XD(:),YD(:),FX(:,:),FY(:,:)
REAL(8) :: PI,E,DX,DY,H,L,RHO,MU
PARAMETER (PI = ACOS(-1.D0))
PARAMETER (E = 2.718)
END MODULE MESH
!**************************************************************
program Cavity
Use Mesh
implicit none
Real(8), Allocatable :: func(:)
Real(8) :: Der,DfDx
integer :: i
IMAX=10
DX=1./10
Allocate(xd(IMAX),func(IMAX))
Do i=1,IMAX
xd(i)=i*DX
End Do
Do i=1,IMAX
func(i) = xd(i)**2
End Do
Der=Dfdx(func,2)
Write(*,*) Der
End program Cavity
Derivatives.f90
Real(8) Function DfDx(f,i)
Use Mesh
implicit none
Real(8) :: f(1:Imax)
integer :: i
DfDx=(f(i+1)-f(i-1))/(2d0*dx)
return
end function DfDx
When I use console command line compilation instead of CodeBlocks interface I already solved this problem (Compiling Multiple Files with modules) but I'm still getting this problem with CodeBlocks.
Does anyone know how to solve this issue?
Assuming what you have written is how your code is, then it appears that the problem is that the module mesh is inside the main program and not a separate file. You should have three files: Mesh.f90, Derivatives.f90 and Main.f90.
Mesh.f90 is exactly as you have it,
module Mesh
implicit none
integer :: IMAX,JMAX,NMAX
real(8), allocatable :: XD(:),YD(:),FX(:,:),FY(:,:)
real(8) :: PI,E,DX,DY,H,L,RHO,MU
parameter (PI = ACOS(-1.D0))
parameter (E = 2.718)
end module Mesh
Derivatives.f90 should be written as another module, using contains:
module Derivatives
use mesh
contains
real(8) function dfdx(f,i)
real(8) :: f(i:imax)
integer :: i
DfDx=(f(i+1)-f(i-1))/(2d0*dx)
end function dfdx
end module Derivatives
and the Main.f90 will then use both modules. Note that I had to eliminate the variable DfDx; this is because it conflicts with the function DfDx in module Derivatives
program Cavity
Use Mesh
use Derivatives
implicit none
Real(8), Allocatable :: func(:)
Real(8) :: Der
integer :: i
IMAX=10
DX=1./10
Allocate(xd(IMAX),func(IMAX))
Do i=1,IMAX
xd(i)=i*DX
End Do
Do i=1,IMAX
func(i) = xd(i)**2
End Do
Der=Dfdx(func,2)
Write(*,*) Der
End program Cavity
I do not know how CodeBlocks works, but I would presume it lets you choose the compilation order. If that is the case, you should compile Mesh.f90 first, then Derivatives.f90, then compile Main.f90 before linking them to an executable.
When I compiled & linked them, I got an answer of 0.200000002980232; hopefully that links up to what you have as well.
On codeblock, you may go to Project properties > Build targets
Then select the file you want to build first (say mod.f90).
In the "Selected file properties" go to "Build"
Here,change the priority weight. Lower weight implies the file will be built first.
The problem is that in CodeBlocks "projects are built in the order of appearence, from top to bottom" (CodeBlocks Wiki), in other words, the files are compiled alphabetically.
Which means that in my case, Derivatives.f90 was being compiled before than Main.f90 causing the error.
A way to circumvent the problem is to set only the Main.f90 file as build target in CodeBlocks:
Menu Project/Properties...
In Build Target Files at the tab Build targets check only Main.f90
And use the command Include 'File_Name.f90' inside the Main.f90 code to include the other f90 files for compilation in the right order.

Integer variable no longer usable after forall construct

I have an integer variable that is declared at the head of my subroutine. After I've used it as a control variable inside a forall construct, I can no longer use it as the control variable of a do loop. The compiler (Intel, v. 12.0.3) complains
xyz.f90(1210): error #6404: This name does not have a type, and must have an explicit type. [I]
do i=1,sp_basis%num_dim
---------------^
xyz.f90(1210): error #6063: An INTEGER or REAL data type is required in this context. [I]
do i=1,sp_basis%num_dim
I have tried to write a small example to replicate this behaviour (and compiled the file with the same compiler options as the actual problematic one, apart from -c), but this compiled & worked nicely, so below is my (slightly shortened) problematic code (implicit none applies to the entire module this code belongs to):
subroutine xyz(stuff)
use data, only: ppm, npeaks
! some declarations
integer :: i ! ...
associate(sp_basis => public_spectra%basis(counter))
spots = npeaks * np
allocate(ref_curves(spots,npeaks,sp_basis%num_dim), stat=stat)
if (stat.ne.0) then
! ...
end if
forall (i=1:max_dim) uppers(i) = ubound(sp_int%int,i)
forall (i=1:max_dim) lowers(i) = lbound(sp_int%int,i)
forall (i=1:npeaks,j=1:sp_basis%num_dim) peak_pos_hertz(j,i) = ppm_to_hertz(ppm(permutation(j),i), sp_axes(j))
do peak_considered=1,npeaks
do pos=(peak_considered-1)*np+1,peak_considered*np
do i=1,sp_basis%num_dim ! <-- COMPLAINT
If I change i to a name that was not used as a forall construct's control variable everything works. Also, this is the second time I've run into this problem.
This is how the compilation is done (xyz.f90 is one of many files that make up the entire program):
ifort -c -g -C -check noarg_temp_created -traceback -warn -warn nodeclarations -nogen-interface xyz.f90
Does any of you know what the problem might be?
Thanks a lot for your time!
For all those interested, it's a bug in the Intel compiler. Here you can read more about it. Also it sounds like this bug will be fixed in a compiler version that is to be released some time in 2012.

gfortran, DLL, underscore

I want to access some subroutines from a third party DLL. The functions use STDCALL as the calling convention.
Running dumpbin /export foo.dll gives me something like:
...
7 6 00004B40 Foo#16
...
I compile my code using:
gfortran test.f90 -o test.exe -Wl,foo.dll
I get an error: undefined reference to '_foo_' (note the underscores).
I have tried adding the -mrtd compilation flag, as well as other flags I googled, all to no avail.
How can I tell fortran to not add the underscores?
edit: A bit of clarification is in order.
I have an existing DLL to which I do not have the source to.
This DLL is written in Visual Basic, if it helps.
I want to call this DLL from fortran.
When I write in test.f90: Foo(1.0d0) I get an undefined reference to '_foo_' linkage error
Did you try -fno-underscoring ?
I found a post by Tobias Burnus (a gfortran developer) at http://www.rhinocerus.net/forum/lang-fortran/604847-fortran-dll-call-excel-2.html (near the end) -- he recommends the use of compiler directives instead of -mrtd.
You need to combine the use of ISO_C_BINDING with compiler attributes. You should really read the Mixed-Language Programming section of the gfortran manual. It gives good advice that can be used with other compilers as well. In particular, in your case you need the stdcall attribute:
interface VisBasSubs
subroutine foo (DoubleArg) bind (C, name="Foo")
!GCC$ ATTRIBUTES stdcall :: foo
use iso_c_binding, only: c_double
real (kind=c_double), intent (inout) :: DoubleArg
end subroutine foo
end interface VisBasSubs
Notice the line with stdcall, it's what should make it work.
Just wanted to expand on M.S.B's -fno-underscoring answer: You may run into issues if using f2c & g77. From the gfortran documentation:
With -funderscoring in effect, GNU
Fortran appends one underscore to
external names with no underscores.
This is done to ensure compatibility
with code produced by many UNIX
Fortran compilers.
Caution: The default behavior of GNU
Fortran is incompatible with f2c and
g77, please use the -ff2c option if
you want object files compiled with
GNU Fortran to be compatible with
object code created with these tools.
Use of -fno-underscoring is not
recommended unless you are
experimenting with issues such as
integration of GNU Fortran into
existing system environments
(vis-à-vis existing libraries, tools,
and so on).
You might need to recompile the DLL with something like -fno-underscoring to remove the underscores from the DLL.
I've run into portability issues related to underscore prefix/suffix by certain Fortran compilers: Some compilers _prefix or suffix_ by default, while others don't! My solution has been preprocessor directives:
#ifdef LC_UNSC
#define GET_DIP_MOMENT get_dip_moment_
#elif LC_NOUNSC
#define GET_DIP_MOMENT get_dip_moment
#endif
...
call GET_DIP_MOMENT()
A different approach is to use the ISO C Binding of Fortran 2003, which is supported by gfortran >= 4.3. This will automatically use the underscoring conventions of C (i.e., probably none), rather those of the Fortran compiler. It will also give you control over the case (capitalization) of the subroutine names, if the Windows linker cares about that. Fortran is case insensitive, and so you can call Fortran subroutines by any case -- probably the linker is converting to lower case.
Including the following "interface" in the declarations of the Fortran routine that calls "Foo" describes Foo to be a C subroutine (void function) with a single argument of double type -- Fortran input/output, or a pointer in C. If Foo has other properties, the interface needs to be changed. The "bind" clause specifies the case-sensitive name to provide to the linker. If you call Foo from several Fortran routines, then it is best to put the interface into a module and "use" it from each Fortran routine.
This is intended for C -- maybe it will work for Visual Basic. The ISO C Binding gives a lot of control, so if this doesn't work, maybe some variation will.
interface VisBasSubs
subroutine foo (DoubleArg) bind (C, name="Foo")
use iso_c_binding, only: c_double
real (kind=c_double), intent (inout) :: DoubleArg
end subroutine foo
end interface VisBasSubs

use cmake add_definition value in fortran

I'd like to include a flag such as -DMY_FLAG=ONETWOTHREE in the CMake call, i.e. make .. -DMY_FLAG=ONETWOTHREE, and get the value of MY_FLAG in the fortran code. I'm using add_definitions("-DMY_FLAG=${MY_FLAG}") to pass MY_FLAG to make.
Currently, when I do something like
write(*,*) MY_FLAG
I get this compiler error:
Error: Symbol 'ONETWOTHREE' at (1) has no IMPLICIT type
Can the -D flags be cast to a type in fortran? It looks like MY_FLAG is somehow defined at compile time, but it has no type.
When using a preprocessor, the final source file must be valid Fortran. In the present situation,
write(*,*) ONETWOTHREE
is not valid because there is not variable named ONETWOTHREE.
Solutions:
Define the variable earlier:
integer ONETWOTHREE
ONETWOTHREE = 5
Do not use ONETWOTHREE but an actual value. Example for an integer:
-DMY_FLAG=123
so that the corresponding line will be
write(*,*) 123
Of course, it would be useful if you could provide us with the intention behind the usage of the preprocessor here.