What is the best intent () to use with variables that are local to a subroutine? These are neither passed into or out of the subroutine but may be modified during execution of the subroutine. What about local named constants (parameters)?
The INTENT attribute can only be applied to dummy arguments.
Source that attempts to apply the INTENT attribute to something that is not a dummy argument, such as a local variable or a named constant, will result in a syntax error from a Fortran compiler.
The attribute intent() is just for variables that are either coming into the subroutine or coming out of it not for local variables. if you use the intent() for local variables, the compiler produces error.
intent() is used for dummy variables.
Related
Umm I've came across a problem in Fortran where I need to use Equivalence for a variable which is already declared in a module written by someone else(Probably is dead by now, otherwise I would have contacted him/her).
The variable in the module is of REAL type. And I want to store a INTEGER value in it.
If I do so directly, wrong data gets stored in the REAL type.
I have tried to use equivalence in module, But no luck.
Any Help ?
Well, EQUIVALENCE is an old keyword which should be avoided in modern Fortran because it makes the code misleading, but it has not been eliminated from Fortran standard yet, AFAIK.
However, if you have just the need to store the bit-by-bit representation of a integer in a real variable, I'd rather suggest to use the intrinsic function TRANSFER which literally transfers the binary contents of a variable to a variable of another type without any conversion and without raising errors. So, assuming that your real module variable is x and your integer value is i you can simply do:
x = TRANSFER(i,x)
The second argument could be any real variable, not necessarily x itself, it just gives a hint to the compiler that the result is of real type and it should not be an error to assign it to a real variable.
__declspec(naked) void printfive() {
int i = 5;
printf("%i\n", i);
}
for some reason this code works, but I do not understand where the i is stored? In the frame of the calling function? It becomes global variable? If it is stored in the caller's frame, then how compiler knows the displacement, because you can call printfive() from different functions with different frame size and local variables. If it is global, or something like static maybe, I have tried to go recursive and I can see that variable is not changed, it is not truly local indeed. But that's obvious, there is no entry code (prolog). Ok, I understand, no prolog, no frame, no register change, but this is values, but what happens to the scope? Is the behaviour of this specifier defined in any reference? Is this part of C++ standard anyway? This sort of functions are great if you mostly use asm {} inside them, (or use asm to call them and want to be sure the function is not over optimized), but you can mix with C++. But this is sort of brain twister.
I know this topic is more than several years old, Here are my own answers.
Since no references are made to Microsoft documentation regarding this topic, for those who care to learn more about what is needed or not as stated by Keltar, here is the Microsoft documentation that explains most of what Keltar didn't explain here.
According to Microsoft documentation, and should be avoided.
The following rules and limitations apply to naked functions:
The return statement is not permitted.
Structured Exception Handling and C++ Exception Handling constructs are not permitted because they must unwind across the stack frame.
For the same reason, any form of setjmp is prohibited
Use of the _alloca function is prohibited.
To ensure that no initialization code for local variables appears before the prolog sequence, initialized local variables are not
permitted at function scope. In particular, the declaration of C++
objects are not permitted at function scope. There may, however, be
initialized data in a nested scope.
Frame pointer optimization (the /Oy compiler option) is not recommended, but it is automatically suppressed for a naked function.
You cannot declare C++ class objects at the function lexical scope. You can, however, declare objects in a nested block.
From gcc manual:
Use this attribute ... to indicate that the specified function does
not need prologue/epilogue sequences generated by the compiler. It is
up to the programmer to provide these sequences. The only statements
that can be safely included in naked functions are asm statements that
do not have operands. All other statements, including declarations of
local variables, if statements, and so forth, should be avoided. Naked
functions should be used to implement the body of an assembly
function, while allowing the compiler to construct the requisite
function declaration for the assembler.
And it isn't standard (as well as any __declspec or __attribute__)
When entering or exiting a function, the compiler adds code to help with the passing or parameters. When a function is declared naked, non of the parameter variables assignment code is generated, if you want to get at any of the parameters, you will need to directly access the relevant registers or stack (depending on the ABI defined calling convention).
In your case, you are not passing parameters to the function, therefore your code works even though the function is declared naked. Take a look at the dis-assembler if you want to see the difference.
I am extremely new to Fortran, so forgive any ignorance in this question.
Anyway I am working on optimizing some simulation software.
To be more clear the subroutine I am editing initializes some static variables at the start and they should be the same no matter what the starting conditions are.
The problem is I have another piece of coding calling this subroutine across each of its time steps reinitializing hundreds of variables, that should have just stayed the same. To fix this I have created a derived type that includes all these variables from other modules in the program, and I am editing the software to initialize the derived type variables instead of the module variables so that I can just refer across different time steps.
My question is, am i doing uneeded work. If I instead just took all the initialization stuff and put it in a subroutine outside of my main program, and then linked these at compilation, would all the variables retain their values across function calls.
If you have a variable that should be initialized once and never changed, give it the parameter attribute:
real, parameter :: pi = 3.141592
The compiler will treat the "variable" as a constant that can't be changed. If you mistakenly try to change such a variable, the compiler will inform you of your mistake.
Does this answer your question?
I can't tell what you are doing, but FORTRAN is a 3GL and it passes parameters by reference. If you want variables from the main to be in subroutines, you need to put it in a common block. COMMON blocks are like global variables in C.
I have an issue in Fortran 90.
I have a user-defined type, and when I call one of the MPI subroutines the data looks to be passed by value (not address, as I thought it should). The output arguments aren't modified. It seems to be specific to the MPI calls. I tried the same thing in a simple test, and I can change the passed in values in the calling scope. I'm not sure why this is, because I thought Fortran always passes by address. Any idea what could be going on?
Just to be clear, the commented snippet shows how the calls are made. In the first call, c%NSubDomains is an output argument and should be modified in the calling scope, but is not. When I call with an array rather than a member of a user-defined type it works, in the uncommented snippet.
! ! This doesn't work output values aren't modified ??
! call MPI_Dims_create(c%NProcs,c%NDims,c%NSubDomains,iErr)
nsubs(:)=0
call MPI_Dims_create(c%NProcs,c%NDims,nsubs,iErr)
c%NSubDomains=nsubs
The Fortran language standard doesn't say how arguments are passed. Different compilers can implement argument passing in various ways, depending on the type of the argument and the "intent" of the argument (in/out/inout).
How are nsubs versus C%NSubDomains declared? Do you have an interface declaration (probably from a Fortran 90 binding to MPI) to tell the compiler how it is supposed to call MPI_Dims_create?
As #MSB observes the Fortran standards don't mandate how argument passing is to be implemented. I think it's clear, though, that they do mandate that the semantics of argument passing make it look to the programmer as if arguments are passed by reference. So I understand OP's upset that this appears not to be the case for the INTENT(OUT) argument of MPI_DIMS_CREATE.
If your compiler supports the syntax of declarations like this:
!DEC$ ATTRIBUTE
or if you are using a compiler with the C-interoperability features of Fortran 2003 implemented, you might be able to coerce the compiler into passing the component as if by reference. However, if you do, it is highly likely that behind the scenes the compiler is generating code to do what you yourself are doing in your uncommented code -- making a variable which can be passed as if by reference and passing that to the subroutine.
In this situation I'd go with the flow and write the code myself.
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?