Wrong numerical result in algebraic expression

[rainer_feldbacher]

An algebraic expression in a numerical assignment using continuing lines is computed erroneously, mixing up multiplication and addition.

The piece of code is part of a very large (200.000 code lines) technical calculation projekt written in FORTRAN.

Until 2004 the project was maintenanced using CVF5.0D, and the formula was computed properly. Now, using CVF6.6a, this expression is computed erroneously. The error appears both in debug and release mode.

I found the failure location by chance, when I debugged through the code, wondering why calculation results of 5.0D differed from 6.6a. However, there are very many similar expressions in the large project.

I extracted a small test project (CVF6.6a) out of the original large program and the error was reproducible. See attached test.zip.

As far as I can read assembler code, also therein seem to be evidence of a compiler bug

Most recently, I found a similar problem at a different location in the source. There an addition is performed instead of an subtraction. But now things become weird: There computation is wrong in CVF5.0D and correct in CVF6.6a !!??

What is happening here? Is this a compiler bug or am I doing something wrong?

Code:

c	begin of critical part.
c     the following 5 lines are the original code:
c
         QZU1 =   VL0*1008.*COMM_WIRBDAT.EINGABE.T1
     &           + (S+BT)*COMM_WIRBDAT.EINGABE.CPF*TE
     &          + COMM_WIRBDAT.EINGABE.WGEHALT
     &            * COMM_WIRBDAT.EINGABE.BMENGE*2230.*TE
     &          + RR*COMM_WIRBDAT.EINGABE.CP*COMM_WIRBDAT.EINGABE.TR
c
c	end of critical part
c
c     this expression should compute like follows: (fixed form line length 132 !)
	   qzu1a = VL0*1008.*COMM_WIRBDAT.EINGABE.T1
	   qzu1a = qzu1a + (S+BT)*COMM_WIRBDAT.EINGABE.CPF*TE
	   qzu1a = qzu1a + COMM_WIRBDAT.EINGABE.WGEHALT* COMM_WIRBDAT.EINGABE.BMENGE*2230.*TE
	   qzu1a = qzu1a + RR*COMM_WIRBDAT.EINGABE.CP*COMM_WIRBDAT.EINGABE.TR
c
c
c
c     but it is erroneously interpreted like:
	   qzu1b = VL0*1008.*COMM_WIRBDAT.EINGABE.T1
	   qzu1b = qzu1b + (S+BT)*COMM_WIRBDAT.EINGABE.CPF*TE
	   qzu1b = qzu1b + COMM_WIRBDAT.EINGABE.WGEHALT* COMM_WIRBDAT.EINGABE.BMENGE*2230. !!!!!!!!
	   qzu1b = qzu1b * TE		!!!!!!!!!
	   qzu1b = qzu1b + RR*COMM_WIRBDAT.EINGABE.CP*COMM_WIRBDAT.EINGABE.TR
c     
c	The variables qzu1a, qzu1b have been introduced just for debuging convenience. 
c	The variables qzu1a, qzu1b are of no further meaning in the original code.


.....

141:       &           + (S+BT)*COMM_WIRBDAT.EINGABE.CPF*TE
142:       &          + COMM_WIRBDAT.EINGABE.WGEHALT
004010DF   fld         dword ptr [S (004473e4)]
004010E5   fadd        dword ptr [BT (004473dc)]
004010EB   fmul        dword ptr [_COMM_WIRBDAT_COMMON+80h (0044b000)]
004010F1   fmul        dword ptr [TE (00447450)]
004010F7   fstp        st(1)
004010F9   fld         dword ptr [VL0 (0044741c)]
004010FF   fmul        dword ptr [KERNEL32_NULL_THUNK_DATA+30h (0043a18c)]
00401105   fmul      
  dword ptr [_COMM_WIRBDAT_COMMON+70h (0044aff0)]
0040110B   fadd        st,st(1)
0040110D   fstp        st(1)
0040110F   fld         dword ptr [_COMM_WIRBDAT_COMMON+10h (0044af90)]
00401115   fmul        dword ptr [_COMM_WIRBDAT_COMMON (0044af80)]
0040111B   fmul        dword ptr [KERNEL32_NULL_THUNK_DATA+2Ch (0043a188)]
00401121   fadd        st,st(1)				<---- this line and
143:       &            * COMM_WIRBDAT.EINGABE.BMENGE*2230.*TE
00401123   fmul        dword ptr [TE (00447450)]	<---- this line seem to be in wrong order!
00401129   fstp        st(1)
144:       &          + RR*COMM_WIRBDAT.EINGABE.CP*COMM_WIRBDAT.EINGABE.TR
0040112B   fld         dword ptr [RR (00447470)]
00401131   fmul        dword ptr [_COMM_WIRBDAT_COMMON+38h (0044afb8)]
00401137   fmul        dword ptr [_COMM_WIRBDAT_COMMON+54h (0044afd4)]
0040113D   fadd        st,st(1)
134:
135:  crfrfrf20050720
136:  c
137:  c   begin of critical part.
138:  c     the following 6 lines are the original code:
139:  c
140:           QZU1 =   VL0*1008.*COMM_WIRBDAT.EINGABE.T1
0040113F   fstp        dword ptr [QZU1 (00447394)]
145:  c
146:  c   end of critical part
147:  c

.....



            COMM_WIRBDAT.AUSGABE.ABMENGE_F1 = 			!!computed correctly
     &            (COMM_WIRBDAT.EINGABE.D1+COMM_WIRBDAT.EINGABE.D2-0.4)
     &            * 2. * COMM_WIRBDAT.EINGABE.HMO 
     &            * COMM_WIRBDAT.EINGABE.fwertwa

            COMM_WIRBDAT.AUSGABE.AHW_F2 = 			!!computed correctly
     &            (COMM_WIRBDAT.EINGABE.D1+COMM_WIRBDAT.EINGABE.D2-0.4)
     &            * 2. * H2 * COMM_WIRBDAT.EINGABE.fwertwa

            COMM_WIRBDAT.AUSGABE.AQ_F3 = 					
     &            ((COMM_WIRBDAT.EINGABE.D1+COMM_WIRBDAT.EINGABE.D2-0.6)
     &             * 2. * (H3-0.5) + WIRB_Q 
     &             - COMM_WIRBDAT.EINGABE.FH * COMM_WIRBDAT.EINGABE.NUQ
     &             - COMM_WIRBDAT.EINGABE.ZA * COMM_WIRBDAT.EINGABE.FZE)  !!this term is added instead of subtracted in CVF5.0D !!
     &            * COMM_WIRBDAT.EINGABE.fwertwa

[Intel_C_Intel]

Have you tried it with CVF6.6C?

[Steven_L_Intel1]

It's a bug of a form I have seen before. Replace the dots for the field delimiters with % and you'll get the results you want. It's also wrong in Intel Fortran - I'll report that.

[rainer_feldbacher]

Using CVF6.6C does not help, the problem remains the same.

Replacing the delimiter dots by "%" works, but it means to me that I have to do it some thousands times.

Does anybody know how I can automatize the job, but only with the delimiter-dots?

And does anybody know, whether Compaq resp. HP will fix the bug?

I sent the problem to vf-support@compaq.com, but I did not get an answer yet but the automatic one.

Thank you very much, Rainer

[Intel_C_Intel]

Rainer,

Compaq are discontinuing sales and support for CVF - in December I think - so you can take it as read they won't be fixing anything that is wrong with it.

You might have to change to IVF.

Dan

[Steven_L_Intel1]

There will be no more fixes made to CVF. The problem will get fixed in Intel Visual Fortran. If you want to do global edits, you can do a series of replacements of

.FIELDNAME1

with

%FIELDNAME1

one of these for each field name in the structure.

[rainer_feldbacher]

Do you know when Intel will fix that problem? (Time/Version)

Doing the replacements in the code (. vs %) would be too big a job for us because of the large number of different fields and different structures.

We prefer to work around by migrating to IVF, but it must be soon.

[Steven_L_Intel1]

I'm hoping that the fix will be available in our next 9.0 update, scheduled for late October.

[rainer_feldbacher]

Is that fix available now? We bought IVF in the meantime!

[Steven_L_Intel1]

I believe so. The fix should be in 9.0.025.

[jim_dempsey]

>>

Does anybody know how I can automatize the job, but only with the delimiter-dots?

<<

I have written a tool that can do this. I have used it on aapplication that was being converted from F77 to F90. The application is comparible to the one you referenced (~700 modules and~180,000 lines). If IVF V9.0.025 does not correct your problems then I would be available for consultation. I am surprised the "." verses "%" was your major problem. For my project it was the continuation lines involving initializers for data statements.

Jim Dempsey