question about assembly code

[Bob Plantz]

I would do several things in this situation:
1. Download the Intel (AMD?) manuals.
2. Read the parts that deal with x87 exceptions.
3. Re-compile the code with no optimization, obtaining the assembly code 
(-S option), and see if the problem still exists.
4. Repeat steps 2 and 3, adding in more optimization, as needed.

I note the following from "Intel(R) 64 and IA-32 Architectures Software 
Developer's Manual":
8.5.5 Numeric Underflow Exception (#U)
The x87 FPU detects a floating-point numeric underflow condition 
whenever the
rounded result of an arithmetic instruction is tiny; that is, less than 
the smallest
possible normalized, finite value that will fit into the floating-point 
format of the
destination operand. (See Section 4.9.1.5, “Numeric Underflow Exception 
(#U),” for
additional information about the numeric underflow exception.)

--Bob

On 8/9/2011 9:01 AM, Olivier Maury wrote:
> Ok there is one main difference when the value to be put on the stack 
> is NAN : it is not put on the stack !
> The fldl instruction just do nothing (expected ?) and that's why 
> instead of having two values on the FP stack I have only one value !
> Even if the intel documentation says nothing about that configuration 
> I guess that's why the fcmove raise a FPE...
> What do you think ?
>
> On 08/09/11 16:44, Ian Lance Taylor wrote:
>> Olivier Maury<Olivier_maury@mentor.com> writes:
>>
>>> I was wondering, is the following assembly code correct:
>>> c94: e8 fc ff ff ff call c95
>>> <load_param_def_given+0x1d1>
>>> c99: 84 c0 test %al,%al
>>> c9b: dd 45 d0 fldl -0x30(%ebp)
>>> c9e: dd 45 d8 fldl -0x28(%ebp)
>>> ca1: da c9 fcmove %st(1),%st
>>> ca3: dd d9 fstp %st(1)
>>> ca5: dd 5d d0 fstpl -0x30(%ebp)
>>> ca8: 89 f8 mov %edi,%eax
>>>
>>> This code is some optimized assembly code extracted from the object
>>> file using objdump. My concern here is that I have a test instruction
>>> without the corresponding jump !
>> The test instruction is setting the flags for the fcmove instruction.
>>
>>
>>> That piece of assembly comes from a code that look like:
>>> if (my_function(param1,&out_param))
>>> value = out_param;
>>>
>>> with :
>>> out_param a double value that is not assigned with a default value
>>> and
>>> char my_function(long param1, double *out)
>>> {
>>> char ret = 0;
>>> ... do some stuff ...
>>> if (some_property)
>>> {
>>> ... do some stuff ...
>>> *out = a_value_computed;
>>> ret = 1;
>>> }
>>> ....
>>> return ret;
>>> }
>>>
>>> And taking that optimized code in a debugger it crash with a FPE from
>>> time to time because even if the my_function returns 0 it seems to do
>>> the assignement (value = out_param) with an unitialized out_param
>>> value !
>>>
>>> What do you think ? Am I doing something wrong or is it a gcc bug ?
>> It's pretty hard to say anything about an incomplete example. However,
>> fcmove is a conditional move, so the code will only do the move if the
>> value returned is non-zero. I don't see anything wrong in what you have
>> shown us.
>>
>> Ian