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 

Initialization to zero
Goto page Previous  1, 2, 3
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
PaulLaidler
Site Admin


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

PostPosted: Tue Sep 05, 2017 8:16 am    Post subject: Reply with quote

Steve

Regarding your experience when moving to a different version of the compiler, I would recommend that you keep an open mind concerning the source of the problem. Since you are apparently using uninitialised variables, it is quite possible/likely that a change in the compiler or the operating system has simply exposed an existing user programming error. For example, an uninitialised variable might consistently have had a zero value say (by chance as it were) simply from of the context. Any change could expose the fault by using a different garbage/random value.
Back to top
View user's profile Send private message AIM Address
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Tue Sep 05, 2017 9:17 am    Post subject: Reply with quote

Thanks, Paul

I would like to think it was never intentional to use unintialised variables, simply that with /ZERO in place, they happened to get initialised and so would never be spotted - until now !

Are you suggesting, Paul, that - quite mysteriously and quite by happenchance - that these variables were consistently being initialised in v6 and all of a sudden they are not now in v8.1 or v7 whenever ? Surely, this change would need to be by design or intention ? For the same reason that using /LO does not intialise these variables, ie the compiler is not actually doing the job it was supposed to do.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Sep 05, 2017 10:01 am    Post subject: Reply with quote

Steve

I am suggesting that you keep an open mind. It is too easy to blame the compiler. As I have tried to explain, if you use /LO then the compiler will tell you that /LO is only provided for use with /CLR. Unless you are creating a .NET assembly, /LO is not an option for you.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Tue Sep 05, 2017 1:33 pm    Post subject: Reply with quote

The Fortran Standard has a delightful and all-encompassing phrase, "behavior undefined". That may apply to your program, especially if the program has instances where variables are used without having been previously defined.

"Undefined" means "anything can happen, or not happen".

Your program may work correctly for a long period, and you may not even know that there is a problem. Without warning, one day you start getting incorrect results, or the program crashes, and you may start casting doubts on a compiler or OS update. Other events covered by "undefined": running your program empties my bank savings account, or causes NK missiles to be launched at Mongolia, or causes a butterfly to flap its wings in Madagascar.

Bite the bullet now; diagnose and fix the bugs in your program. There is no known compiler with a /just_give_me_the_correct_results option.
Back to top
View user's profile Send private message
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Wed Sep 06, 2017 5:45 pm    Post subject: Reply with quote

Thank you mecej4, we are resigned to your point, now that we are staying with v8.1.

Finding 'External exception' or Invalid floating point operation' has now happened a few times since moving compilers to v8.1 and employing tracing - sending messages to DebugViewer - identifies poor programming.

But, I have just come across one instance where introducing trace statements actually makes the program work ! I remember noticing some 'old' code where a statement had been broken up with an accompanying note that the compiler at the time was unable to process the original statement correctly.

Do the forum have any advice that can help overcome my problem ? Compiling the offending routine with /UNDEF or with /ZERO makes no difference to the outcome.

Thanks
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Wed Sep 06, 2017 6:52 pm    Post subject: Reply with quote

How to go about fixing your code is going to be mainly decided on the basis of how big your code is and what tools are available to you. If the code is not suitable for posting, that is one more hindrance.

FTN95 is great for small to medium size projects or projects that make use of graphics and Windows features, but there are other compilers and tools that I would consider using in parallel.

Sometimes, it is better to log a runtime error to a log file, take a reasonable corrective action, and proceed with execution, rather than abort execution on each message. The Lahey-Fujitsu compiler was good in that regard.

There are static code analysis tools such as FTNCHEK and Forcheck.

Floating point errors are routinely fixable if a traceback is available.
Back to top
View user's profile Send private message
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Thu Sep 07, 2017 9:54 am    Post subject: Reply with quote

Most appreciated. When our product was an EXE and compiling with v6, we used the traceback to great effect.

Our dilemma is that the 'offending' code - that needed trace statements inserted before working in the DLL form - compiled with v6 or v8.1 and without the trace statements worked fine as an EXE. As it has done for many years.

Compiling this same code in v6 or v8.1 but in the Delphi wrapper, ie. as a DLL, causes 'Invalid floating point operation' and 'External exception', until the trace statements are introduced. It would appear the traceback facility is no more when creating a DLL.

Does this suggest a Delphi involvement that needs addressing or the way we build our DLL ?

The LNK to create the DLL is as follows :

MAP product-name.MAP
PERMIT_DUPLICATES
NOSIZEWARNING
DLL
LO *.OBJ [ several instances ]
LO named.DLL [ several instances ]
EXPORTALL
FILE product-name
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, 3
Page 3 of 3

 
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