木村です．
下記のようなトラブルに遭遇しました．調べた限りではこの問題は
報告されていないので，この ML で情報を募りたくメール致しました．
1. 状況
FreeBSD 5.3 + gcc(3.4.2) で作成した，拡張倍精度 (long double)
を使ったプログラムを FreeBSD 6.2 + gcc(3.4.6) にて使用すると，
結果が違いました．検討した末，以下のことが分かりました．
gcc に -m96bit-long-double (default) と -m128bit-long-double の
option を付けた場合を各々 96bit,
小野です。
結論から言えば、i386システム用のgccにおけるコン
パイルオプションなのではないでしょうか。
% gcc -m96bit-long-double -S s.c -o s1.a
% gcc -m128bit-long-double -S s.c -o s2.a
これを簡易に試してみました。いづれもプラットフォームはIntel
Core2DuoのMacintoshです。
1) MacOSXネイティヴな環境 (OSX 10.5.2)
この環境では、二つのアセンブラソースは僅かに違い、変数lcの定
義において96bitオプションでは
木村です．
小野さん [FreeBSD-users-jp 91681] Re: long double の bug ? について
結論から言えば、i386システム用のgccにおけるコン
パイルオプションなのではないでしょうか。
済みません．書き忘れていました．i386 での話です．
-m96bit-long-double, -m128bit-long-double は確かに i386 用の option
ですが，私が問題にしているのは，少なくとも FreeBSD 6.2 にて，
この option の差異によって，計算結果に本来生じるべきでない差異が
こんにちは、小野です。
私こそ問題をちゃんと把握していなかったようで、すみません。
96bitオプションをつけた場合、拡張倍精度の仮数部が
52bit(=doubleの仮数部のビット幅)程度しかない、というの
が問題だったんですね。そうだとすると、MacOSXに載っているgcc4
では、どちらのオプションを付けても仮数部(2)が64bit幅の
$560513589になっていますから、FreeBSD/i386 6.2のgcc
固有の問題ということになりそうですね。
ところで
movabsq されている二つの行はどちらも変数 lc の仮数部
なのでしょうか？
続けまして小野です。
FreeBSD/i386 7.0Rを導入して試してみましたが、同様の問
題は残存しています。やはり拡張倍精度の変数への代入部分のアセ
ンブラコードはオプションの違いによって異なっていますね。数値は6.2
の場合と同じです。gccは4.2.1 20070719になっている
のですが。
--
;; So I must go before you see me fall
;; 小野すず＠平城京右京五条三坊
こんにちは、鶴谷です。
[#x30E1;#x30FC;#x30EB;#x30A2;#x30C9;#x30EC;#x30B9;#x4FDD;#x8B77;] さん
続けまして小野です。
FreeBSD/i386 7.0Rを導入して試してみましたが、同様の問
題は残存しています。やはり拡張倍精度の変数への代入部分のアセ
ンブラコードはオプションの違いによって異なっていますね。数値は6.2
の場合と同じです。gccは4.2.1 20070719になっている
のですが。
うちでもこうでした：
FreeBSD 7.0, gcc 4.2.1 : NG
FreeBSD
take です。
皆さん ありがとうございます。
milterでもcfでもできそうってことがわかってよかったです。
もうひとつわかった事は、私の圧倒的な知識不足のようです。
みなさんのアドバイスや設定例を頂いて、
なるほどなるほど、ではやってみようとなれない程に力量不足でした。
cf/README、こうもり本と修行をつんだ後
設定する事にしました。
（Fromを制限したからって抜本的なSpamやウィルス対策にはなっていないので）
また何かあれば報告させて頂きます。
