- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello. I've received a geophysical model from a colleague. I received source code, a working executable and project files for an early Windows Compaq Fortran development environment.
I managed to compile his code with the latest Intel compiler (both via the DE and command line via ifort) for Windows. However, the model did not run as it should. I mentioned this to the original developer and he recommended I try to obtain an older compiler. He suggested I look for either the last Compaq compiler and environment or the earliest Intel Visual Fortran package.
If I have a licensed version of Visual Studio (2008), can I download an earlier version of the Intel Visual Fortran package? I'd like to mimic the original developers environment and ensure I can recompile his source and run the model so that it produces the same validated output. Ultimately, I'd like to get this package built on OSx. Any help would be appreciated. Thanks.
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would recommend against such an approach - try to figure out why the program does not work with the current compiler. If it was originally built with CVF, try adding the /Qsave and /Qzero options. Add /warn:interface as well. If you converted the project from CVF, go into the Diagnostics property page and enable "Check Routine Interfaces".
The oldest Intel compiler that works with VS2008 is 10.1.019. You CAN get older versions following the instructions in this article. You can't get Compaq Fortran from us.
It is entirely possible (indeed, probable) that the program has errors that were masked by features or lack of optimizations in older compilers.
The oldest Intel compiler that works with VS2008 is 10.1.019. You CAN get older versions following the instructions in this article. You can't get Compaq Fortran from us.
It is entirely possible (indeed, probable) that the program has errors that were masked by features or lack of optimizations in older compilers.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Besides the options Steve suggested, /fp:source /arch:IA32 (if using the ia32 compiler) will bring the compilation more in line with CVF.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A couple of thoughts that I may add:
1. I have found it useful to keep an older computer (CVF will not run in native mode on Windows 7 X64) in running condition with CVF on it , since this environment provides a baseline, even if the source code has bugs that do not manifest themselves in this ancient environment. CVF had one nice feature: it allowed a makefile to be generated and exported from a project. For console programs, this removes the dependence on the IDE, and allows testing the program with other compilers and on other operating systems. With larger programs, I'd use fsplit to break up the source, compile one source at a time with ifort and CVF-compatible options, until I found a subprogram that gave different results. The buggy portion of code would have been narrowed down at that point. Sometimes, the whole sequence may need to be iterated since changes in one subprogram can cause bugs to be triggered in others.
2. If you have mixed-language programs or previously compiled objects, libraries or DLLs in your project, especially if there are character arguments, you have to devote some effort to ensure calling convention compatibility.
1. I have found it useful to keep an older computer (CVF will not run in native mode on Windows 7 X64) in running condition with CVF on it , since this environment provides a baseline, even if the source code has bugs that do not manifest themselves in this ancient environment. CVF had one nice feature: it allowed a makefile to be generated and exported from a project. For console programs, this removes the dependence on the IDE, and allows testing the program with other compilers and on other operating systems. With larger programs, I'd use fsplit to break up the source, compile one source at a time with ifort and CVF-compatible options, until I found a subprogram that gave different results. The buggy portion of code would have been narrowed down at that point. Sometimes, the whole sequence may need to be iterated since changes in one subprogram can cause bugs to be triggered in others.
2. If you have mixed-language programs or previously compiled objects, libraries or DLLs in your project, especially if there are character arguments, you have to devote some effort to ensure calling convention compatibility.
![](/skins/images/45C6C2D737ED71F4C51F0145C8CB1E9C/responsive_peak/images/icon_anonymous_message.png)
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page