removing /save fortran compiler option
in [Fortran]
|
From: Lynn McGuire on 5 Jul 2010 20:18 >> 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. Because in my engineering judgement, the answers make sense. Once one gets the answers, they are fairly easy to work out what is reasonable and what is not. In a flash separator, vapor goes out the top and liquid goes out the bottom. > 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). Me too. I do not understand why the code is working either. I could hazard several theories but at the end of the day, the code is working with the /save compiler option. Thanks, Lynn
From: dpb on 5 Jul 2010 20:27 Lynn McGuire wrote: .... > 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 .... Hmmm....which OS is that on? That's interesting behavior, indeed. I was unaware that there had actually been any changes in OW Fortran since the spin-off. I knew folks had done some work on the C compiler but was unaware of anything on the Fortran side that would change such behavior. If I weren't limited to slow dial-up I'd be tempted to download OW and check here but it would take days so isn't feasible. I'll certainly know to keep the V11 compiler CDs for our performance monitoring code if it were ever needed to go back to the Watcom build at some future point (say if OS/2 comes back again, say... :) altho there are still at least a dozen of the workstations still running 24/7 at a couple of the plants last I knew but all the rest are on NT4 (!!!) or newer (altho I'm sure XP is latest for these). Anyway, glad it's your problem and not mine even though it an interesting dilemma... Good luck... Oh...You don't have the defunct commercial Watcom compiler, too, perchance, do you by any stroke of luck? --
From: dpb on 5 Jul 2010 20:38 Lynn McGuire wrote: .... > Me too. I do not understand why the code is working either. I could hazard > several theories but at the end of the day, the code is working with the /save > compiler option. .... Oh, something just came to me...the statement that in particular you initialized the array indices. W/O that and /NOSAVE were you getting floating point errors on the integer conversion, perhaps? That I could see if it simply crashed owing to random memory given the other result that OW does different on clearing process memory as compared to Watcom which I've been used to (altho I had assumed it was OS spawning process security behavior rather than the compiler having not investigated where it actually was happening). --
From: Lynn McGuire on 6 Jul 2010 00:09 > Hmmm....which OS is that on? Windows XP Pro x86. > I was unaware that there had actually been any changes in OW Fortran since the spin-off. I knew folks had done some work on the C > compiler but was unaware of anything on the Fortran side that would change such behavior. The code generator has had a massive amount of work over the years. Since the C, C++ and F77 compilers feed directly to it, any change in the code generator for a C or C++ problem automatically affects the F77 compiler. I have had to have them fix a code generator change or two over the years for being too aggressive: http://openwatcom.org/index.php/C_Compilers_Release_Changes > If I weren't limited to slow dial-up I'd be tempted to download OW and check here but it would take days so isn't feasible. I'll > certainly know to keep the V11 compiler CDs for our performance monitoring code if it were ever needed to go back to the Watcom > build at some future point (say if OS/2 comes back again, say... :) altho there are still at least a dozen of the workstations > still running 24/7 at a couple of the plants last I knew but all the rest are on NT4 (!!!) or newer (altho I'm sure XP is latest > for these). The current OW still supports OS/2, DOS16 and DOS32 apps along with Win32 and linux apps (a work in progress). There is actually some one writing a F2003 code parser to go directly to the OW code generator. > Oh...You don't have the defunct commercial Watcom compiler, too, perchance, do you by any stroke of luck? I have Watcom versions 8.0 through 11.0 at the office. Somewhere. Lynn
From: Lynn McGuire on 6 Jul 2010 00:34
> Oh, something just came to me...the statement that in particular you initialized the array indices. W/O that and /NOSAVE were you > getting floating point errors on the integer conversion, perhaps? Nope. The integer variables that were used to build the array indices had random values in them. Generally huge random numbers that caused the program to crash immediately when that code was hit. One of them was: NOUT = IVDY(NWOUT).I IF (NOUT .GT. MAXOUT) MAXOUT = NOUT where the maxout initialization code was jumped over so it had a random value of something like 101,456,999 and nout was equal to 1, 2 or 3. I put a maxout=0 at the beginning of the subroutine and all was OK. > That I could see if it simply crashed owing to random memory given the other result that OW does different on clearing process > memory as compared to Watcom which I've been used to (altho I had assumed it was OS spawning process security behavior rather than > the compiler having not investigated where it actually was happening). The code generator symbol table organizer was rewritten several years ago in version 1.5 or 1.6. And the F77 symbol library was made case sensitive like C code is so I expect that may have changed then. Or not, it is tough to tell without testing each version. BTW, I am one of the code maintainers for OW also. I griped too much about a code parser/generator bug and they gave a login to fix it myself. I have made a few changes in the F77 run time library with extreme hand holding by the lead code maintainer. Since OW is over 2,000,000 lines of C code, any changes are nerve wracking at best. Thanks, Lynn |