 |
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2403 Location: Yateley, Hants, UK
|
Posted: Tue Aug 13, 2019 10:42 am Post subject: |
|
|
@John,
I think it's the /opt not the /p6 wot dun it; but reading up on what the P6 does, doesn't give me a lot of confidence. Core!
@Mecej4,
Just so we are on the same page, 1, seems to me to be a cause of the lack of robustness as defined by John, but 3. surely brings the code down every time, as I would expect 4. to also do. Improper integer expressions alternate 'coming right' with 'going wrong', and that should be obvious.
As for No. 2, why does that cause problems? Just asking.
Eddie |
|
Back to top |
|
 |
mecej4
Joined: 31 Oct 2006 Posts: 1899
|
Posted: Tue Aug 13, 2019 3:05 pm Post subject: Re: |
|
|
LitusSaxonicum wrote: |
As for No. 2, why does that cause problems? Just asking. |
Here is an example. Before you compile and run it, think out the answer, and compare that with what the program actually gives. Note that the subroutine seemingly does not touch the second argument at all.
Code: | program copy
dimension j(10)
j(1:10) = 1
call subr(j, j(1:9:2))
print '(10I3)', j
end
subroutine subr(j, k)
dimension j(10), k(5)
j(1:10) = 2
end |
In real code with aliasing bugs, the offending aliased variables may have been declared and defined in various places up long call chains, may have different names (because of Equivalence) bug may overlap in memory in some way.
This code is non-conforming, but detection of that fact can be very hard. |
|
Back to top |
|
 |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2403 Location: Yateley, Hants, UK
|
Posted: Tue Aug 13, 2019 3:56 pm Post subject: |
|
|
Hi Mecej4,
Thanks for the explanation and the example.
Good, I'm safe from that one. I simply haven't got a clue what "j(1:9:2)" is or does*, as I'm no enthusiast for some code constructs.
Indeed, having the same variable twice in an argument list seems to me to be an incantation to summon up Dannian Devilry. Just call me old-fashioned.
Perhaps the abliity to spell and the adoption of certain restrictive rules on 'clever' constructs may be keeping some of us safe in ways we didn't realise.
But by the time I'd converted the example to Fortran that I can read and understand at a glance, the problem had gone away (and before you ask, fixed format, in capitals, removing parameters that don't do anything and constructs I never use, WRITE instead of print, a numbered FORMAT statement - and thank heavens you used implicit type so I was OK there!)
Eddie
*I worked it out for myself, after pondering briefly whether it meant 2,4,6 ... or 1,3,5... The fact that you can do certain things doesn't mean that you should, much less must. |
|
Back to top |
|
 |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8219 Location: Salford, UK
|
Posted: Sat Oct 12, 2019 9:35 am Post subject: |
|
|
I have discovered why this failure was not showing up on my machine. It is a bug and I have made a note that it needs to be fixed. |
|
Back to top |
|
 |
mecej4
Joined: 31 Oct 2006 Posts: 1899
|
Posted: Sat Oct 12, 2019 10:34 am Post subject: |
|
|
It cannot be a case of using a different SALFLIBC.DLL, so I am curious to learn about the explanation. |
|
Back to top |
|
 |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8219 Location: Salford, UK
|
Posted: Tue Oct 15, 2019 3:19 pm Post subject: |
|
|
This bug has now been fixed for the next release of FTN95. The bug was restricted to the new functions erf, erfc, erfc_scaled, gamma, log_gamma, bessel_j0, bessel_j1, bessel_y0, bessel_y1, bessel_jn, bessel_yn. |
|
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
|