- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a program that the release version works on more robust computers but fails on two computers with RAM memory of 48 and 64 MB respectively. However when I compile a debug version to try and locate where the program fails on these two machines, the program runs fine. Is there something in the release version optimizer that I could set or does the debug version do some error trapping that the release version doesn't
Link Copied
- « Previous
-
- 1
- 2
- Next »
25 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tom,
Actually, it seems much more like we are in the realm of the philosophy of programming.
I don't understand your position at all. The root cause of the problem is not that the CVF compiler is missing an option to initialize variables for you, but that you (or someone else) has written an incorrect program. I didn't see anything in your prior posts where you admitted that your code is in error.
You stated :
..., MY first goal in writing FORTRAN programs that people rely upon to make multimillion dollar decisions is first and foremost to write a 'correct' program that gives the 'right' answer, hence the importance of a compiler that minimizes the effort to write 'correct' programs.
This is a non-sequitor. If you do not intialize variables before usage, the fact is that you are NOT writing a correct Fortran program.
The first step in minimizing the effort to write a correct Fortran program is to understand the requirements of that language. The compiler is an implementation of the language standard. You are getting different answers from your Fortran code because of a coding error not because of the compiler options used. If you want to maintain this coding style you should modify your stated goal to specify either 'Lahey Fortran with option x', 'Salford Fortran with option y', or 'Visual Basic' for that matter. As it stands, maybe people should not rely on your code to make multi-million dollar decisions because it is incorrect code. If you ported your code to other platforms/compilers than Win32/CVF you would run into the same issue. If you want a given Fortran program to be portable between compilers or platforms that program should conform to the Fortran standard. And IMO, I believe that if you are releasing Fortran source code to the public for use in decision making, you should explicitly state whether or not it is standard conforming.
It is interesting that the standard first defines what is a standard conforming program, and then what a standard conforming compiler must do with it. A common statement on comp.lang.fortran is that a compiler can do anything it wants to with nonstandard code, including 'start World War III'.
If you want to use an implementation that supports a nonstandard feature, by all means, go ahead. People (including myself) take advantage of extensions every day. In fact, those extensions can be the deciding factor in purchasing a compiler.
But, you should use those extensions knowingly. And, if you want to complain that vendor X doesn't also support that feature when you move to their compiler, that's one thing. But to state that Vendor X's compiler doesn't produce correct code is just plain wrong.
Also, to claim that all programs of size/merit will have some bugs is undoubtedly true. But to use that claim as a crutch to justify ignoring both well-known good programming practices and the requirements of the language tool you are using is cavalier at best and possibly negligent at worst.
This thread started because of differing results in release vs debug builds. There are frequent posts on c.l.f. about this for all different combinations of compilers/platforms. So this is not an isolated case. The standard reply from any number of contributors there is this is almost always an indication of programming error, be it explici t or by assumption. There can be many programming errors that can cause this (as Steve mentioned). In this case, the assumption that it is OK not to initialize variables before being used is the cause of the problem. Not a missing compiler option.
I apologize for any harshness. I hope my being frank doesn't obscure the message.
Good luck,
John
Actually, it seems much more like we are in the realm of the philosophy of programming.
I don't understand your position at all. The root cause of the problem is not that the CVF compiler is missing an option to initialize variables for you, but that you (or someone else) has written an incorrect program. I didn't see anything in your prior posts where you admitted that your code is in error.
You stated :
..., MY first goal in writing FORTRAN programs that people rely upon to make multimillion dollar decisions is first and foremost to write a 'correct' program that gives the 'right' answer, hence the importance of a compiler that minimizes the effort to write 'correct' programs.
This is a non-sequitor. If you do not intialize variables before usage, the fact is that you are NOT writing a correct Fortran program.
The first step in minimizing the effort to write a correct Fortran program is to understand the requirements of that language. The compiler is an implementation of the language standard. You are getting different answers from your Fortran code because of a coding error not because of the compiler options used. If you want to maintain this coding style you should modify your stated goal to specify either 'Lahey Fortran with option x', 'Salford Fortran with option y', or 'Visual Basic' for that matter. As it stands, maybe people should not rely on your code to make multi-million dollar decisions because it is incorrect code. If you ported your code to other platforms/compilers than Win32/CVF you would run into the same issue. If you want a given Fortran program to be portable between compilers or platforms that program should conform to the Fortran standard. And IMO, I believe that if you are releasing Fortran source code to the public for use in decision making, you should explicitly state whether or not it is standard conforming.
It is interesting that the standard first defines what is a standard conforming program, and then what a standard conforming compiler must do with it. A common statement on comp.lang.fortran is that a compiler can do anything it wants to with nonstandard code, including 'start World War III'.
If you want to use an implementation that supports a nonstandard feature, by all means, go ahead. People (including myself) take advantage of extensions every day. In fact, those extensions can be the deciding factor in purchasing a compiler.
But, you should use those extensions knowingly. And, if you want to complain that vendor X doesn't also support that feature when you move to their compiler, that's one thing. But to state that Vendor X's compiler doesn't produce correct code is just plain wrong.
Also, to claim that all programs of size/merit will have some bugs is undoubtedly true. But to use that claim as a crutch to justify ignoring both well-known good programming practices and the requirements of the language tool you are using is cavalier at best and possibly negligent at worst.
This thread started because of differing results in release vs debug builds. There are frequent posts on c.l.f. about this for all different combinations of compilers/platforms. So this is not an isolated case. The standard reply from any number of contributors there is this is almost always an indication of programming error, be it explici t or by assumption. There can be many programming errors that can cause this (as Steve mentioned). In this case, the assumption that it is OK not to initialize variables before being used is the cause of the problem. Not a missing compiler option.
I apologize for any harshness. I hope my being frank doesn't obscure the message.
Good luck,
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
John,
No offense taken - we are just having a discussion about how to solve a recurring problem that CVF users encounter. I have offered what I think is one solution to a part of the problem being that users end up with different results depending upon compiler options, thus making it very difficult to track down bugs in a program that, by definition, is incorrectly written. Otherwise, there would be no need to use the debugger.
Steve has made it clear that the best solution is not high on his list of priorities and I can live with that. All I am trying to say is that an option to initialize variables would be relatively easy to implement and would help solve part of the problem when trying to track down the cause of incorrectly written programs. Use it if you find it useful, don't use it if you don't. I agree that it is not the fault of the compiler when an incorrectly written program gives different answers. All I have been trying to do is point out one solution that would facilitate finding where the problem is in incorrectly written code without having to resort to print statements.
I think we've reached the end of any further constructive discussion on this matter, so let's let this sleeping dog lie. I have enjoyed the exchange.
Tom
No offense taken - we are just having a discussion about how to solve a recurring problem that CVF users encounter. I have offered what I think is one solution to a part of the problem being that users end up with different results depending upon compiler options, thus making it very difficult to track down bugs in a program that, by definition, is incorrectly written. Otherwise, there would be no need to use the debugger.
Steve has made it clear that the best solution is not high on his list of priorities and I can live with that. All I am trying to say is that an option to initialize variables would be relatively easy to implement and would help solve part of the problem when trying to track down the cause of incorrectly written programs. Use it if you find it useful, don't use it if you don't. I agree that it is not the fault of the compiler when an incorrectly written program gives different answers. All I have been trying to do is point out one solution that would facilitate finding where the problem is in incorrectly written code without having to resort to print statements.
I think we've reached the end of any further constructive discussion on this matter, so let's let this sleeping dog lie. I have enjoyed the exchange.
Tom
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a program the I have compiled with full debug. When I run it using the debugger (F5) the program bombs, when I run it using (F5) it runs fine. Does data initialization take place at compile time or run time? Any clues on why the same executable will run outside the debugger but not within the debugger?
Ray
Ray
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a program the I have compiled with full debug. When I run it using the debugger (F5) the program bombs, when I run it using (F5) it runs fine. Does data initialization take place at compile time or run time? Any clues on why the same executable will run outside the debugger but not within the debugger?
Ray
Ray
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Data initialization is compile/link time. Probably uninitialized variables again.
Steve
Steve
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »