View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Tue Nov 20, 2018 4:48 pm Post subject: Incorrect evaluation of vector expressions |
|
|
The bugs reported here are akin to those that I recently reported in the thread http://forums.silverfrost.com/viewtopic.php?t=3892 . Here, I have a drastically simplified and short example code, and am able to shed some light on what the generated code is actually doing, as opposed to what it should have done.
The example source code:
Code: | program xpi
implicit none
integer, parameter :: nx = 2
integer :: i, n = nx*4
real :: x(4*nx) = (/ (1.0, 2.0, 3.0, 4.0, i=1,nx) /)
real :: s
s = sum((x(2:n-2:2)-x(3:n-1:2))**4)
print *,s,' (expected: 83)'
end |
The results that I obtained from FTN95 8.30.279:
Code: | -default- 26.3333
/opt 26.3333
/check Internal compiler error
/checkmate Internal compiler error
/64 21.0000
/64 /opt 21.0000
/64 /check 0.0000
/64 /checkmate 0.0000 |
Inspection of the /exp listings for some of the cases (where there is output and that output is not zero) shows that the 32-bit EXE actually computes and the 64-bit EXE actually computes where
and instead of computing the requested result |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Tue Nov 20, 2018 5:01 pm Post subject: |
|
|
Many thanks. I will make a note of this. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Wed Nov 21, 2018 2:00 am Post subject: |
|
|
don't forget the second espression from the other post quoted above where d (line 12) gave a FP error for 32bit
A mod of this code here with the form:
s = sum ((x(:n-3:2) - x(4:n:2))**4)
would test that too (and presumeably give a FP error)
I noted on the original 'big' probleme code that this expression starts with a ':' in the first term.
I wonder if that could relate to the problem too ?
maybe 1:n-3:2 would work ?
This is a good example of where the 'suck-it-and-see' method of diagnosing the problem (progressively weeding out the source in the 'good-old-fashioned' code elimination way) combines nivìcely with subsequent 'clever' debugging to understand exactly what is hapening. _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Wed Nov 21, 2018 2:01 am Post subject: |
|
|
mecej4 - in your single lines quoted at top you've pur **3 (twice) in error of **4 !!! _________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Wed Nov 21, 2018 10:44 am Post subject: |
|
|
I wonder why it has taken so long to find this out?
Perhaps Holmes has the answer: "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth."
Could it be that no-one has ever used this form of statement? Or if they did, the result didn't matter? Or perhaps they blithely assumed the wrong answer was correct? Certain predictions in climate science leap instantly to mind.
My own guess is that the first is the real answer. After all, traditionally one would do it with some sort of explicit loop. I would, perhaps in so doing revealing that there are some parts of Fortran 90 et seq. that haven't entered my consciousness, or that within days of writing the statement I wouldn't have a clue what it did! (That is, if I could).
On a serious note, is it the raising to the power where the problem lies? I suspect so, because converting to repeated multiplication gives 83. And there was me, thinking that 42 was the answer to life, the universe and everything ...
Eddie |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Wed Nov 21, 2018 11:01 am Post subject: Re: |
|
|
John-Silver wrote: | mecej4 - in your single lines quoted at top you've put **3 (twice) in error of **4 !!! | Blame not the messenger!
The compiler emits machine code for two loops for Line-8. The first loop calculates the array valued expression to the right of '='. The second loop sums up the elements of the temporary array that the first loop filled in.
Here are the 32-bit assembler instructions in the first loop generated for Line-8 of the source code.
Code: | Label __N3
fld X[ebx*8+4] # u = X(i+1)
fsub X[ebx*8+8] # v = X(i+2), u - v
fst Temp@9 # u-v
fmul Temp@9 # (u-v)**2
fmul Temp@9 # (u-v)**3
fdiv X[ebx*8+8] # (u-v)**3/v
fstp [eax+ebx*4] # store element of temporary result array
inc ebx # increment i
cmp ebx,Temp@7 # loop count reached?
jle __N3
|
If any of the elements of v happen to be zero, doing '/v' with such an element will cause an FP 0-divide exception. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Fri Nov 23, 2018 2:57 am Post subject: |
|
|
ooer missus, after reading that and TRYING to understand it ... my cervical functioning is affected
_________________ ''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... " |
|
Back to top |
|
|
|