View previous topic :: View next topic |
Author |
Message |
awoolley
Joined: 12 Jan 2007 Posts: 3
|
Posted: Fri Jan 12, 2007 12:57 pm Post subject: Floating point stack overflow using /OPTIMISE |
|
|
I am having problems with some code compiled using /OPTIMISE (with v 5.0).
I get a floating point stack overflow error in the debugger. I am running the program on a 64-bit machine.
I can compile and run exactly the same code using /DEBUG without any problems.
Does anyone have any suggestions on what to do?
thanks |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Fri Jan 12, 2007 7:20 pm Post subject: |
|
|
You cannot use /optimise when debugging. The options are not compatible.
It is recommended that you upgrade from 5.0 to 5.01. |
|
Back to top |
|
|
DrTip
Joined: 01 Aug 2006 Posts: 74 Location: Manchester
|
Posted: Sun Jan 14, 2007 9:45 pm Post subject: |
|
|
Hi Paul
Alice is my colleague, Although I am not as familiar as Alice with the code in question, which is legacy and old school fortran.
We can't really get a sample to you, but our problem is this we are running code on a 64bit xp machine using the 3GB switch we need this to get the memory required for the code to run at all.
the code compiled to debug will run through in around 42 hours on this machine however when we try to do an optimised compile the code just stops somwhere with no error messages at all.
to try and track this down to give us some stack info about where to look for the bug ( if thats what it is) we ran the opimised code using SDBG.
This at least had the efect that SDBG gave us a error message that we could post here and maybe the name of the subroutine to look for bugs in )via the stack window.
The window message is
"floating point stack overflow"
what flags do we have to set to get an optimised code which will not fall over?
Since the code runs thorugh fine in DEBUG we are a little lost for ideas.
in FULL_DEBUG our third party libraries seem to stop functioning this may be a clue or a red herring
I have been unable to reproduce code that will get a similar result in a short code example.
our stack is huge something like 800MB could this be the a problem?
Carl |
|
Back to top |
|
|
awoolley
Joined: 12 Jan 2007 Posts: 3
|
Posted: Mon Jan 15, 2007 12:12 pm Post subject: |
|
|
I have repeated the process using v 5.01 of the compiler, and the results are the same. I also increased the stack size simultaneously, so it does not appear to be this which is the problem.
Any suggestions?
Thanks,
Alice |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Mon Jan 15, 2007 5:46 pm Post subject: |
|
|
There is a stage between /DEBUG and /OPTIMISE that is obtained without using any of the debugging options and without using /OPTIMISE. This gives you the default optimisation but not the extras. I would try this first to see if it runs and if the runtime is acceptable.
Failing that I would do some more detailed testing on a smaller model. For example, if you are using large arrays then I would make the array size a parameter and test first with small arrays using /CHECKMATE. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Tue Jan 16, 2007 6:54 am Post subject: |
|
|
I would expect that the problem is that /optimise is introducing a problem in the code. The most likely cause would be some non-standard fortran, such as local variable values not being retained between calls. The use of the optimiser assumes more standard fortran usage than /debug allows.
/debug also has a small overhead over /optimise and does not significantly increase the run time, especially compared to /check.
You may be interested in running the program for a shorter time or problem and using the /timing option to find which routines require /optimise. Then use /optimise for only the few routines that would show a benefit to the run time.
Being more selective in your use of /optimise may provide the solution you want. |
|
Back to top |
|
|
|