removing /save fortran compiler option
in [Fortran]
|
From: Lynn McGuire on 5 Jul 2010 19:56 >> I think that our code needs zeroing upon EACH entry of our subroutines. >> I have been trying this out and have gotten several benchmark files to run >> to completion now by adding the zeroing of a few key variables (the indexes >> for the arrays variables have been killers). > ... > > If that's the case, it's been wrong w/ the /SAVE option because it does _NOT_ do that at all. I do not disagree with that statement. That is why I think that the explicit zeroing of our local variables will be better for the code as that initial value of zero in each subroutine call will be much more consistent with the resultant calculations. Thanks, Lynn
From: dpb on 5 Jul 2010 19:56 dpb wrote: > Lynn McGuire wrote: > ... > >> I think that our code needs zeroing upon EACH entry of our subroutines. >> I have been trying this out and have gotten several benchmark files to >> run >> to completion now by adding the zeroing of a few key variables (the >> indexes >> for the arrays variables have been killers). > ... > > If that's the case, it's been wrong w/ the /SAVE option because it does > _NOT_ do that at all. > > >> type wat.for > > program wat > x = 1.0 > > call foo(x) > call foo(x) > end > > Subroutine foo(x) > > x = x+1. > > print *, y > > y = y+1.0 > End > > > C:\Temp> wfl386 /save wat.for > Watcom F77/32 Compile and Link Utility Version 11.0 > Copyright by Sybase, Inc., and its subsidiaries, 1990, 1997. > All rights reserved. Watcom is a trademark of Sybase, Inc. > wfc386 wat.for /save > Watcom FORTRAN 77/32 Optimizing Compiler Version 11.0 2010/07/05 18:15:38 > Copyright by Sybase, Inc., and its subsidiaries, 1984, 1997. > All rights reserved. Watcom is a trademark of Sybase, Inc. > wat.for: 11 statements, 72 bytes, 1 extensions, 0 warnings, 0 errors > > WATCOM Linker Version 11.0 > Copyright by Sybase, Inc., and its subsidiaries, 1985, 1997. > All rights reserved. Watcom is a trademark of Sybase, Inc. > loading object files > searching libraries > creating a Windows NT character-mode executable > > C:\Temp> wat > 0.0000000 > 1.0000000 > > C:\Temp> And, C:\Temp> wfl386 /quiet wat.for C:\Temp> wat 0.0000000 0.0000000 C:\Temp> W/O /SAVE, y is zero on entry; with it retains its previous value. So, if as I understand it, you've had global /SAVE and think the results are correct, wherever there's an uninitialized variable it's not been being reset and so adding that in will definitely be a change. Now, whether that's important or not is indeterminate from here, but it surely will be a different code behavior if do so. As noted earlier by somebody, the DATA statement has the same initialization effect as /SAVE and implicitly will cause /SAVE C:\Temp> *type wat.for program watfor x = 1.0 call foo(x) call foo(x) end Subroutine foo(x) data y /0.0/ x = x+1. print *, y y = y+1.0 End C:\Temp> wfl386 /quiet wat.for C:\Temp> wat 0.0000000 1.0000000 C:\Temp> --
From: dpb on 5 Jul 2010 20:01 Lynn McGuire wrote: >>> I think that our code needs zeroing upon EACH entry of our subroutines. >>> I have been trying this out and have gotten several benchmark files to run >>> to completion now by adding the zeroing of a few key variables (the indexes >>> for the arrays variables have been killers). >> ... >> >> If that's the case, it's been wrong w/ the /SAVE option because >> it does _NOT_ do that at all. > > I do not disagree with that statement. That is why I think that the explicit > zeroing of our local variables will be better for the code as that initial value > of zero in each subroutine call will be much more consistent with the > resultant calculations. I'm truly confused now about what you think is the right answer...and how you know whether the answer is, in fact, correct. It makes no sense to me as the 2nd sentence of the first paragraph seems to completely negate the assertion that the code has been running w/ OW owing to /SAVE and its initialization (which is one-time only). --
From: Lynn McGuire on 5 Jul 2010 20:08 > C:\Temp> wfl386 /quiet wat.for > > C:\Temp> wat > 0.0000000 > 0.0000000 > W/O /SAVE, y is zero on entry; with it retains its previous value. That is not the behavior that I am seeing when the /save is dropped from OW 1.9. I see that the y variable has a totally random, but consistent, value upon usage. I see that you are using Watcom 11.0, not OW 1.9. C:\dii>wfl386 /quiet wat.for C:\dii>wat 6.0233654E+036 6.0233654E+036 > As noted earlier by somebody, the DATA statement has the same initialization effect as /SAVE and implicitly will cause /SAVE Since I do not want that behavior, explicit initialization of the local variables will be much better for me. Thanks, Lynn
From: Richard Maine on 5 Jul 2010 20:11
dpb <none(a)non.net> wrote: > Lynn McGuire wrote: > >>> I think that our code needs zeroing upon EACH entry of our subroutines. > I'm truly confused now about what you think is the right answer...and > how you know whether the answer is, in fact, correct. > > It makes no sense to me as the 2nd sentence of the first paragraph seems > to completely negate the assertion that the code has been running w/ OW > owing to /SAVE and its initialization (which is one-time only). I'm a little confused as well, but a possibility does occur to me. It could be that the code runs ok now with zero-init+save because each subroutine where this applies is called only once, but that it would need zeroing on each entry if the code ended up being called multiple times. Just a guess as to what might be meant. I have run into situations like that in the past, where a code was once a standalone program, but then gets converted to run in a loop or otherwise do multiple cases. It can be a pain if the original code assumed zero initialization. Been there. Done that. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |