mecej4
Joined: 31 Oct 2006
Posts: 1917
|
 Posted: Tue Dec 02, 2014 4:17 pm Post subject: |
 |
|
Beyond the incompatibilities between /save and recursive functions, I think that the example code posted by Garling (on Fri Nov 28, 2014 9:05 am, see above) brings out a bug in the FTN95 7.1 compiler when the /save option is used.
Here are details on how to see the bug. Compile the code with /debug /save. Start SDBG and set a breakpoint on Line-40, which contains
| Code: |
| iA1 = IAANRA(iA, iM, iT) |
Press Run twice. With the program now stopped on Line-40, note the values of IA and IM (2 and 1). Step to the next line. Note that IA changed to 3! This happened, despite IA being an INTENT(IN) argument.
At the assembler level, the problem occurs because the static (because of /save) local variable, IA1, and the first function argument, IA, have been aliased to the same address (the SS and DS register contents are equal). Thus, assigning to IA1 on Line-40 changes the value of IA used on Line-41.
This is the bug at its inception. From now on, since this incorrect value of IA is used as an array index, lots of things start going wrong, including accesses to uninitialized parts of the arrays.
I have compared this behavior with IFort and Gfortran (using /Qsave and -fno-automatic, respectively). They do no behave in this fashion. |
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
