After a successful migration of CVF to IVF, an error appears...

[emreka82]

Hi,

I recently download and install the IVF composer XE 2011 and Visual Studio 2011 to my newly formatted computer. I was using CVF to my compiling issues and because of the lack of support during CVF use, I decided to switch forward to IVF. I step-by-step apply "the migration from CVF to IVF" article of the forum. After the building and running the program (...exe) everything "seems to be " right. But at some point of the running procedure, I encountered an error and the program stopped. The error is:

On the command:

forrtl: sever (408): fort: (3): Subsxcript #1 of the array INB has value 0 which is less than the lower bound of 1

then some exe and dll file names under the image header.

On the pop-up window:

Debug Assertion Failed !

Program:....exe
File: f:\\dd\\vctools\\ctr_bld\\self_x86\\crt\\src\\winsig.c
Expression: ("Invalid signal or error", 0)

For information on how your program can cause an assertion failure, see the Visual Cplusplus documentation assets.

In the light of my searches in the forum, I change "Stack Reserve Size" to 100000000 and heap-array value to 0. Nothing has changed...

Note: Why is thi assertion error related to Visual Cplus plus instead of Visual Fortran ? I did not understand...

[emreka82]

So this is normal, right ? Then, I understand that it shows informational messages about what debug was loaded and which wasn't and also that your program executed and exited normally. I hope that I am right :D

[Arjen_Markus]

Yes, it is normal. If you see return values of bizarre size, you should beware - it is usually a sign
something went wrong. In that sense it can indeed help.

Regards,

Arjen

[JohnNichols]

I migrated a number of Fortran 66 programs that were written at Berkeley in the late 1960's by graduate students for the strucutres group.

I had similar problems with IVF, even though these programs compiled on Control Data Fortran from punch cards, Microsoft Fortran 3.3, Powertation and CVF without errors, with these programs.

My programs are a lot less buggy on IVF, but when I get this type of error I have found using the Debug sceen and watching the actual values of the variables, and the values in the arrays. I found a lot of errors in the code, which ran and worked in the other compilers, but they were still errors. Powerstation gave me the greatest problems.

JMN

[Tino_Zerbini]

I have a similar problem when migrating from Digital Fortran to Intel Fortran and also execution under different processors and Windows version. I can get the IVF to copile old sourse code, execute it , and get output. The problem is that the output is diferent. So now the dilema. Which is correct? Thissource code has been in use for years and used by many organizations.

So, the statement "I found a lot of errors in the code, which ran and worked in the other compilers, but they were still errors" means that everything you have done before changing to IVF is wrong!

Any comments?

[jeremy_h]

Hi Tino,

The response you are likely to get is that a program that depends on ambiguous or non-standard behavior is not guaranteed to work. This sounds reasonable enough. Intel's position appears to be to rigorously support the published standard, with little or no regard to precedents set by older compilers. Whether this is reasonable depends on a user's circumstances, but they should at least be aware of this philosophy before embarking on a large migration.

Most coders do not inspect the LRM for each line of code. They write code, test it, and deliver it. Coders come and go, dozens of coders over the life of a typical legacy application. Legacy apps get filled with non-standard usage that works.

Our large legacy program migration had serious issues, and still has serious ongoing defects as the less common conditionals get executed. That IVF is descended from CVF gave us hope of a cleaner, higher quality migration than we achieved.

I should add that we experienced absolutely no bugs, defects or crashes of any kind with IVF. It is a very solid product. Steve will argue that this is in part because of adherence only to the standard, and not to arbitrary strangenesses supported by various popular compilers over the years.

- Jeremy

[Tino_Zerbini]

Hi Jeremy,

I think I understand what you meant by errors in the code. If a package works with an older compiler, and produces the so call "right answer", and if the answer obtained with the new compiler is wrong, the issue is with the source code not following the standard.

So, in other word, changing compilers is not trivial. I thank you for setting me straight and changing my way of thinking about compilers (I always thought FORTRAN is FORTRAN no matter what, and if it compiles then the results are right).

[Steven_L_Intel1]

I don't agree with Jeremy's assertion that we "rigorously support the published standard, with little or no regard to precedents set by older compilers". However, if the standard clearly specifies a behavior that contradicts that of an older compiler, the standard wins. You will note that we provide many options, mainly under the /assume switch, to select older, non-standard behavior and sometimes the default is not standard-compliant. I would also argue that Intel Fortran supports a wider variety of common extensions to the language than any other current compiler.

What we do insist on is that we reserve the right to improve diagnostics for incorrect programs and that incorrect programs may behave differently compiled with the Intel compiler than with other compilers. Just because compiler X did not give an error and gave you an answer you liked, that doesn't mean your program is correct.

Many customers have been delighted that programming errors were revealed by the Intel compiler that went undetected with other compilers, despite the short-term aggravation this can cause.