verifying argument counts and types
in [Fortran]
|
Prev: managing identities
Next: Call Tree Generator
From: robin on 2 Feb 2010 18:16 "Lynn McGuire" <lmc(a)winsim.com> wrote in message news:JPKdnd0U140H9_XWnZ2dnUVZ_tGdnZ2d(a)supernews.com... | Is there some way that I can verify our argument call | counts and argument types ? We are locked into a F77 | compiler 1. Even if you want to use an F77 compiler for profuction, you can use an F95 compiler for compilation, and that will check what you want. And ... 2. and therefore you are not "locked into" an 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. | | Thanks, | Lynn
From: Ron Shepard on 2 Feb 2010 18:26 In article <WPqdna9e687ECfXWnZ2dnUVZ_qednZ2d(a)supernews.com>, Lynn McGuire <lmc(a)winsim.com> wrote: > 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. Wow! You *started* using them only six years ago? I expected this to be from 70's or 80's legacy code. Maybe there is a tool that will automatically replace these nonstandard structures with standard user defined data types? That is what I recommend. Eliminate the bugs now while your code still works on at least one compiler. Otherwise it will become more and more difficult over time as your code works on fewer and fewer, and eventually zero, compilers. For initialization/save kinds of bugs, you can sometimes do binary searches where you compile different subsets of your code with various compiler options. But for this to work, you need at least one compiler where your code works and gives what you think is correct output. It is much more difficult (or impossible) to do this when you have only compilers on which your code fails. Once the bugs are isolated with the binary searches, you can examine the code and fix the problems (with explicit initializations, save statements, modules, etc.). $.02 -Ron Shepard
From: Lynn McGuire on 2 Feb 2010 18:27 > 1. Even if you want to use an F77 compiler for production, > you can use an F95 compiler for compilation, and > that will check what you want. And ... Yes. I just had a "duh" moment as a result of these answers. > 2. and therefore you are not "locked into" an F77 compiler. Just for benchmarking, debugging and production <g>. Lynn
From: robin on 2 Feb 2010 18:27 "Lynn McGuire" <lmc(a)winsim.com> wrote in message news:mvKdnYNrbtDuO_XWnZ2dnUVZ_tWdnZ2d(a)supernews.com... |> 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. That doesn't prove anything. And you have two problems, not just the zero-init problem that you first raised. As well as that, you didn't initially tell us that you were using non-standard F77. How do you expect to receive good advice if you tell us only a fraction of the story? | > 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: Giorgio Pastore on 2 Feb 2010 18:58
Maybe could help, maybe not: what about compiling with different level of optimization ? Giorgio |