Prev: managing identities
Next: Call Tree Generator
From: Richard Maine on 2 Feb 2010 16:51 Lynn McGuire <lmc(a)winsim.com> wrote: > We use structures and unions. I think that Salford FTN77 > does not support these vax vms extensions that never got > moved into the fortran standard. We started using structures > about 6 years ago to solve a precision problem that we were > having and the usage is now prevalent through our code. Ouch, and hmm. Started using them a decade and a half after f90 standardized something different. Yes, I'm sure like it seemed like a good idea at the time, at least when looked at in the short term (as such things so often are). I think I even recall some discussion on this forum of your quandry with that. Much though I sympathize with the problems involved (and I'm sure it isn't entirely up to you anyway), I can't help but see an image of being stuck in a hole and digging it deeper. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Colin Watters on 2 Feb 2010 17:08 "Lynn McGuire" <lmc(a)winsim.com> wrote in message news:FJOdnalFStQu7fXWnZ2dnUVZ_hidnZ2d(a)supernews.com... .... > >> Intel Fortran has a "generated interface checking" option. You compile >> your sources with -warn interface (/warn:interface on Windows) and it >> automatically generates interface blocks and modules for subroutines and >> functions and checks calls against them, warning you of mismatches. For >> best success, I suggest two builds, leaving the generated .mod files in >> place after the first build, because a call to a routine that has not >> yet been compiled can't be checked. > > I have not tried this. I may do this but the setup is very > painful with 5,000 files, 4 EXE files and 3 DLLs. It is very good. The code does not need to run, it does not even need to link, it just needs to compile. Then compile it again, and watch the lint fly. Of course it isn't perfect; its just REALLY USEFUL, about 99.9% of the time. P.S. What happened to the "Open Watcom" project? -- Qolin Email: my qname at domain dot com Domain: qomputing
From: Lynn McGuire on 2 Feb 2010 17:25 > Is it possible that what you think are zero-initialization problems > are really symptoms of some other kind of bug? Your project is already Nope. We dont have the runtime problems unless I turn off the zero-init and universal save options. > old, and it won't be finished any time soon. Perhsps it would be worth > the effort to re-engineer it with a F95+ compiler that offers better > diagnostics and interface checking. I'm sure that Richard would say > that it's far cheaper in the long run to do it right the first time. The first time this software was released was in 1969 on the old UCC system (Univac 1108) ... This is released commercial software in use by 1000s of customers. Lynn
From: Lynn McGuire on 2 Feb 2010 17:29 > It is very good. The code does not need to run, it does not even need to > link, it just needs to compile. Then compile it again, and watch the lint > fly. Of course it isn't perfect; its just REALLY USEFUL, about 99.9% of the > time. True. And I do have a version of our code that will compile and link with IVF 10.0. > P.S. What happened to the "Open Watcom" project? Still hanging in there http://www.openwatcom.org/ but mostly the C and C++ compilers are being worked on. Lynn
From: Lynn McGuire on 2 Feb 2010 17:39
On 2/2/2010 2:34 PM, Harald Anlauf wrote: > On Feb 2, 7:10 pm, Lynn McGuire<l...(a)winsim.com> wrote: >> Is there some way that I can verify our argument call >> counts and argument types ? We are locked into a F77 >> compiler because of some zero initialization problems >> that we have not been able to find. We have 650,000 >> lines of f77 code in about 5,000 files with probably >> 6,000 subroutines and functions. > > Have you tried ftnchek? If your code is standard F77, it > should help you to diagnose problems with dummy arguments, > inconsistent common blocks and similar problems. I have before. It seemed to want ALL on our code, all 650K lines, in a single file. And then it crashed when I did that ... Lynn |