I would like to compile a Fortran 90 (fixed format) library under Windows. However, I cannot understand the error of prepocessor variables.
Say the sample file is VF_TestPreprocessor.F:
program VF_TestPreprocessor
implicit Integer(A-Z)
Parameter (TestAlpha=22,TestBeta=TestGamma)
print *, TestBeta
end program VF_TestPreprocessor
Under Linux, I can use ifort VF_TestPreprocessor.F -DTestGamma=25 to compile, and run.
However, under windows, I cannot use ifort VF_TestPreprocessor.F /DTestGamma=25 to compile. The error message is error #6592: This symbol must be a defined parameter, an enumerator, or an argument of an inquiry function that evaluates to a compile-time constant. [TestGamma]. Could you help to analyse the error?
It looks like ifort doesn't run the preprocessor. I have no experience with ifort, but this page (the first hit in Google on ifort preprocessor) says that on Windows the preprocessor is only run on files ending in an extension of .fpp.
So, I guess there are (at least) two solutions:
Rename your files to end in .fpp;
invoke ifort with the /fpp switch.
Related
I work with a very long Fortran code full of preprocessor (#if) conditionals, Is there any way to compile it and get a source file only with the fraction of the code where conditions are satisfied?
As mentioned by chw21, you can run the preprocessor directly. Either the cpp (with the right flags) or the fpp command, depending on your compiler.
Because you can be unsure about the right flags, you can also let the compiler do that for you. In GCC (gfortran) it is the -E flag, which will force the compiler to stop after preprocessing. You must redirect standard output to a file because the preprocessed code is returned to standard output.
I have some (Microblaze) assembly I need to build (via the GCC cross-assembler and linker) and execute many times with the (same) constants, currently fixed via
.SET
commands, changed each time.
Is there a way to automate the setting of in-assembly constants in this way and so avoid the dull task of resetting the code for each build?
You can use the power of C pre-processor in your assembler files. This could be done simply changing file extension from .s to .S (capital S) on Unix-like platform or to .sx on Windows. Then using gcc instead of gas over these files will let C pre-processor first run through the source and then gas will be called automatically.
In this case you can use all regular pre-processor #define, #ifdef, etc. And of cause you can pass these defines from the command line with gcc's -D parameter.
In this episode of "let's be stupid", we have the following problem: a C++ library has been wrapped with a layer of code that exports its functionality in a way that allows it to be called from C. This results in a separate library that must be linked (along with the original C++ library and some object files specific to the program) into a C program to produce the desired result.
The tricky part is that this is being done in the context of a rigid build system that was built in-house and consists of literally dozens of include makefiles. This system has a separate step for the linking of libraries and object files into the final executable but it insists on using gcc for this step instead of g++ because the program source files all have a .c extension, so the result is a profusion of undefined symbols. If the command line is manually pasted at a prompt and g++ is substituted for gcc, then everything works fine.
There is a well-known (to this build system) make variable that allows flags to be passed to the linking step, and it would be nice if there were some incantation that could be added to this variable that would force gcc to act like g++ (since both are just driver programs).
I have spent quality time with the gcc documentation searching for something that would do this but haven't found anything that looks right, does anybody have suggestions?
Considering such a terrible build system write a wrapper around gcc that exec's gcc or g++ dependent upon the arguments. Replace /usr/bin/gcc with this script, or modify your PATH to use this script in preference to the real binary.
#!/bin/sh
if [ "$1" == "wibble wobble" ]
then
exec /usr/bin/gcc-4.5 $*
else
exec /usr/bin/g++-4.5 $*
fi
The problem is that C linkage produces object files with C name mangling, and that C++ linkage produces object files with C++ name mangling.
Your best bet is to use
extern "C"
before declarations in your C++ builds, and no prefix on your C builds.
You can detect C++ using
#if __cplusplus
Many thanks to bmargulies for his comment on the original question. By comparing the output of running the link line with both gcc and g++ using the -v option and doing a bit of experimenting, I was able to determine that "-lstdc++" was the magic ingredient to add to my linking flags (in the appropriate order relative to other libraries) in order to avoid the problem of undefined symbols.
For those of you who wish to play "let's be stupid" at home, I should note that I have avoided any use of static initialization in the C++ code (as is generally wise), so I wasn't forced to compile the translation unit containing the main() function with g++ as indicated in item 32.1 of FAQ-Lite (http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html).
Is it possible in Fortran to query the name of the function or subroutine that I am in? I.e., what do I put in place of '???' to get it to print 'my_subroutine' on the screen?
subroutine my_subroutine()
write(*,*) ???
end subroutine my_subroutine
I am trying to find a way to implement a custom debugger/profiler using nothing but a text editor's search and replace mechanism. Programmatically querying my position in the code would be helpful.
No, you can't. What you want to achieve is called reflection and it is not available in Fortran (nor in C or C++ for what matters).
You can use the preprocessor to print out the file name and line number. You might want take advantage of the predefined preprocessor symbols __LINE__ and __FILE__. Here's an example:
A preprocessor macro is defined in header file (so that it can be used in multiple locations), call it errormsg.h:
#define ERRORMSG(msg) write(0,'("There was an error at ",I4," in file ",/,A,/,"Error message: ",A)') __LINE__,__FILE__,msg
Then you can include this header file in your program, library or module files, for example:
#include "errormsg.h"
program main
ERRORMSG("not really an error...")
call foo()
end program
subroutine foo()
ERRORMSG("not an error too!")
end subroutine
The ERRORMSG("not really an error...") seems like weird syntax for fortran code, but it get's replaced by the c-preprocessor using the macro definition. So when this is compiled, it looks like:
write(0,'("There was an error at ",I4," in file ",/,A,/,"Error message: ",A)') __LINE__,__FILE__,"not really an error"
For my ERRORMSG macro, I chose to use the 0 file unit to print to stderr. You obviously have the freedom to write the message how ever you like, as long as it results in syntactical correct FORTRAN code.
Getting this to compile requires you to pass flags to the compiler, and they differ slightly from compiler to compiler. This worked for me, for example:
gfortran -cpp -o errorTest errorTest.f90
That is, for gfortran, -cpp invokes the c-preprocessor before compiling. The output from the above program looks like this:
There was an error at 5 in file
errorTest.f90
Error message: not really an error...
There was an error at 13 in file
errorTest.f90
Error message: not an error too!
This might have the effect you are looking for, especially if you write only one subroutine per file.
I found an easy semi-automated way out of this situation: use regex to add a hardcoded definition of __FUNCTION__ right after the SUBROUTINE declaration. Done from within the makefile will take care that every compilation refreshes the __FUNCTION__ macro.
Suppose we have a F77 listing that looks like this
file 'my-file.F'
SUBROUTINE my_sub(var1, var2, var3)
INCLUDE 'some-include.PRM'
INTEGER var1
INTEGER var2
! the rest of my code here
WRITE(*,*)__FUNCTION__
END SUBROUTINE
I want to convert it to
file 'my_file.F.F'
SUBROUTINE my_sub(var1, var2, var3)
#undef __FUNCTION__
#define __FUNCTION__ "my_sub"
INCLUDE 'some-include.PRM'
INTEGER var1
INTEGER var2
! the rest of my code here
WRITE(*,*)__FUNCTION__
END SUBROUTINE
Note the amended code is now located in another source file: my-file.F.F
To do this I added the following lines to 'Makefile'
my-file.o: my-file.F
perl -pne 's/^(\s+SUBROUTINE\s*)([^(]+)(\(.*\))/$$1$$2$$3\n#undef __FUNCTION__\n#define __FUNCTION__ _S($$2)/ixms' $< > $<.F; \
$(FC) $(CPPFLAGS) $(FCFLAGS) -c $<.F -o $#
Assuming FC is defined as the fortran compiler executable, this should perform the following procedure on all the subroutines in the file:
undefine a __FUNCTION__ macro that was possibly defined earlier.
Add a __FUNCTION__ directive two lines below the SUBROUTINE definition, containing the subroutine's name.
save the file under another name.
compile the new source into the required object file.
The result should be my-file.o in this case.
You may have noticed that I'm using the macro _S() as well. This is a 'stringify' macro. You just need to add it to the top of your fortran file (I place it inside a config.h that I include everywhere)
There is a different implementation for GNU and intel:
#ifdef __INTEL_COMPILER
#define _S(x) #x
#else
#define _S(x) "x"
#endif
There are sometimes non-standard features in compilers to help you to print where you currently are. These are highly compiler specific and should be used only for debugging.
In gfortran you can use subroutine BACKTRACE. From the manual:
BACKTRACE shows a backtrace at an arbitrary place in user code.
Program execution continues normally afterwards.
The output will look like an error message, but it may be helpful.
Why don't you just hard write the name of the subroutine you're in, in the WRITE statement?
You cannot programmatically (dynamically) give or change the name of the subroutine, therefore I see no reason to try to access it either that way (about that: while I'm not sure that it is impossible to access it somehow, I'm quite sure that it is the wrong way to go ... you will cause yourself more trouble going that way, than just hard coding it).
Btw, why are you trying to print it out anyway? Wouldn't a well phrased diagnostic message be more informative?
To completely disable a debug output in c-source,
I usually define the following SIMPLE macro #1
#define dprintf(args)
To enable a debug output, I define macro #2 alternatively
#define dprintf(args) printk##args
The usage in source looks like:
dprintf(("Irqs:%lu\n",irqs));
A preprocessor should create following line if I use macro #2
printk("Irqs:%lu\n",irqs);
Under Windows Visual c++, there is no problem.
Using gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) under NETBEANS IDE 6.8,
I got the following error message:
"printk" and "(" does not give a valid preprocessing token
I tried the following under Linux
#define dprintk(args...) printk(args)
This works only with
dprintf("Irqs:%lu\n",irqs);
Visual C++ however does not know args...
I have to compile source code on windows
and Linux(386) platform alternatively.
Does anyone have an idea ?
Why not #define dprintf(args) print args ?
The double parenthesis could have been added to replace the variadic macro in visual C++ : the preprocessor will handle macro invocation as if there was only one parameter.
The token pasting operator ## can only be used to concatenate tokens, as its name implies. Some compilers, e.g. newer versions of gcc, enforce this more rigidly than others, as you have now discovered. As philippe says, though, you don't actually need ## in this particular example.