木村です.

> 小野さん [FreeBSD-users-jp 91684] Re: long double の bug ? について 
>  96bitオプションをつけた場合、拡張倍精度の仮数部が 
> 52bit(=doubleの仮数部のビット幅)程度しかない、というの 
> が問題だったんですね。
  このメールに続いて送る鶴谷さんへの回答も御覧いただきたいの
ですが,この問題が生じるのは「変数」でなく「定数」です.

> そうだとすると、MacOSXに載っているgcc4 
> では、どちらのオプションを付けても仮数部(2)が64bit幅の 
> $560513589になっていますから、FreeBSD/i386 6.2のgcc 
> 固有の問題ということになりそうですね。

  小野さんが FreeBSD 7.0 で,また鶴谷さんが FreeBSD 6.3, 7.0
/i386 にて gcc 4 も試して下さいましたが,やはりこの問題が
生じています.FreeBSD 6.2 に限定した話でもなく,gcc 3/4 の
差異の問題でもなさそうです.


> していますから、この二つのmovabsqは仮数部の代入命令だと 
> 思います。
>  なお、amd64のsizeof(long double)は16でした。

>>> 変数 lc の定義部分は
>>>
>>> .LCFI1:
>>>     movabsq $4614256656552045848, %rax
>>>     movq    %rax, -8(%rbp)
>>>     movabsq $-2958705157555305931, %rax

  いや,各々が 64bit ありますから,sizeof(long double) が 16
すなわち 128bit だとすると大き過ぎると思いまして.

4614256656552045848 を 16 進数にすると
40 09 21 fb 54 44 2d 18  <- こうなります.
40 09 21 fb 54 44 2d 18  <- 変数 c を dump するとこうなります.
なので,上の行は変数 c への代入でしょう.

ただまあ,-2958705157555305931 を 16 進数にすると
d6 f0 91 55 c8 cc c2 35  <- こうなります.
c9 0f da a2 21 68 c2 35  <- 変数 lc を dump するとこうなります.

なぜ上位 bit が違うのか悩ましいですが,format の違いとかしか
考えられません.

                     Satoshi Kimura  
([&#x30E1;&#x30FC;&#x30EB;&#x30A2;&#x30C9;&#x30EC;&#x30B9;&#x4FDD;&#x8B77;])

メールによる返信