 |
forums.silverfrost.com
Welcome to the Silverfrost forums
|
| View previous topic :: View next topic |
| Author |
Message |
mecej4
Joined: 31 Oct 2006
Posts: 1899
|
 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: 8211
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 |
|
|
LitusSaxonicum
Joined: 23 Aug 2005
Posts: 2402
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: 1899
|
| 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 |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
