Возьмем к примеру, следующий код

:#include <stdio.h>

int main (void)
{
  double a = 3.0, b = 7.0, c;

  c = a / b;

  if (c == a / b) {
    printf ("comparison succeeds\n");
  } else {
    printf ("unexpected result\n");
  }

  return 0;
}

и оказываеться что например на gcc, наверное и на других компиляторах, он вполне может выдавать unexpected result.

странно ?

Тут надо вспомнить немного теории о точности и FPU:

FPU оперирует в трех вариантах точности:

24 bits precision - одинарная точность (single precision), 32 bit length

53 bits precision - двойная точность (double precision),64 bit length

64 bits precision - повышеная точность  (extended precision or double extended precision), 80 bit length , вариант работы по умолчанию.

где например 80bit IEEE754 формат = 1bit sign + 15bit exponent + 64bit mantissa.

Кстати, уже должно быть понятно что SSE инструкции, вплоть до SSE4, по определению не могут работать с double extended precision ибо максимальный размер базовых типов - 64 bit length еще с SSE2 времен - просьба не путать с разрядностью XMM регистров (128 бит)

Немного я отошел в сторону - возращаясь к нашему коду , взглянем на asm и видим

00401082  |. DD05 40204000  FLD QWORD PTR DS:[402040]
00401088  |. DD5D F8        FSTP QWORD PTR SS:[EBP-8]
0040108B  |. DD05 48204000  FLD QWORD PTR DS:[402048]
00401091  |. DD5D F0        FSTP QWORD PTR SS:[EBP-10]
00401094  |. DD45 F8        FLD QWORD PTR SS:[EBP-8]
00401097  |. DC75 F0        FDIV QWORD PTR SS:[EBP-10]
0040109A  |. DD5D E8        FSTP QWORD PTR SS:[EBP-18]
0040109D  |. DD45 F8        FLD QWORD PTR SS:[EBP-8]
004010A0  |. DC75 F0        FDIV QWORD PTR SS:[EBP-10]
004010A3  |. DD45 E8        FLD QWORD PTR SS:[EBP-18]
004010A6  |. D9C9           FXCH ST(1)
004010A8  |. DAE9           FUCOMPP
004010AA  |. DFE0           FSTSW AX
004010AC  |. 9E             SAHF

как бы не так все и плохо

Присмотревшись поближе увидим/вспомним что

QWORD = quadruple word (64-bit)

(Кстати FDIV с операндом в памяти не может использовать повышеную точность  (double extended precision) )

компилятор постарался.

Например может еще и так

00401013  |> D97D FE        FSTCW WORD PTR SS:[EBP-2]
00401016  |. 0FB745 FE      MOVZX EAX,WORD PTR SS:[EBP-2]
0040101A  |. 25 C0F0FFFF    AND EAX,FFFFF0C0
0040101F  |. 66:8945 FE     MOV WORD PTR SS:[EBP-2],AX
00401023  |. 0FB745 FE      MOVZX EAX,WORD PTR SS:[EBP-2]
00401027  |. 0D 3F030000    OR EAX,33F
0040102C  |. 66:8945 FE     MOV WORD PTR SS:[EBP-2],AX
00401030  |. D96D FE        FLDCW WORD PTR SS:[EBP-2]

принудительно сбрасывая FPU в

64 bits precision - повышеная точность  (extended precision or double extended precision), 80 bit length

В итоге имеем:

Для сохранения/восстановления промежуточного значения используеться QWORD PTR (8 байт)  а для последующего сравнения используеться результат  в 10 байт (повышеная точность) !

Вариантов решения "unexpected result" недопонимания как бы несколько:

1. Например принудительное переключение FPU на работу с двойной точностью вместо повышеной точности, например так

void
set_fpu (unsigned int mode)
{
  asm ("fldcw %0" : : "m" (*&mode));
}

и дальше перед вычислениями

set_fpu (0x27F);

главное что мы устанавливаем контрольный регистр FPU , а именно биты 8 и 9 в соответствии:

The PC field (bits 9 and 8 ) or Precision Control determines to what precision the FPU rounds results after each arithmetic instruction in one of three ways:

00 = 24 bits (REAL4)
01 = Not used
10 = 53 bits (REAL8)
11 = 64 bits (REAL10) (this is the initialized state)

2. Так как размерность double подходит к SSE типам можно попросить компилятор использовать SSE вместо FPU

для gcc например так -mfpmath=sse -msse2

что обратиться во вполне вероятное использование SSE инструкций типа DIVSD и далее UCOMISD .

Однако этот подход не отрицает полное использование FPU, например для transcendental functions.

3. Вместо double переключаемся на long double ( размерность которого (попрошу еще раз свериться с используемым компилятором) должна быть 12 байт по сравнению с 8 )

что позволяет нам с успехом и без проблем сохранять

64 bits precision - повышеная точность  (double extended precision), 80 bit length , вариант работы по умолчанию для FPU

 и компилятор начнет использовать FPU деление в виде

FDIVP ST(1),ST

тем самым сохраняя наши ценные биты и будет использовать правильный размер операндов

004010AA  |. DB6D E8        FLD TBYTE PTR SS:[EBP-18]
004010AD  |. DB6D D8        FLD TBYTE PTR SS:[EBP-28]
004010B0  |. DEF9           FDIVP ST(1),ST
004010B2  |. DB7D C8        FSTP TBYTE PTR SS:[EBP-38]
004010B5  |. DB6D E8        FLD TBYTE PTR SS:[EBP-18]
004010B8  |. DB6D D8        FLD TBYTE PTR SS:[EBP-28]
004010BB  |. DEF9           FDIVP ST(1),ST
004010BD  |. DB6D C8        FLD TBYTE PTR SS:[EBP-38]

 где

TBYTE - temporary real, 80 bit.

Вообщем и все.

Пару полезностей по-ходу дела:

- прочитать текущие контольный регистр FPU можно например так

volatile unsigned short int cw;
__asm__ volatile("fstcw %0" : "=m" (*&cw));

 - для использования в Windows

#define PRECISION_SIGNLE 0x000
#define PRECISION_DOUBLE 0x200
#define PRECISION_EXTENDED 0x300

unsigned short int set_x87_precision( unsigned short int m_precision){
 volatile unsigned short int old_cw;
 volatile unsigned short int new_cw;
 _asm{
  fstcw old_cw
  mov ax,old_cw
  and ax,0fcffh
  or ax,m_precision
  mov new_cw,ax
  fldcw new_cw
 }
 return old_cw;
}

unsigned short int get_x87_control_word(){
    volatile unsigned short int cw;
 __asm { fstcw cw }
 return cw;
}

- по умолчанию приложения в Linux OS, MacOS оперируют с FPU в  повышеной точностью

и в Windows OS - двойная точность

вообщем , моя рука писать устала ...

надеюсь это было полезно, комментарии принимаются.