Floating-pointing overflow/underflow exception mystery

[seeocean2000]

I am new to IVF 9.0 with VS .Net 2002 (SP1), but have recently encountered a wierd floating-point exception problem I cannot figure why. I was debugging an over-flow problem, and it turns out it is related to an under-flow problem. I have recreated the problem with the following code (appended). This problem has been demonstrated on both Windows 2000 (SP4) and Windows XP (SP1), both professional editions.

The problem is that when I assign a very small (variable too_small) real*8 value to a real*4 variable (small), an under-flow occurs, as expected. However, at this point, the program also gives me an unexpected floating-point over-flow exception, as indicated in the comments.

Anyone who wants to try this is welcome to download the entire program's zip file with the project file.

By the way, oddly enough, I cannot catch this particular floating-point over-flow with /fpe:0 flag (by setting the "floating-point except handling" to "Underflow gives 0.0; Abort on other IEEE exceptions) in VS .Net. I have to go to the menu Debug->Exceptions->Win32 Exceptions, and force the exceptions to be handled by Debugger to catch it.

Does any one have any comments?

Yang
----
program Overflow

implicit none

! Variables
real*4 small, odd_num

real*8 too_small, large_sum

integer i, j

! Body of Overflow

odd_num = 1.0073068E-04
large_sum = 2.117469508051196E+034

! too_small will hold 4.757125456343630E-039 after this:
too_small = odd_num / ( 1 + large_sum)

! initialize small to 0.0
small = 0.0

! expect to get under-flow exception first,
! then over-flow exception
small = too_small

end program Overflow

[seeocean2000]

So no body replied to my message from last week. let me try to put it simpler to help you understand my problem:

- I assign a REAL*8 number (very small) to a REAL*4 number, and got an under-flow exception (result is 0.0), which is normal
- At the same time I also got an over-flow exception

My question is why do I get the over-flow exception? Those who are interested can download the project in zip and try it.

Thanks for any insights.

Yang

[greldak]

if 1+large_sum will not fit in a REAL*4 that may be generating the overflow and then

too_small = odd_num / ( 1 + large_sum)

becomes

too_small = odd_num / overflow

generating the underflow

[seeocean2000]

Craig,

That's what I thought too, but it's not the case:

- large_sum is REAL*8 and will not overflow
- the overflow exception occurs AFTER the underflow exception for the statement "small = too_small"

That is, both exceptions occur at the same statement! You can download the project (or the program) and try to see if it happens in your environment.

By the way, I have submitted this problem to Intel Premiere Support, but have not heard any thing (even a confirmation) yet from Intel.

Yang

[Steven_L_Intel1]

Yang, I don't see any Premier Support issues from your e-mail address. You filed this through http://premier.intel.com ? You should have been given an issue ID at that time - what was it?

[greldak]

Yes large_sum is REAL*8 but the constant 1 is only single precision - REAL*4 so the sum 1+large_sum may be being cast to single precision. You could try using the available functions to explicitly cast and use the double precision constant 1.0D0and see if that gives a clue to the problem.

[seeocean2000]

---

sblionel wrote:
Yang, I don't see any Premier Support issues from your e-mail address. You filed this through http://premier.intel.com ? You should have been given an issue ID at that time - what was it?

---

Steve,

I registered my IVF 9.0, and requested for a Premier user account at http://premier.intel.com. At the same time, I also added comments pointing to the Forum article here describing the problem that I have. I have not received my user account, nor conformation e-mail for the request. Maybe I did something wrong. If so, please advice. Thanks.

Yang

[seeocean2000]

---

craig.mitchell@mottmac.com wrote:
Yes large_sum is REAL*8 but the constant 1 is only single precision - REAL*4 so the sum 1+large_sum may be being cast to single precision. You could try using the available functions to explicitly cast and use the double precision constant 1.0D0 and see if that gives a clue to the problem.

---

Craig,

I changed the line of code from

too_small = odd_num / (1 + large_sum)

to

too_small = DBLE(odd_num) / ( 1.0D0 + large_sum)

but nothing changed. The two exceptions (one underflow, followed by one overflow) still occur at the line:

small = too_small

I also tried only changing the constant "1" to "1.0D0". Same result.
Yang

Message Edited by seeocean2000 on 09-20-2005 08:41 AM

[Steven_L_Intel1]

Yang,

Comments you add during registration may not be read for a long time. Please send me an e-mail at steve.lionel at intel.com and tell me the e-mail address you registered with and your serial number - I'll look up the info.

[giveup]

Yang,

It seems that you cannot avoid this extra overflow exception, because it's generated by Intel Fortran Run-Time Library in order to determine the version of Visual Studio you are using.

Vyacheslav.

[seeocean2000]

FYI - this problem has been reported to Intel, and is still an open issue (ID# 328164).

Yang