mhattaによる
2006年03月05日 12時11分の掲載
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 (スコア: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 (スコア: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
でした。# 外れてたらごめんなさい。
親コメント
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な人 (スコア: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から分岐確率を調べてヒントを埋め込むだけでも速度的にはかなり稼げると思います。
親コメント
faster hand-written recursive-descent parser (スコア:2, 興味深い)
速くなったかどうかじゃなくて、今まで通ってたのがはねられる、というのがないかどうかが。
(求む人柱)