今度こそ、GCC 4.1正式リリース 27
ストーリー by mhatta
FLOSSの大黒柱 部門より
FLOSSの大黒柱 部門より
hylom曰く、"フリーのコンパイラスイート、GNU Compiler Collection 4.1が2006年2月28日に正式リリースされた。新機能やバグ修正などはChanges, New Features, and Fixes
に、新機能の詳細はGCC Wikiに情報がある。
タレコミ男はコンパイラに疎いのでよくわからないが、とりあえずInter-Procedural Optimizations（IPO、プロシージャ間の最適化）や自動ベクトル化などの最適化機能が大幅に強化されたほか、バッファオーバーフローなどを利用したアタックからソフトウェアを防ぐ機能などが追加されているようだ。IPOや自動ベクトル化などの機能はIntel純正のIntelプロセッサ向けコンパイラ「Intel Compiler（ICC）」の特徴としてよく耳にしていたので、実際生成するコードはICCと比較してどうなのかを比較してみたいところ。
LinuxカーネルのGCC 2.95サポートもそろそろ廃止される模様だし、古いコンパイラを愛用している方々もそろそろ新しいコンパイラに挑戦し、人柱となってみてはいかがだろうか？"
propolice (スコア:3, 参考になる)
ついに正式リリースに入ったんですね!
これで普通の人でもバッファオーバーフローの脅威が減らせるわけで、すばらしい。
うちにあるマシンでは Momonga [momonga-linux.org] でも OpenBSD [openbsd.org] でも
SSP 有効だったので、なにも変わらないのですけど。
Re:propolice (スコア:3, 興味深い)
まぁ、この劣化が気になるのは、カーネルとかドライバとかくらいでしょうけど。
Re:propolice (スコア:5, 参考になる)
1-4%程度とのことです。
Re:propolice (スコア:1, 興味深い)
あと、なんかIBMのがそのまま採用されたわけじゃなくって、RedHatの中の人が"再実装"したってIBMのページなんかにかいてあるのが気になるんですが、どういう意味なんでしょうか？
Re:propolice (スコア:3, 参考になる)
IBM のは 3000 行以上、RedHat のは 700 行程度の変更 [gnu.org]
どうも IBM のは
デカすぎる [gnu.org]し、
作者が返事をしない [gnu.org]から
ダメと評価されていたようです。
気付かせてくださってありがとうございます。
で、リリースに入ったということは、すべて、あるいはほとんどの
アーキテクチャで使えるってことじゃないかと推測しますが…。
Re:propolice (スコア:2, 参考になる)
行数だけ見ればそうですが、ということはすべてのアーキテクチャに対してi386.md相当の修正が必要になるような気がします。その場合、IBMのと行数が大差なく…。
ちなみにgcc-4.1.0/configure.inを見たところ、AIXに対してlibsspのコンパイルを弾いていました。
Re:propolice (スコア:1)
IBMのものから700行程度(i386の部分のみ)を取り出してgccにマージした感じでしょうか。
Re:propolice (スコア:2, 興味深い)
IBMのはあくまでパッチとして提供することを意識して実装されています。オリジナルへのコード影響を最小限にするために、必要となる関数呼び出しを埋め込んで全てprotector.cで動いてるかと。たぶん、SSP本体はターゲットアーキテクチャに依存しない中間言語で実装されています。
上の方でパフォーマンスへの影響は1-4%とありましたが、こちらの実装でしょうね。
RedHatのはパフォーマンスへの影響を最小限にするために、適切なファイルに埋め込んでいますし、SSP本体はターゲットアーキテクチャに依存するmdファイル（machine descriptionファイル）も利用して実装されています。
# 本家に取り込まれることを前提としてコードを書けるRedHatの強みですね。
i386.mdだと"stack_protect_set"辺りであってるのかな？ もしそうならこれが書かれているのは、
- i386.md
- rs6000.md
- s390.md
- sh.md
- sparc.md
でした。# 外れてたらごめんなさい。
Re:propolice (スコア:0)
Re:propolice (スコア:1, 参考になる)
関数のプロローグ・エピローグはここで定義されているので、
ここをいじってチェック用のコードを生成させているのでしょう。
#ということをコードも読まずに書いているのでAC
Re:propolice (スコア:1)
alphaとかmipsでは効かなかったという話も聞いたことがあるなぁ。
ソース嫁？
lfsとhlfs (スコア:3, 興味深い)
2種類がリリースされていたのだが、 今後はlfsとhlfsの統合になるのだろうか。
SSPを有効にするためにglibcにpatchを当ててる現状も変わる？
Re:lfsとhlfs (スコア:4, 参考になる)
M16C/M32C (スコア:3, おもしろおかしい)
# 対応するbinutilsがまだリリースされていませんが
関連記事 (スコア:2, 参考になる)
Gentooな人 (スコア:2, おもしろおかしい)
#KDEでﾓｻﾗｰなAC
Re:Gentooな人 (スコア:3, 参考になる)
バリバリチューン (死語？) の定義によりますが、一応、今のところ (今 == 2006/03/04 05:33:54) Gentoo で sys-devel/gcc-4.1.0 は masked 状態のようです (testing の更に前)。
まあ、少なからぬ人が package.mask を書き換えるなり何なりして動かしていそうな気はしますが...
Re:Gentooな人 (スコア:2, 参考になる)
ただ、前コメントのとおりgcc-4.1.0はmaskedなので、gcc-4.1.0から構築するにはpackage.mask等の書き換えが必要ですが。
# gentooの現時点のx86 stableなgccは3.4.5です
しないさせない！スルー力
Re:Gentooな人 (スコア:1, すばらしい洞察)
なんと言うか週毎にビルドして追いかけていた
Gentooer(?)にとっては別に変わりないのでは？
# 去年年末までは追いかけてたのですが根性足りませんでした＞＜
Re:Gentooな人 (スコア:5, 参考になる)
今は4.1.1 prereleaseを使っていますが、linux kernelもXorg X11もFirefoxもコンパイルでき、普通に動きます。
GNU/Linux pentium4環境でicc9(Intel cc version9)を使っていますが、
* icc9は大きなソースファイルを-O3でコンパイルするのに非常にメモリを喰うが、gcc4はそんなに喰わない。でもgcc3時代よりは肥大化している。
* icc9のIPO(リンク時に複数のオブジェクトファイルの垣根を超えてinline化などをする最適化)は更にメモリを喰う
* 手元のものを幾つか比較した限り数値計算主体のものはicc9の方が速いこともあるが劇的な差があるわけではないので、gccを前提に作られたconfigure.inやソースを書き直す手間のほうが大きいかも…
* firefoxをgcc4.1でMOZ_PROFILE_GENERATE=1, MOZ_PROFILE_USE=1としてprofile最適化をしてビルドするとicc9より体感としては速い気がする
厳密に比較したわけではないのであくまでご参考に。
gccはIPOではなく、profileを利用した最適化に力をいれているのではなかったかな?
オブジェクトファイルを跨るIPOをするのならld, arも変更する必要があります(iccではxild, xiar又はxild -lib)し、Makefileでのファイル間の依存性をつかったビルドもほぼできなくなります(hoge.cを変更しただけでもhoge.cで定義されている関数を呼んでいる各所の*.oや*.aが影響をうける)。
Re:Gentooな人 (スコア:5, 参考になる)
でもIPO?をするからといってMakefileの依存関係は変わりませんよ。*.cのコンパイル引数にhoge.oを渡すわけじゃありませんよね？ 実際にはldが再度cc1 *.oを呼び出してるんでは、と。
# icc9は知りませんがMIPS(IRIX)はそうやってました。
IPOには限界がありますし、レジスタの足りないx86では手も足も出ないのでは…。逆にProfile最適化の場合、profileから分岐確率を調べてヒントを埋め込むだけでも速度的にはかなり稼げると思います。
Re:Gentooな人 (スコア:1)
# 最近こんなネタばかりだけどID
masashi
faster hand-written recursive-descent parser (スコア:2, 興味深い)
速くなったかどうかじゃなくて、今まで通ってたのがはねられる、というのがないかどうかが。
(求む人柱)
Re:馬鹿ばかり (スコア:0, 余計なもの)
# 心底あきれたのでID