- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am having a problem compiling some fortran codes with optimization level 4. The sources compile and run properly when compiled with optimization level 1, but when compiled with optimization level 4 I get a math runtime error M6201 referencing the sqrt function. I'm using the df command to compile the source and am linking the fortran source with a piece of C source. Any ideas why this is happening?
Thank you, Betty
Thank you, Betty
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
First of all check the initialization of all variables, espeicially arrays. Non initialized variables contain "garbage", which leads to mathematical errors in optimized code.
Sabalan.
Sabalan.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Betty,
What you are encountering (IMHO) is that optimization often causes arithmetic operations to be performed in different orders for different levels and types of optimizations, leading to different round off and truncation errors, hence slightly different results. This is especially true for Intel processors, which have 80 bit FP registers and so give different results if a value is maintained in a register rather than stored in memory as a 64 bit result. There is a compiler option that forces consistancy in precision, at a cost in performance, by always returning FP results to memory.
Hint: there is a kludge that often works in CVF6.6-use the "fast" option, which doesn't check the validity of the arguement to a library math function, and often returns a zero or a NaN rather than generating an error message. It's still a case of GIGO, but if you only print the result and ignore it, your program will continue to execute without halting.
Keith
What you are encountering (IMHO) is that optimization often causes arithmetic operations to be performed in different orders for different levels and types of optimizations, leading to different round off and truncation errors, hence slightly different results. This is especially true for Intel processors, which have 80 bit FP registers and so give different results if a value is maintained in a register rather than stored in memory as a 64 bit result. There is a compiler option that forces consistancy in precision, at a cost in performance, by always returning FP results to memory.
Hint: there is a kludge that often works in CVF6.6-use the "fast" option, which doesn't check the validity of the arguement to a library math function, and often returns a zero or a NaN rather than generating an error message. It's still a case of GIGO, but if you only print the result and ignore it, your program will continue to execute without halting.
Keith

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