forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Bad 32-bit code generated for simple expression
Goto page Previous  1, 2
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
John-Silver



Joined: 30 Jul 2013
Posts: 1219
Location: Aerospace Valley

PostPosted: Mon Aug 12, 2019 7:58 pm    Post subject: Reply with quote

... assuming they're reported all bugs will be found , eventually.

When they are found, and if they relate to a case where a 'workaround' was previously proposed the developers should:

a) check if the 'fix' invalidates the 'work around' or not

b) if it does then issue 'an advisory' (well documented of course) which states that the workarounf is no longer needed

c) if it doesn't affect the workaround then that can be added to the advisory also

I think it's called QA and all major compilers (Sf being no exception) expend a lot of effort into it, as we see on these forums with the efforts Paul puts in to fix bugs as speedily as humanely possible.

All revolves around documentation, whether it's to make sure that future complications to 'workaround's' are avoided, or just to formalise for posterity the fixing of the bug.

It's not easy, and none of us are perfect, but documentation is the backbone to everything.
_________________
''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 ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1219
Location: Aerospace Valley

PostPosted: Mon Aug 12, 2019 8:06 pm    Post subject: Reply with quote

As for:

Quote:
With /opt, the output is 0.00000. The correct output, without /opt, is 0.135904 (both with FTN95 8.51).


what happens with /OPT /P6 which Eddie's example was run with ?

and as for ...

Quote:
Small changes to the syntax of the program, without changing the semantics, may make the bug go into hiding.


when that's the case there's a distinct (fatal) lack of 'robustness', which is essential for a compiler.

As Eddie notes, Paul will be having kittens at the thought of tracking such things down.

Assuming it reaches the top of the 'to-do' list immediately.
_________________
''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 ... Smile "
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1196

PostPosted: Tue Aug 13, 2019 4:04 am    Post subject: Reply with quote

Lack of robustness is not just the compiler's fault. It can be caused by, for example:

1. Assuming that local variables are saved in some subroutines

2. Aliased actual arguments

3. Calling a subroutine inside a DO loop with the DO index variable as an argument that gets changed in the subroutine

4. Improper usage of mixed precision expressions
...
n. Any combination of all the preceding causes.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2047
Location: Yateley, Hants, UK

PostPosted: Tue Aug 13, 2019 10:42 am    Post subject: Reply with quote

@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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1196

PostPosted: Tue Aug 13, 2019 3:05 pm    Post subject: Re: Reply with quote

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
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2047
Location: Yateley, Hants, UK

PostPosted: Tue Aug 13, 2019 3:56 pm    Post subject: Reply with quote

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
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1219
Location: Aerospace Valley

PostPosted: Tue Aug 13, 2019 8:35 pm    Post subject: Reply with quote

I was commenting on cmpiler robustness, not user robustness.

It goes without saying that all users are non-robust. It's human nature that does that.

ALL compilers (simply by virtue of the fact that they are human-written thus inevitably have similar traits) are su8sceptible to bugs, and hence non-robustness at some level.

The example which was quoted (and it's apparent 'workaround), and then shown to be 'unreliable' (for want of a better hrase to explain that it might, or might not, work), is a clear example of non-robustness imo.

The difficult bit is identifying such anomalies, which is why Paul relies on user feedback to do so, as do all sofware vendors.
The (relatively) easy bit is then fixing them.

It's just like the nonsense with self-driving cars (or god-forbifěd srone parel deliveries or Zapata-transportation , and the like.
All the 'smart' algorithms involved depend on a youman being a) thinking of all the possible variations of behaviour under a myriad of conditions and restrictions 2) then programming all that cleverness into a machine which very speedily, very effectively .... but blindly ... executes those inděstructions.

It's not the technology that's smart, it's the people who implement ideas who sare the smarties .... provifiěding they get it right.

The idea is the easy bit, the implementation is the hard slog, and that's where robustness comes into play.

Some food for thought when in the future one is being driven by one of those clever algorithms and the car suddenly deviates into the path of that on-coming juggernaut.

Non-robustness of the developer, combined with non-robustness of the 'driver' for actually having believed all the hype and paying a fortune for the 'high' .

The same will be said of the first person to be killed by ehir 'vitěrtual flying postman' or a Dan Dare type.
_________________
''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 ... Smile "
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6067
Location: Salford, UK

PostPosted: Sat Oct 12, 2019 9:35 am    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1196

PostPosted: Sat Oct 12, 2019 10:34 am    Post subject: Reply with quote

It cannot be a case of using a different SALFLIBC.DLL, so I am curious to learn about the explanation.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 6067
Location: Salford, UK

PostPosted: Tue Oct 15, 2019 3:19 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
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