今度こそ、GCC 4.1正式リリース

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

[deleted user (19654)]

SSP とか ProPolice とかいうやつ [ibm.com]が
ついに正式リリースに入ったんですね!

これで普通の人でもバッファオーバーフローの脅威が減らせるわけで、すばらしい。

うちにあるマシンでは Momonga [momonga-linux.org] でも OpenBSD [openbsd.org] でも
SSP 有効だったので、なにも変わらないのですけど。

Re:propolice

[shadowin (23191)]

SSPによる性能劣化ってどんな感じなんでしょうか?
まぁ、この劣化が気になるのは、カーネルとかドライバとかくらいでしょうけど。

Re:propolice

[yuu3261 (11831)]

つhttp://pacsec.jp/psj04/psj04-hiroaki-j.ppt [pacsec.jp]

1-4%程度とのことです。

Re:propolice

[Anonymous Coward]

SSPの対応プラットフォームってどこかに記載がありますっけ？
あと、なんかIBMのがそのまま採用されたわけじゃなくって、RedHatの中の人が"再実装"したってIBMのページなんかにかいてあるのが気になるんですが、どういう意味なんでしょうか？

Re:propolice

[deleted user (19654)]

あ、ほんとですね。RedHat でほとんど完全書き下ろしみたいです:
IBM のは 3000 行以上、RedHat のは 700 行程度の変更 [gnu.org]

どうも IBM のは
デカすぎる [gnu.org]し、
作者が返事をしない [gnu.org]から
ダメと評価されていたようです。

気付かせてくださってありがとうございます。

で、リリースに入ったということは、すべて、あるいはほとんどの
アーキテクチャで使えるってことじゃないかと推測しますが…。

Re:propolice

[Tsann (15931)]

＞IBM のは 3000 行以上、RedHat のは 700 行程度の変更

行数だけ見ればそうですが、

RedHat:
  config/i386/i386.c  |    3
  config/i386/i386.md |  122 ++++++++++++++++++-----------
 
IBM:
  config/arm/arm.md |    8
  config/t-linux    |    2

ということはすべてのアーキテクチャに対してi386.md相当の修正が必要になるような気がします。その場合、IBMのと行数が大差なく…。

ちなみにgcc-4.1.0/configure.inを見たところ、AIXに対してlibsspのコンパイルを弾いていました。

Re:propolice

[shadowin (23191)]

コードをリファクタリングして700行程度で実現したのではなく、
IBMのものから700行程度(i386の部分のみ)を取り出してgccにマージした感じでしょうか。

Re:propolice

[Tsann (15931)]

# 中身を見ずに影響のあったファイル名だけでコメントしてます。

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

[Anonymous Coward]

mdってなんのファイルでしたっけ?

Re:propolice

[Anonymous Coward]

共通の内部表現からターゲットの命令を生成するための規則を定義しとります。
関数のプロローグ・エピローグはここで定義されているので、
ここをいじってチェック用のコードを生成させているのでしょう。

#ということをコードも読まずに書いているのでAC

Re:propolice

[yuu3261 (11831)]

4.1のsspですが、どこだったかでx86/x86-64/sparc/s390/sh/ppcで使えるという話を聞きました。が、裏は取ってません。
alphaとかmipsでは効かなかったという話も聞いたことがあるなぁ。

ソース嫁？

lfsとhlfs

[ona-neet (29940)]

今まで素のGCCを使ったlfs [linuxfromscratch.org]とSSPを有効にしたhlfs [linuxfromscratch.org]の
2種類がリリースされていたのだが、 今後はlfsとhlfsの統合になるのだろうか。
SSPを有効にするためにglibcにpatchを当ててる現状も変わる？

Re:lfsとhlfs

[yuu3261 (11831)]

FedoraCore5のglibcにはSSP用のサポート関数が 統合されていて、libsspは不要になっているよう ですね。まぁ、FC独自のパッチがあたっている可能 性はありますが。

M16C/M32C

[Anonymous Coward]

RenesasのM16C/M32Cのサポートが追加されていますね。マイコン野郎のみなさま人柱お願いします。

# 対応するbinutilsがまだリリースされていませんが

関連記事

[KENN (3839)]

勇み足だった前回のストーリー [srad.jp]。

Gentooな人

[Anonymous Coward]

Gentooでバリバリチューン（死語？）な人は燃え燃えなんだろうな～。

#KDEでﾓｻﾗｰなAC

Re:Gentooな人

[oku (4610)]

バリバリチューン (死語？) の定義によりますが、一応、今のところ (今 == 2006/03/04 05:33:54) Gentoo で sys-devel/gcc-4.1.0 は masked 状態のようです (testing の更に前)。

まあ、少なからぬ人が package.mask を書き換えるなり何なりして動かしていそうな気はしますが...

Re:Gentooな人

[Phalacrocoracidae (29780)]

丁度良いタイミングで、2/27にGentoo Linux 2006.0がリリース [gentoo.org]されたので、これからやってみようという方には最適でしょう。

ただ、前コメントのとおりgcc-4.1.0はmaskedなので、gcc-4.1.0から構築するにはpackage.mask等の書き換えが必要ですが。

# gentooの現時点のx86 stableなgccは3.4.5です

--
しないさせない！スルー力

Re:Gentooな人

[Anonymous Coward]

＞Gentooでバリバリチューン（死語？）な人は燃え燃えなんだろうな～。

なんと言うか週毎にビルドして追いかけていた
Gentooer(?)にとっては別に変わりないのでは？

# 去年年末までは追いかけてたのですが根性足りませんでした＞＜

Re:Gentooな人

[Anonymous Coward]

Gentooな人じゃないですがほぼ毎週ビルドしてます。
今は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な人

[Tsann (15931)]

オブジェクトファイルを跨るIPOをするのならld, arも変更する必要があります(iccではxild, xiar又はxild -lib)し、Makefileでのファイル間の依存性をつかったビルドもほぼできなくなります(hoge.cを変更しただけでもhoge.cで定義されている関数を呼んでいる各所の*.oや*.aが影響をうける)。

ldやarは結構コンパイラ依存しますし。
でもIPO?をするからといってMakefileの依存関係は変わりませんよ。*.cのコンパイル引数にhoge.oを渡すわけじゃありませんよね？ 実際にはldが再度cc1 *.oを呼び出してるんでは、と。
# icc9は知りませんがMIPS(IRIX)はそうやってました。

IPOには限界がありますし、レジスタの足りないx86では手も足も出ないのでは…。逆にProfile最適化の場合、profileから分岐確率を調べてヒントを埋め込むだけでも速度的にはかなり稼げると思います。

Re:Gentooな人

[masashi (569)]

has.x とか hlk.x を思い出しました…

# 最近こんなネタばかりだけどID

--
masashi

faster hand-written recursive-descent parser

[Anonymous Coward]

個人的には、from scratchな手書き再帰下降パーサ(「Changes, New Features, and Fixes」の「New Languages and Language specific improvements」、「C and Objective-C」を参照)が気になります。

速くなったかどうかじゃなくて、今まで通ってたのがはねられる、というのがないかどうかが。
(求む人柱)

Re:馬鹿ばかり

[of (17899)]

いいかげん、エサなしでも食いつくのやめようぜ。
# 心底あきれたのでID