replica nfl jerseysreplica nfl jerseyssoccer jerseyreplica nfl jerseys forums.silverfrost.com :: View topic - Bad 32-bit code generated for simple expression
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
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2403
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: 1899

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: 2403
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
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8219
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 AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1899

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: 8219
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 AIM Address
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