Register to reply

Fortran Call Question

by stupify
Tags: fortran
Share this thread:
stupify
#1
Dec12-12, 09:23 PM
P: 4
ok,

Been programing for awhile, come from a visual basic background.

We have a new server with newer compilers. Compiling with -f77 switch.

Seems the old software allowed passing of integers, and strings in a call statement. New compilers seems to be inconsistent in passing the values.


Example:

call foo(0,'Hello','World')


subroutine foo(x,a,b)
integer x
character*(*) a
character*(*) b

if(x.eq.1) then
print *, a
else
print *, b
end if

return
end

Seems to not pass integer 0 to variable x.

Any thoughts. I have read that fortran passes by reference, not value; maybe someone can explain this to me.

Thnkx
Phys.Org News Partner Science news on Phys.org
'Smart material' chin strap harvests energy from chewing
King Richard III died painfully on battlefield
Capturing ancient Maya sites from both a rat's and a 'bat's eye view'
stupify
#2
Dec12-12, 10:33 PM
P: 4
No responses,

Let me ask the question, is the call statement legal?

call foo(0,'Hello','World')
Mark44
#3
Dec12-12, 11:54 PM
Mentor
P: 21,397
Quote Quote by stupify View Post
No responses,

Let me ask the question, is the call statement legal?

call foo(0,'Hello','World')
According to this reference (http://www.physics.nau.edu/~bowman/P...bprograms.html ), a tutorial on F77 out of Northern Arizona University, no.

Call-by-referenceFortran 77 uses the so-called call-by-reference paradigm. This means that instead of just passing the values of the function/subroutine arguments (call-by-value), the memory address of the arguments (pointers) are passed instead.
The literal value 0 has no address, so there's no address to pass in the subroutine call. I'm not sure how F77 stores string literals such as 'Hello', and 'World'. In C, which you didn't ask about, a string literal evaluates to the address of the first character in the string, but string literals are considered read-only.

jedishrfu
#4
Dec13-12, 12:20 AM
P: 3,096
Fortran Call Question

That doesn't seem right. In the past using Fortran-Y I've called subroutines with numeric literals. Looking at the assem listing you could see that the compiler had assigned the numeric literal to a mem location and the address for the numeric literal was passed. The bad thing was that there was nothing preventing the subroutine from changing the numeric literal because it now had its address (ie call by reference) .

What happened to me was I called a subroutine which did that and my numeric 3 argument got changed everywhere to a different number because whereever the compiler saw a 3 it pointed it to the same memory location. From there very bizarre program results happened.

Perhaps the newer compilers have handled this problem better but still pass things by reference.
stupify
#5
Dec13-12, 12:22 AM
P: 4
Thanks for responding.

Some of the code is passing to C, other subroutines are passing to Fortran. I have not witnessed the problem with code passed to C.

You are confirming what I believe, yet I have legacy Fortran code doing exactly as I have outlined. Further, I have legacy programmers telling me you can. Yet I read guides, exactly stating what you posted. The old servers seems to handle the case, new server no.

Some websites indicate passing by value was legal prior to F77; I believe the old server is using a very old compiler that may be backward compatible.

Perhaps there is a compiler switch I can use ????

Anyway, I am still open to comments.
jedishrfu
#6
Dec13-12, 12:31 AM
P: 3,096
another thing to look at is how the library code is built?

I recall theres a flag on gcc for byte packing but I cant remember the name. Basically for structures it placed each element on an even byte boundary (for faster memory fetching). We had to remember to do that same otherwise the alignment was off, arguments were skipped ...

http://en.wikipedia.org/wiki/Data_structure_alignment
uart
#7
Dec13-12, 06:47 PM
Sci Advisor
P: 2,751
In the Fortran implementations I've used, a call with a numeric literal would create a temporary variable and then pass its address. This temporary variable is created at run time as part of the call mechanism (rather than just assigning some address and initializing it once at load time).

So for example (with the g95 fortran compiler that I'm using) the following code correctly prints "Is zero" each iteration. This indicates that the memory reference is not just initialized once at load time. (Note that the subroutine changes n but this does not affect the literal value of the next call). This all seems pretty well behaved by my expectations. Personally I think that if your new compiler doesn't behave like this then it's buggy.

program test
implicit none
integer :: k
  do k = 1,3
    call testsub(0)
  end do

contains

subroutine testsub(n)
integer :: n
  if (n == 0) then
       print *,'Is zero'
  else
       print *,'Not zero'
  end if
  n = 1
end subroutine
end program test
uart
#8
Dec13-12, 07:09 PM
Sci Advisor
P: 2,751
BTW. I'm not a Fortran expert, so can anyone tell me the purpose of the extra '*' in declaration: character*(*) a.

I thought all that's needed there is: character(*) a, or if preferred then the more verbose: character (len = *) :: a
AlephZero
#9
Dec13-12, 08:14 PM
Engineering
Sci Advisor
HW Helper
Thanks
P: 7,284
Quote Quote by uart View Post
BTW. I'm not a Fortran expert, so can anyone tell me the purpose of the extra '*' in declaration: character*(*) a.
The "old style" syntax (still supported in F90 etc) was CHARACTER*length A
where "length" is either an integer constant, or the three characters (*).

This is probably because of the historical vagaries of Fortran syntax. There are no "reserved words" in Fortran, so CHARACTER(*) could potentially be a variable named CHARACTER (which would be type REAL, by default!) that is an 1-D array with an unknown number of elements. There's a practical limit to how far compilers have to "read ahead" to figure out what things actually mean. The apparently redundant characters remove the ambiguity.

FWIW, this is probably also the reason why "new style" Fortran syntax overdoses on colons.
jtbell
#10
Dec14-12, 08:19 AM
Mentor
jtbell's Avatar
P: 11,866
Quote Quote by stupify View Post
No responses,
Around here, you need to wait longer than an hour and ten minutes before complaining about a lack of responses.

In fact, we have a rule here (click the Rules link at the top of any page) that you need to want at least 24 hours before "bumping" a thread. If Mark hadn't already responded to the post (and quoted it), I would have deleted it.
stupify
#11
Dec17-12, 09:44 AM
P: 4
Thanks for your responses.

I bumped it, after I noticed 6 views, with no responses. Thought I would rephrase the question.

As uart explained, place value in temporary variable, and pass the address is what I have believed in the past. Code misbehaves occasionally, I am a bit mystified.
uart
#12
Dec17-12, 09:24 PM
Sci Advisor
P: 2,751
I agree with the OP in this case. I saw his second post as more of a clarification (or simplification) to the original question rather than straight out bumping his post.

Quote Quote by stupify View Post
Code misbehaves occasionally, I am a bit mystified.
Ok it's interesting that it's only occasionally misbehaving. Are saying that if you run some simple "test" code, similar to that which was posted above, that it mostly works but sometimes gives unexpected results. Or are you referring to a more complicated piece of code that sometimes gives unexpected results and you've tracked it down to (perhaps?) this situation?

Quote Quote by AlephZero View Post
The "old style" syntax (still supported in F90 etc) was CHARACTER*length A
Thanks AlephZero, that makes perfect sense now.


Register to reply

Related Discussions
What Is Actually Being Passed in a Fortran Sub Call? Programming & Computer Science 2
System call from fortran Programming & Computer Science 0
Cos(x) question! How would you call 'x'? General Math 5
Fortran 90 call random number Programming & Computer Science 2
Accessing Fortran Modules within a Fortran library from Fortran Programming & Computer Science 0