EGCSは実験の/増強されたGNUコンパイラシステム(Experimental/Enhanced Gnu Compiler System)を表わします。 gccに、より多くの最適化およびより多くの特徴を組み入れるゴールを備えたgccの子孫です。 EGCS開発プロセスは一般に、より開放されています。より詳細および公表には、このページを見てください。

1.7 EGCSとPGCCはどう関係がありますか。

PGCCがGCCと以前に関係した同じ方法でPGCCはEGCSに関係があります。つまり、 PGCCはEGCSの現在のバージョンに基づきます。また、私たちはEGCSをPGCCにパッチするためにdiffを配布します。将来の開発はEGCSと同様にPGCCの上でも行われます。したがって、PGCCは両方のプロジェクト中の増強から利益を得るでしょう。

1.8 PGCCとGCCの関係は何ですか。

オリジナルのGCCはフリーソフトウェアファウンデーション(FSF)によって配布されます。スケジューリングコードは、実際のgcc(2.8.0に)に組み入れられました。しかし、恐らく、他のものは何もそうではありません。

1.9 なぜGNU ccのペンティアムバージョン?

標準のGCCはペンティアムのために最適化されません。
特別のペンティアムに最適化されたプログラムは30%高速でありえます!
Linux/FreeBSDなどに利用可能なペンティアムコンパイラはありませんでした。
GCC 2.8.0はいくつかのペンティアム最適化を持つでしょう。しかし、cygnusは最も恐らくペンティアム・プロだけをサポートするでしょう。スケジューリングコード(fschedule-insns2)は、私たちのバージョンから得られます、したがって、pgccほど速くない:)

1.10 どうバージョン名を読みますか。

「pgcc」バージョンにはそれらが基づくegcsバージョンと同じ名前があります、つまり、egcs-2.90.20->pgcc-2.90.20。

1.11 いくらですか。

無料です。

1.12 どこで入手することができますか。

gcc.ml.org で私たちの主要なサイトを見てください。

1.13 FTPミラーはどこですか。

現在、diffとバイナリは次で利用可能です:

ftp.pmi.saitama-med.ac.jp (日本)
linux.cis.nctu.edu.tw/pub/packages/pcg (台湾)
ftp.goof.com/pub/pcg(アメリカ)

注: このウェブ・サーバあるいは私たちの主要なサイトのいずれか上でより長くて良いリストを見つけることができます。

1.14 PGCCのためのウェブミラーはどこですか。

www.pmi.saitama-med.ac.jp/pcg 日本
linux.cis.nctu.edu.tw/pcg 台湾
www.nightflight.com/~pcg アメリカ

注: このウェブ・サーバあるいは私たちの主要なサイトのいずれか上でより長くて良いリストを見つけることができます。

1.15 利用可能なメーリングリストがありますか。

beastium-list@desk.nl (pgccに興味を持つすべての人々のためのメーリングリスト)。
pgcc-list@desk.nl (pgccの開発者のためのメーリングリスト)は、Pascalの承認を必要とします :)(彼に電子メールを送る)
本文に「subscribe beastium-list」と書き、subject行(件名)を空にして「majordomo@desk.nl」に電子メールを送ることによりメーリングリストに参加できます。「pgcc-list」も同様です。

1.16 プロジェクトのステータスは何ですか。

これらは現時点で含まれる主要な人々です (私が誰かを忘れた場合に、私に単に伝えてください):

Marc Lehmann [ほとんどすべて]...
Andrew Crabtree <andrewc@rosemail.rose.hp.com> [DJGPPバイナリ]
Pascal Van Dam <pascal@ramoth.xs4all.nl> [支援]
Andrew Pollard <andrew@odie.demon.co.uk> [GNU/Linuxバイナリ]
Bernhard Rosenkraenzer <root@BOL-SubNet.ml.org> [パッチuploader]
Andrew Zabolotny <bit@freya.etu.ru> [OS/2移植]
Shaw Terwilliger [オリジナルのWWWデザイン]

1.17 PGCCはどのプラットフォーム上で動作しますか。

pgccは、オリジナルのgccが動作するほとんどすべてのプラットフォーム上で動作します。(非インテルさえ、しかし、私たちは、生成されたコードの質に関して何も言うことができません...より速いかも知れないが、必要としません!) プリコンパイルされたバイナリは、私たちの主要なサイトでlinuxおよび他のオペレーティングシステムに利用可能です。

1.18 PGCCの歴史は何ですか。

かつてインテルのチームがいて、特別のペンティアム最適化を持つためにGNU cc 2.4.5をパッチしました。これはいわゆる技術デモだけでした。したがって、共通のベンチマーク・プログラムの30%の速度増加を達成した後、彼らはプロジェクトを止めて、公にリリースしました。時間とともに、多くの人々は、時々パッチのいくらかの研究を行いました。様々なサイト上でgcc-2.6.3iを見つけることができます。今、pgccがあります(名前に注意する)。そして、最も安定したものであるように見えます。

1.19 ペンティアムGCCのグループは何のためにありますか。

パッチされたGCCがすべて多少不安定であり(つまり、それらはいくつかのプログラムをコンパイルできません)、多少安全でないので(これは多くの場合において看過されていますが、時々間違っているコードを生成します)、PCGが作成されました。 PCGは、コンパイラの安定を改善し、生成されたコードの質を増強することを望みます。

1.20 どう支援できますか。

私たちはハッカーを求めています..そして時間を! 私たちと連絡をとってください!

1.21 pgccのa.outバージョンはどうですか?

私たちはa.outのことを知りません ;) 通常のGNUコンパイラをa.outバージョンとしてコンパイルすることができれば、同様にpgcc動作するようにすることができるはずです。私たちはa.outバージョンをサポートしません。pgccはa.outのためにコンパイルできますが、自分で行わなければなりません。

1.22 どうやって私は自分の国にミラーをセットアップできますか。

確かに、望めば、... それを行う3つの推薦された方法があります。

私がrshかsshとrdistかrsyncでアクセスできるpcgのためのアカウントをセットアップします。私はそれによって規則的に最新版を送付します。 (これは好ましい方法です)... 単にftpファイルを置くパスとhtmlを置くパスを私に伝えます。
w3mirrorとftpmirrorを入手して、独自にミラーリングを行います(あなたが何らかの理由のためにアカウントを配付したくなければ、セキュリティの悩みの種はより少ないでしょう)。
単にftpmirrorを入手して、ftpのみのミラーを作ります。

1.23 誰と連絡をとることができますか。

PGCCあるいはペンティアム・コンパイラ・グループに関する質問があれば、 Marc Lehmann <pcg@goof.com> あるいは Pascal Van Dam <pascal@ramoth.xs4all.nl> に躊躇せずメールしてください!

ソースコード・パッチを持っていれば(例えばあなたがハッカーである場合)、それらをいつでもドキュメント化し(あるいは説明する)、 Marc Lehmann <pcg@goof.com> に直接送ることができます。しかし、pgccをハックしはじめる前に、彼に尋ねるべきです(不必要な仕事が行われないことを保証するために)!

FAQのためのより多くの提案を行っていれば、 Marc Lehmann <pcg@goof.com> にいつでもメールできます。 subjectにPCG [トピック、あるいは空]を置くことを確かめてください。例えば:

subject: PCG [Improve FAQ] あるいは subject: PCG []

2 互換性問題
　

2.1 pgccでlinuxカーネルをコンパイルできますか。

もちろん! しかし、カーネルにpgcc(およびegcsのような最近の他の進んだコンパイラ)の下でのみ現れる様々なバグがあります。 2.1.50(以降)のバージョンは通常問題無くコンパイルします。 (もちろん、pgccの中のバグの可能性も常にあります。) 2.0.xカーネルはバグが多く、多くの場合pgccで適切にコンパイルできません(以下を参照)。

2.2 PGCCとLinux 2.0.xはどうですか。

Linux　2.0.xは、gcc-2.7.2以前のバージョンで偶然動作した不法な構築を多数使用します。 PGCCは重大なコードをどんどんうまく最適化します。したがって、PGCCでコンパイルされた場合、Linux 2.0.xは一般に動作しません。 egcsとlinux 2.0ページは、最も重要な問題のためのいくつかのパッチがあります。また、多くのユーザは、そのようなパッチされたカーネルに関して問題を持っていませんが、私は、これらのパッチを当ててさえカーネルを信用しません。

3 インストール/配置
　

3.1 プリコンパイルされたバイナリをインストールする方法

mv /usr/bin/gcc /usr/bin/oldgcc
tar xvpzf tarfile.tgz -C /

デフォルトコンパイラとしてバイナリのコンパイラをインストールするでしょう(実際のコンパイラではなく/usr/bin/gccに上書きするでしょう)。上に示されるように古い/usr/bin/gccを保存した場合、問題に遭遇すればoldgccを使用して古いコンパイラを呼ぶことができます。

3.2 アンインストールする方法

オリジナルの/usr/bin/gccをバックアップしなければなりません。(あるいはcour配布からのgccを再インストールする)

/usr/bin/gccに上書きすれば、pgccが無効になります。しかし実際に除去するには、バージョンに依存して/usr/lib/gcc-lib/i586-pc-linux-gnu/ (このパスは様々です。システムの正確なパスを得るためにgcc-vを使用します)中のコンパイラ・ディレクトリを削除しなければなりません。

3.3 どうやって前のコンパイラを起動しますか。

フルインストールを行う場合さえ、前のgcc(恐らくgcc-2.7.2になるでしょう)は失われません。一般に、望む多くのアーキテクチャのためのgccの多くのバージョンをインストールできます。それらの間に選ぶために、gccには2個のスイッチがあります:

-V	起動したいgccのバージョン。 -V2.7.2あるいは-V2.7.2pのように使用されます。
-b	gccがコードをコンパイルするためのターゲットマシン/アーキテクチャ。典型的な用途は-bi-486linuxおよび-bi586-pc-linux-gnuを含んでいます。

PGCCのアーキテクチャ(GNU/Linuxの下の)は一般にi586-pc-linux-gnuです。古いコンパイラはアーキテクチャi486-linuxあるいはi586-linux(古代の配布はi386-linuxを使用します)およびバージョン2.7.2を恐らく使用するでしょう、したがって、-V2.7.2 -bi486-linuxを使用する場合、恐らく古いコンパイルを得るでしょう。

3.4 コンパイルする方法

pgccをコンパイルする「正しい方法」はありません。しかしながら、ここに、利用可能なシンプルな方法があります(pgccに付属するファイルINSTALLを読むほうがよい)。

ソースを入手します(egcsを入手して私たちのパッチを適用するか、私たちのサイト(利用可能な場合)から十分なソースツリーを得て、最新版を適用してください)
cd gcc
vi INSTALL(あるいはinfo -f gccを試みて、インストール指示を読む)
configure
make
make install
より多くの情報のためにINSTALLを読む、例えば、ステージ2や3のコンパイラを作る方法で。 これは強く推薦されます!

3.5 libcとbinutilsのどのバージョンを使用しなければなりませんか。

推薦された組み合わせはglibc-2.0.6(以上)(あるいはlibc-5.4.22、5.4.43以上を推薦)とbinutils-2.8.1.0.15です。これらは実際に最小のバージョンです、新しいバージョンはさらによいはずです(そしてさらに速いコードを生成するかもしれない)。

3.6 スナップをインストールするためにペンティアムライブラリをインストールする必要がありますか。

pentium-libcはスナップをインストールするためには要求されません。

3.7 pgccをコンパイルするために何か他に必要ですか?

gperf(GNU完全ハッシュ・ジェネレータ)、autoconf、bisonおよびflex。これらはすべて任意のGNUミラーから利用可能です。最新版(スナップのために必要とするかもしれません)はhttp://egcs.cygnus.com/pub/egcs/infrastructure/で見つけることができます。

ftp://ftp.yggdrasil.com/provate/hjl/ からlibc-5.4.43(また他のバージョン)を入手することができます。

4 最適化
　

4.1 最適な性能のためにどのコンパイラ・スイッチを使用する必要がありますか。

pentium最適化を得るために-mpentiumを使用し、pentiumproとpentium-iiの-mpentiumproを使用し、amdk6のために-mk6(スナップ)または-mamdk6(リリース)を使用します。コードは全てのプロセッサ上で走るでしょう。 i486のために最適化されたバージョンを得るために-m486M/KBD>を使用できますが、保証はありません。それは、i486の上のgccより速いかもしれません。追加のppro命令を利用したい場合、-match=pentiumproを加えますが、しかし、生成されるバイナリは、より古いcpusの上で(必ず)走りません! -O6は、私たちが安全であると思う最適化をすべて含んでいます。性能をもっと増すかもしれないループアンローリング(-funroll-loopsあるいは-funroll-all-loops)を試みるかもしれません。さらにfpu集約的なプログラムに関する質問を参照してください。

4.2 最小コード・サイズのためにどのコンパイラ・スイッチを使用する必要がありますか。

-O -Osの組み合わせは通常最小のバイナリを生成するでしょう。さらに比較のために-O2 -Osを試みるかもしれません。例外を使用しなければ、コード・サイズをさらに縮小するために-fno-exceptionsを加えることができます(新しいbinutilsは例外テーブルを圧縮するでしょう、その結果さらにあまり重要でないだろう、gdbがフレームポインタのないコードのデバッグのために結局例外テーブル情報を使用するだろうと予想します)。

C++プログラムでは、さらにプログラム中で実行時型情報を使用しない-fno-rttiを試みるかもしれません。

4.3 改良はどれだけですか

速度改良は2%から30%(まれ)まで変動します。しかし、それらのうちの多くが不安定なので、現在のコンパイラはデフォルトですべての最適化を有効にするとは限りません。私がコンパイルするすべての時間を計るとは限りません。通常は、全てのプログラム上の-O3で約5%(少なくとも)を得ることができます(全ての時間は標準のGNU ccと比較されました)。

GZIP-1.24は展開が20%-35%より速いです。

もちろん、マイル数は変わるかもしれません。しかし、標準のGNU cc以上の速度改良を常に得るはずです。

4.4 プログラムはpentium-gccによってなぜより小さくではなく、より大きくなりますか。

x86アーキテクチャには多くの特殊目的命令(lodsのような)があります。新しいCPU(pentium以上)では、これらの特殊命令の使用は非常に高い実行時ペナルティを伴います。したがって、通常速度に最適化されたコードは最適化されていないコードより大きなコードを意味します。新しいpgcc/egcsコンパイラにコード・サイズのために最適化するオプション、すなわち-Osがあります。このスイッチはやや新しく、より小さなコードを必ずしも生成するとは限らないかもしれません。そのサポートは進行中です(この質問を参照)。

4.5 どれくらい安定していますか。

すべては-O6でコンパイルすることができるはずです。

生成コードはめったに壊れませんが、何かが誤る場合、-O2スイッチで試みてください。 -O2は、すべての場合に正確なコードを生成するはずです。私のすべてのバイナリ(カーネルを含んで)の約99%は-O6スイッチでコンパイルされます。

信頼性の低いことが知られている最適化は、どの-Oxステートメントによっても有効になりません、手でそれらを有効にしなければなりません。

4.6 いくつかの比較を行っていますか。

P133、64MBのRAMおよびLinux 2.0.2の上でRobert Loganによって比較しました。示されたすべての時間は秒です。カーネルは-O3およびpgcc-960511(かなり古い)でコンパイルされました。

使用されるプログラムは「cjpeg」および「djpeg」のための標準のjpeg-6配布でした。変換されたPCDはhpcdtoppm.0.6です。ノーマルは標準の2.7.2 GCCで、次の2つが最適化されたgccの風味であるということです。驚くべきものはPCDのpostcriptへの変換です。カラーは16%よい。しかし、白黒は50%です! テストはすべて10回以上の実行の平均です。

ノーマル	gcc-p-p18-O6	pgcc-960511-O6	説明
17.64	15.30	15.02	標準のcjpeg xx.gif(4メガ GIFファイル)
17.01	14.80	14.95	-dct float (FPテスト)
9.39	8.64	8.03	xx.jpgのdjpeg
24.32	11.68	12.45	PCDイメージ(2048x3072)を白黒postscriptに変換
42.92	35.36	35.53	同じPCDをカラーpostscriptに

4.7 pgccはどんな最適化を実装していますか?

テーブル・ヘッダー

スイッチ	最適化を有効／無効にするために使用するコンパイラ・スイッチ。 `reduce-all-givs`がスイッチの場合、`-freduce-all-givs`で有効になり、`-fno-reduce-all-givs`で無効になります。
O	デフォルトでスイッチを有効にする標準の最適化レベル。例えば、3は`-O3`、`-O4`、それ以上にこの最適化が含まれ、`-O2`に含まれないことを意味します。 -は `-O`レベルではこの最適化が有効にならないので、手動で指定しなければならないことを意味します。
S	この最適化の「安定性」。次うちの1つ: S 安定。このオプションは安定していて、間違っているコードを生成しないでしょう。 U 不安定。 Dほど問題はありませんが、なお、それに関するいくつかの既知の問題があります。 D 無効。このオプションは無効です(つまり、-foption形式を明示的に使用することによって有効になるはずです)。通常は、これは、最適化に関する問題を示します。自分のリスクで使用してください ;) R このオプションは性能を遅くするかもしれません。したがって、デフォルトでオフです。
説明	最適化の短い説明を与えます。何か加えたいか、質問があれば私に伝えてください...

スイッチ	O	S	説明
move-all-movables	-	S	g77から得られ、Fortranコードは改善されるかもしれませんが、CやC++のコードをめったに改善しません。
reduce-all-givs	-	S	g77から得られ、Fortranコードは改善されるかもしれませんが、CやC++のコードをめったに改善しません。
rerun-loop-opt	-	S	g77から得られ、Fortranコードは改善されるかもしれませんが、CやC++のコードをめったに改善しません。
opt-reg-use	1	S	メモリ・アドレス用レジスタの使用法を最適化します。
reduce-index-givs	1	S	縮小可能なメモリgivsとしてアドレスのインデックス用語を扱おうと努めます。
inline-functions	3	S	gccのドキュメントを参照してください。
jump-back	3	S	ループの最適化中で、最適化機会を無効にしないように後方ジャンプを扱います。
copy-prop	3	S	ループ・コピー伝播
compare-elim	3	S	比較を除去します。
software-pipe	3	S	スタックレジスタ上でミニソフトウェアパイプラインを行います。
reg-reg-copy-opt	3	S	再ロードの後に、レジスタが別のレジスタへのコピーで死んだとマークされるかどうか - コピーを除去して、そのために他のレジスタを最初の場所で使用できるかどうか確かめる。
opt-reg-stack	3	D	スタックからのスタックレジスタの使用法を最適化します。
loop-after-global	3	D	再ロードの後に、ループ中の流出スロットの使用法を最適化しようと努めます。
peep-spills	3	U	再ロードの後に、流出スロットを等価レジスタで交換しようと努めます。
replace-stack-mem	3	S	ループ最適化の第1のパス中で、メモリ・オペランドを等価なスタックレジスタで交換しようと努めます。
opt-jumps-out	3	S	jumps taken to jumps not taken 積極的に変更しようと努めます。
replace-mem	3	S	ループ最適化の第1のパス中で、メモリ・オペランドを等価なレジスタに取り替えようと努めます。
correct-cse-mistakes	3	S	cseは時々不利益です。
push-load-into-loop	3	S	ロードしたレジスタがこぼされた場合ループへロードを押し上げようと努めます。
replace-reload-regs	3	S	再ロードされるメモリ・オペランドが同じレジスタへ再ロードされるように利用可能なレジスタを使用しようと努めます。これはloop-after-globalを助けます。
sign-extensions-elim	3	S	符号拡張除去
lift-stores	3	S	ループの持続時間のためにループ中にレジスタへ格納されるメモリ明瞭、メモリオペランドを上げようと努めます。
combine-222	4	D	2つの命令に2つの命令を組み合わせることは時々利益があるかもしれません。
schedule-insns2	4	S	gccのドキュメントを参照してください。
swap-for-agi	4	S	1番目が定数によってレジスタをインクリメントし、第2がベースとしてそのレジスタを使用する場合に2つの命令を交換しようとスケジューラが努めることを可能にします。
risc	4	S	再ロードの後に、利用可能なレジスタにメモリ・オペランドをロードし、メモリ・オペランドの代わりにレジスタを使用します。
risc-const	4	S	再ロードの後に、利用可能なレジスタにCONST_INTsをロードし、その後CONST_INTの代わりにレジスタをストアします。
recombine	4	R	スケジューリング中にその場でriscifiedされた命令が変更していない場合、cisc命令へ再結合します。
interlave-stack-non-stack	4	S	参照スタックレジスタをinsnsの間で再整理するスケジューラおよびしないもの、だがそれら自身の中のではない第1のパスを使用します。
schedule-stack-reg-insns	4	S	insnsの間でその参照スタックレジスタを再整理するためにスケジューラの第1のパスを使用します。
runtime-lift-stores	5	S	リフトストアとして、しかし実行時に明瞭を改善する、つまり、一つは明瞭で一つはそうでないループの2つのコピーがあり、どちらを実行するかを実行時に決定します。
omit-frame-pointer	5	U	gccのドキュメントを参照してください。
schedule-insns	5	R	gccのドキュメントを参照してください。
all-mem-givs	6	S	メモリ・アドレスgivsをすべて縮小します。
do-offload	6	S	均等のために離れて比較されるレジスタを積み重ねる、比較の前のスタックスタックレジスタを移動する
risc-mem-dest	6	S	riscifyedされた目的地はその方法を止めるはずです。

4.8 特別のスイッチが必要ですか。

-fno-rtti
g++は実行時型情報をサポートします。リンクの問題を得れば、C++の最近の特徴(その中のrttiを備えた名前に関する不確定のシンボルは、この特徴を無効にする-fno-rttiおよびリンカエラーを試みます)。二者択一で、実際に最近のlibg++を得ることができるが知りません、どのバージョン(恐らく、そのlibgバージョンは、公にさえリリースされません)

-Wno-sign-compare
-Wallは(だいたいss-960511から)Linusを悩ました新しい警告-Wsign-compareを含んでいます。 gcc2開発者リスト上で最近の戦争がありました、しかしその警告は、たぶんより長くgccにとどまります。正しく実行できるプログラム中で、符号付き比較に関する多くの警告を得る場合、"-Wall -Wno-sign-compare"を使用します(注:-Wallは -Wno-sign-compareの前にある必要があります)

4.9 fpu集約的なプログラムのためのコツがありますか。

はい.. 新しいcpu(ペンティアム以上)は、doubleの変数のメモリ整列に非常に敏感です。不運にも、x86 ABI(アプリケーション・バイナリ・インターフェイス)は、4バイトの整列を指定します。しかし、8バイトが最適でしょう。したがって、整列が最適かどうかは、単に運の問題です。

今スイッチを得ましょう:

-malign-double
このスイッチは、構造体中のdoubleを8バイト境界へ整列させます。これはある意味ではABIを壊します。(それらが新しい整列を知らなければならないので)いくつかのライブラリを再コンパイルしなければならないことを要求するかもしれません。 libjpeg v6は顕著な例です。

-mstack-align-double
このスイッチは、スタック(つまりCの中の自動変数)上のdoubleを8バイト境界へ整列させようと努めます。 pgccは、スタック・ポインタが手続きエントリで既に整列すると予期します。 Linux、glibc2およびlibc.5.4.22以上の下ではプログラム・スタートでこれを行います。古いlibcを持っていればアップグレードすべきです。これはABIを壊さないので、安全なはずです。

-marg-align-double
これは、他の関数へのパラメータとして使用されるdoubleを8バイト境界へ整列させるでしょう。 厳しくABIを壊すでしょう。 gcc/egcsの中のバグにより、このオプションは現在動作しません(amd上のもの以外は)。

-funroll-all-loops
このオプションは、一般に用いられているコードだが、特にfpu集約的なループを高速化を一般に支援します。これは不可欠です。ループを広げることがgcc/egcs/pgccのより劣った信頼できる部分のうちの1つであることに注意してください;

5 トラブルシュート
　

5.1 完全に素晴らしいプログラムでなぜ何百ものエラーが出ますか。

このような過度のエラーが出る場合

pgcc-2.90.21/include/stdarg.h:41: parse error
pgcc-2.90.21/include/stdarg.h:0: numeric constant with no digits
pgcc-2.90.21/include/stdarg.h:0: warning: unrecognized text at end
pgcc-2.90.21/include/stdarg.h:69: parse error at null character

システム上にlibc5の古いバージョンがインストールされています。少なくともlibc-5.4.22(5.4.43以上を推薦します)を必要とします。 glibcを使用していれば、恐らくpgccのlibc5バージョンをインストールしました(glibcでとにかく動作しないでしょう)。

5.2 pgccでコンパイルした時、私のlinuxカーネル2.0.xは適切に動作しません。答えに関しては、この質問を参照します。

5.3 SIGSEV(シグナル11)をなぜ得続けますか。

pgccで何かコンパイルしている時に偽のSIGSEGV(シグナル11)シグナルを得て、コンパイルを再開するとき去る場合、pgccの問題ではなくハードウェアに関する問題です(つまりオーバークロック、遅いドラムなど)。 http://www.bitwizard.nl/sig11/ でsig11 faqを参照してください。

同じファイルをコンパイルする時にいつもSIGSEGV(シグナル11)を得れば、つまりpgccが一貫して失敗すれば、pgccの中のバグを打ちました。 Marc Lehmann <pcg@goof.com> に報告してください。

インデックス・ページに戻る

PentiumGCC FAQ

バージョン2.6.0

テーブル・ヘッダー

問題? 私たちがどうそれらを解決できるか確かめるために このページ を見てください。

問題? 私たちがどうそれらを解決できるか確かめるためにこのページを見てください。