question about assembly code

question about assembly code

[Olivier Maury]

Hi all,

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 !

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 ?

Regards

Olivier

Re: question about assembly code

[Jeff Kenton]

On 08/09/2011 10:25 AM, Olivier Maury wrote:
> Hi all,
>
> 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 !
>
> 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 ?
>
> Regards
>
> Olivier
>

Isn't fcmove a conditional floating move?

--jeff

Re: question about assembly code

[Ian Lance Taylor]

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

Re: question about assembly code

[Olivier Maury]

Ok thanks for the information !
But when the floating point happens gdb shows the fcmove instruction, 
the content of the variable is NAN (because of the UMR) but the 
condition must be false (at least the function has returned 0).
When the FPE is raised the floating point stack is :
=>R7: Valid   0x3fff8000000000000000 +1
   R6: Empty   0x00000000000000000000
   R5: Empty   0x00000000000000000000
   R4: Empty   0xc0778fb44823c7812000
   R3: Empty   0x3febc9539b888722a000
   R2: Empty   0x3feba10fafa06c1bb5b7
   R1: Empty   0x00000000000000000000
   R0: Empty   0x3feb8637bd05af6c6800



Any idea about what to check in my gdb ?


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

Re: question about assembly code

[Olivier Maury]

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

Re: question about assembly code

[Ian Lance Taylor]

Olivier Maury <Olivier_maury@mentor.com> writes:

> 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 ?

An fldl of NaN should put a value on the stack.

I don't know what is happening here.

Ian


> 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

Re: 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

is "-ifoobar.h=dir/foobar.h" possible?

[Mark Galeck]

Hello,

Windriver's diab C/++ compiler had this incredibly useful option for a long 
time:

-ifoobar.h=dir/foobar.h

This means to the preprocessor, 

"whenever you find 

#include "foobar.h"
or 
#include <foobar.h>

in the code, replace foobar.h with dir/foobar.h "


This option makes all other header file search options obsolete, in fact the 
whole "search" is obsolete, which means compilation is fastest, and also if you 
have multiple files in the filesystem with the same name, it is trivial to point 
which is the one you want to include (with thousands of files and copies all 
over the place, it can be very difficult to arrange traditional -I options so 
that all the correct header files are picked up, and not the unwanted copies).  




Is anything like that planned for gcc?  Possible?  


Thank you,

Mark 

Re: is "-ifoobar.h=dir/foobar.h" possible?

[Ian Lance Taylor]

Mark Galeck <mark_galeck@pacbell.net> writes:

> Windriver's diab C/++ compiler had this incredibly useful option for a long 
> time:
>
> -ifoobar.h=dir/foobar.h
>
> This means to the preprocessor, 
>
> "whenever you find 
>
> #include "foobar.h"
> or 
> #include <foobar.h>
>
> in the code, replace foobar.h with dir/foobar.h "
>
>
> This option makes all other header file search options obsolete, in fact the 
> whole "search" is obsolete, which means compilation is fastest, and also if you 
> have multiple files in the filesystem with the same name, it is trivial to point 
> which is the one you want to include (with thousands of files and copies all 
> over the place, it can be very difficult to arrange traditional -I options so 
> that all the correct header files are picked up, and not the unwanted copies).  
>
>
>
>
> Is anything like that planned for gcc?  Possible?  

As far as I know, no such option is planned for gcc.

It's certainly possible.  See the existing support for a header.gcc file
in libcpp/files.c.

Ian