|f77 on SUN vs. on HPRISC'S email@example.com (1994-12-03)|
|Re: f77 on SUN vs. on HPRISC'S firstname.lastname@example.org (1994-12-05)|
|Re: f77 on Sun vs. on HPRISC's email@example.com (1994-12-07)|
|Re: f77 on SUN vs. on HPRISC'S firstname.lastname@example.org (1994-12-14)|
|Re: f77 on Sun vs. on HPRISC's email@example.com (1994-12-16)|
|Re: f77 on Sun vs. on HPRISC's firstname.lastname@example.org (1994-12-21)|
|From:||email@example.com (Shankar Unni)|
|Organization:||Silicon Graphics, Inc.|
|Date:||Wed, 21 Dec 1994 19:28:52 GMT|
firstname.lastname@example.org (harris) writes:
> In my case the problem was the HP compiler does not remember the values of
> local subroutine variables from one pass to the next.
Jan Vorbrueggen (email@example.com) wrote:
> Why should it - the standard doesn't require it. (See John's comment.)
And even more importantly, every Fortran77 compiler out there usually has
an option to force subroutine variables to be static. For HP, I *think* the
option is "-K". Check the f77 man page on HP-UX to be sure..
Also, be aware that -K will usually *KILL* your optimization, so the better
alternative is to identify which variables you want to be static, and stick
them in some common block private to the subroutine.
Shankar Unni E-Mail: firstname.lastname@example.org
Silicon Graphics Inc. Phone: +1-415-390-2072
[I still prefer SAVE to a private common block, since that's specifically
what it's for. If your compiler has a broken save, you can get essentially
the same effect by initializing your variables in a DATA statement. Indeed,
if you plan to reuse values from one call to the next, I'd be pretty dubious
if you don't initialize them with DATA. -John]
Return to the
Search the comp.compilers archives again.