GCC(1) GNU Tools GCC(1)
gcc, g++ - GNU プロジェクト C および C++ コンパイラ (gcc-2.95.3)
gcc [ option | filename ]...
このマニュアルに書かれた情報は GNU C コンパイラの完全な ド-
ュメンテーションからの抜粋であり、オプションの意味の欺劼砲箸匹瓩泙后
このマニュアルはボランティアのメンテナンスが行なわれた時にのみ更新され
るもので、常に最新の情報を示しているわけではありません。
もしこのマニュアルと実際のソフトウェアの間に矛盾点があれば、 正式なド-
ュメントである Info ファイルのほうを参照して下さい。
このマニュアル中の古い欺劼重大な混乱や不具合をい燭垢海箸砲覆譴弌
このマニュアルページの配布は中止します。 GNU
CCのメンテナンス作業の都合上、 Info
ファイルを更新した時にマニュアルページも併せて更新することは で-
ません。マニュアルページは時代遅れであり、 これに時間をかけるべ-
ではないと GNU プロジェクトでは考えています。
完全な最新のドゥ絅瓮鵐董璽轡腑鵑必要な場合は、Info ファイルの`gcc'
またはマニュアルの Using and Porting GNU CC (for version 2.0)
を参照して下さい。この双方は Texinfo のソースファイル gcc.texinfo
から生成されます。
C と C++ のコンパイラは統合されています。どちらの場合も、入力ファイル
は、プリプロセス、コンパイル、アセンブル、リンクの 4 つの処理ステージの
うちの 1 つ以上のステージを踏んで処理されます。
ソースファイル名の拡張子によってソースの言語を識別しますが、
デフォルトの動作は、どちらの名前でコンパイラを使うかに依存しています:
gcc プリプロセス済みの (.i) ファイルを C のファイルと仮定し、C
スタイルのリンクを行います。
g++ プリプロセス済みの(.i) ファイルを C++ のファイルと仮定し、C++
スタイルのリンクを行います。
ソースファイル名の拡張子は、その言語が何であるかと、どのような処理が行われる
べいを示します:
.c C言語ソースです。プリプロセッサ、コンパイラ、アセンブラにかけられます。
.C C++言語ソースです。プリプロセッサ、コンパイラ、アセンブラにかけられます。
.cc C++言語ソースです。プリプロセッサ、コンパイラ、アセンブラにかけられます。
.cxx C++言語ソースです。プリプロセッサ、コンパイラ、アセンブラにかけられます。
.m Objective-C 言語ソースです。プリプロセッサ、コンパイラ、アセンブラにかけられます。
.i プリプロセッサにかけられたC言語ソースです。コンパイラ、アセンブラにかけられます。
.ii プリプロセッサにかけられたC++言語ソースです。コンパイラ、アセンブラにかけられます。
.s アセンブリ言語ソースです。アセンブラにかけられます。
.S アセンブリ言語ソースです。プリプロセッサ、アセンブラにかけられます。
.h プリプロセッサファイルです。通常はコマンドラインには現れません。
その他の拡張子を持つファイルはリンカに渡されます。以下のものがあります。
.o オブジェクトファイルです。
.a アーカイブファイルです。
リンクは、オプション -c, -S, -E
を指定して抑制しないかぎり(もしくはコンパイルエラーによってすべての処理が中断
しないかぎり)、常に最終ステージで実行されます。
リンクのステージにおいては、ソースファイルに対応した全ての .o
ファイルと、 -l で指定したライブラリと、認識されなかったファイル名
(名前に .o のついたオブジェクトファイルや .a のついたアーカイブを含む)
は、 コマンドラインに並べられた順番でリンカに渡されます。
オプションは分割されていなければなりません。すなわち `-dr' は `-d -r
'とは異なった扱いを受けます。
ほとんどの `-f' と `-W' 形式のオプションには、 -fname と -fno-name
(または -Wname と -Wno-name)
の形式の、対照的な表現があります。ここではデフォルトでない形式の
みを示します。
すべてのオプションを種類別に分けてまとめました。詳しい解説は
以下の節で行ないます。
-pthread
スレッド化ユーザプロセスに libc の代りに libc_r をリンクします。
スレッド化ユーザプロセスにリンクされるオブジェクトは
-D_THREAD_SAFE 付い コンパイルする必要があります。
-kthread
スレッド化カーネルプロセスに libc に加えて libpthread
をリンクします。
スレッド化カーネルプロセスにリンクされるオブジェクトは
-D_THREAD_SAFE 付い コンパイルする必要があります。
全澗体療的な淵オプ廛シ轡ョ腑ン
-c -S -E -o file -pipe -v -x language
言生語譽オプ廛シ轡ョ腑ン
-ansi -fall-virtual -fcond-mismatch -fdollars-in-identifiers
-fenum-int-equiv -fexternal-templates -fno-asm -fno-builtin
-fhosted -fno-hosted -ffreestanding -fno-freestanding
-fno-strict-prototype -fsigned-bitfields -fsigned-char
-fthis-is-variable -funsigned-bitfields -funsigned-char
-fwritable-strings -traditional -traditional-cpp -trigraphs
警拗告陬オプ廛シ轡ョ腑ン
-fsyntax-only -pedantic -pedantic-errors -w -W -Wall
-Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscript
-Wcomment -Wconversion -Wenum-clash -Werror -Wformat
-Wid-clash-len -Wimplicit -Wimplicit-int
-Wimplicit-function-declaration -Winline -Wlong-long -Wmain
-Wmissing-prototypes -Wmissing-declarations -Wnested-externs
-Wno-import -Wparentheses -Wpointer-arith -Wredundant-decls
-Wreturn-type -Wshadow -Wstrict-prototypes -Wswitch
-Wtemplate-debugging -Wtraditional -Wtrigraphs -Wuninitialized
-Wunused -Wwrite-strings
デ妊バ丱ッ奪グ哀オプ廛シ轡ョ腑ン
-a -dletters -fpretend-float -g -glevel -gcoff -gxcoff -gxcoff+
-gdwarf -gdwarf+ -gstabs -gstabs+ -ggdb -p -pg -save-temps
-print-file-name=library -print-libgcc-file-name
最播適化愁オプ廛シ轡ョ腑ン
-fcaller-saves -fcse-follow-jumps -fcse-skip-blocks
-fdelayed-branch -felide-constructors -fexpensive-optimizations
-ffast-math -ffloat-store -fforce-addr -fforce-mem
-finline-functions -fkeep-inline-functions -fmemoize-lookups
-fno-default-inline -fno-defer-pop -fno-function-cse -fno-inline
-fno-peephole -fomit-frame-pointer -frerun-cse-after-loop
-fschedule-insns -fschedule-insns2 -fstrength-reduce
-fthread-jumps -funroll-all-loops -funroll-loops -O -O2 -O3 -O0
-Os
プ廛リ螢プ廛ロ蹈セ札ッ奪サ汽オプ廛シ轡ョ腑ン
-Aassertion -C -dD -dM -dN -Dmacro[=defn] -E -H -idirafter dir
-include file -imacros file -iprefix file -iwithprefix dir -M
-MD -MM -MMD -nostdinc -P -Umacro -undef
ア▲セ札ン鵐ブ屮ラ薀オプ廛シ轡ョ腑ン
-Wa,option
リ螢ン鵐カオプ廛シ轡ョ腑ン
-llibrary -nostartfiles -nostdlib -static -shared -symbolic
-Xlinker option -Wl,option -u symbol
デ妊ィレ譽クト肇リ螢オプ廛シ轡ョ腑ン
-Bprefix -Idir -I- -Ldir
タ拭ー璽ゲ殴ッ奪ト肇オプ廛シ轡ョ腑ン
-b machine -V version
コ灰ン鵐フ侫ィギュ絅レ譟ー璽シ轡ョ腑ン鶲依預存献オプ廛シ轡ョ腑ン
M680x0
-m68000 -m68020 -m68020-40 -m68030 -m68040 -m68881 -mbitfield
-mc68000 -mc68020 -mfpa -mnobitfield -mrtd -mshort -msoft-float
VAX
-mg -mgnu -munix
SPARC
-mepilogue -mfpu -mhard-float -mno-fpu -mno-epilogue
-msoft-float -msparclite -mv8 -msupersparc -mcypress
Convex
-margcount -mc1 -mc2 -mnoargcount
AMD29K
-m29000 -m29050 -mbw -mdw -mkernel-registers -mlarge -mnbw
-mnodw -msmall -mstack-check -muser-registers
M88K
-m88000 -m88100 -m88110 -mbig-pic -mcheck-zero-division
-mhandle-large-shift -midentify-revision
-mno-check-zero-division -mno-ocs-debug-info
-mno-ocs-frame-position -mno-optimize-arg-area
-mno-serialize-volatile -mno-underscores -mocs-debug-info
-mocs-frame-position -moptimize-arg-area -mserialize-volatile
-mshort-data-num -msvr3 -msvr4 -mtrap-large-shift
-muse-div-instruction -mversion-03.00 -mwarn-passed-structs
RS6000
-mfp-in-toc -mno-fop-in-toc
RT
-mcall-lib-mul -mfp-arg-in-fpregs -mfp-arg-in-gregs
-mfull-fp-blocks -mhc-struct-return -min-line-mul
-mminimum-fp-blocks -mnohc-struct-return
MIPS
-mcpu=cpu type -mips2 -mips3 -mint64 -mlong64 -mlonglong128
-mmips-as -mgas -mrnames -mno-rnames -mgpopt -mno-gpopt -mstats
-mno-stats -mmemcpy -mno-memcpy -mno-mips-tfile -mmips-tfile
-msoft-float -mhard-float -mabicalls -mno-abicalls -mhalf-pic
-mno-half-pic -G num -nocpp
i386
-m386 -m486 -mpentium -mpentiumpro -mno-486 -mcpu=cpu type
-march=cpu type -msoft-float -mrtd -mregparm -msvr3-shlib
-mno-ieee-fp -mno-fp-ret-in-387 -mfancy-math-387
-mno-wide-multiply -mdebug-addr -mno-move -mprofiler-epilogue
-reg-alloc=LIST
HPPA
-mpa-risc-1-0 -mpa-risc-1-1 -mkernel -mshared-libs
-mno-shared-libs -mlong-calls -mdisable-fpregs
-mdisable-indexing -mtrailing-colon
i960
-mcpu-type -mnumerics -msoft-float -mleaf-procedures
-mno-leaf-procedures -mtail-call -mno-tail-call -mcomplex-addr
-mno-complex-addr -mcode-align -mno-code-align -mic-compat
-mic2.0-compat -mic3.0-compat -masm-compat -mintel-asm
-mstrict-align -mno-strict-align -mold-align -mno-old-align
DEC Alpha
-mfp-regs -mno-fp-regs -mno-soft-float -msoft-float
System V
-G -Qy -Qn -YP,paths -Ym,dir
コ魁ー璽ド廟生言成オプ廛シ轡ョ腑ン
-fcall-saved-reg -fcall-used-reg -ffixed-reg
-finhibit-size-directive -fnonnull-objects -fno-common
-fno-ident -fno-gnu-linker -fpcc-struct-return -fpic -fPIC
-freg-struct-return -fshared-data -fshort-enums -fshort-double
-fvolatile -fvolatile-global -fverbose-asm
-x language
このオプションに続く入力ファイルの言語を language
であると明示的に指定します
(拡張子に基づくデフォルトの選択よりも優先されます)。このオプションは、
次の `-x'
オプションが出てくるまで、後続する全ての入力ファイルに対して
適用されます。language としては、 `c', `objective-c', `c-head-
er', `c++', `cpp-output', `assembler', `assembler-with-cpp'
を指定することが可能です。
-x none
言語の指定を解除します。このオプションのあとに続くファイルは、それらの拡張子に
基づいて (あたかも何の `-x'
オプションも使用されたことがないように) 処理されます。
もし、4 つのステージ (プリプロセス、コンパイル、アセンブル、リンク) の
うちの一部のみが必要な場合は、 `-x' オプション
(またはファイル名の拡張子) を使用して gcc
に対してどのステージから開始するかを伝え、さらに `-c', `-S', `-E'
のオプションのうちのどれかを使用して gcc
に対してどこで処理を停止させるかを指定します。ここで、
いくつかの組み合わせ (例えば `-x cpp-output -E') は gcc
に対して何の動作も行なわないように指定することになることに注意してください。
-c ソースファイルを、コンパイルまたはアセンブルまではしますが、リンクはしません。
コンパイラの出力は、それぞれのソースファイルに対応したオブジェクトファイル
となります。
デフォルトでは、GCC はオブジェクトファイルのファイル名として、
ソースファイルの拡張子 `.c', `.i', `.s' 等を `.o' で置-
換えたものを使用します。 -o
オプションを使用することによって、他の名前を指定することも可能です。
GCC は -c オプションを使用した場合は、理解でい覆て力ファイル
(コンパイルやアセンブル を必要としないファイル) を無視します。
-S コンパイルが終った所で処理を停止し、アセンブルは行いません。
アセンブラコードではない入力ファイルが指
定された場合は、出力はアセンブラコードのファイルになります。
デフォルトでは、GCC はアセンブラファイルのファイル名として、
ソースファイルの拡張子 `.c', `.i' 等を `.s' で置-
換えたものを使用します。 -o
オプションを使用することによって、他の名前を指定することも可能です。
GCC はコンパイルを必要としない入力ファイルを全て無視します。
-E プリプロセス処理が終了したところで停止します。コンパイルはしません。
出力はプリプロセス済みのソースコードであり、標準出力へと送られます。
GCC はプリプロセスを必要としない入力ファイルを全て無視します。
-o file
出力先を file に指定します。このオプションは GCC
が実行可能ファイル、
オブジェクトファイル、アセンブラファイル、プリプロセス済み C
コードなどの、 いかなる種類の出力を行なう場合にも適用可能です。
出力ファイルは 1 つしか指定でい覆い燭瓠 `-o'
を複数の入力ファイルをコンパイルする際に使用することは、実行ファ
イルを出力する時以外は無意味です。
`-o'オプションを指定しなかった場合のデフォルトは、実行ファイルを作る場
合は `a.out' という名前であり、`source.suffix'
の形式のファイル名を持ったソースファイルのオブジェクトファイルは
`source.o' であり、アセンブラのファイルは `source.s' です。
プリプロセス済みの C 言語は、全て標準出力に送られます。
-v (標準エラー出力に対して)
コンパイルの各ステージで実行されるコマンドを
表示します。コンパイラドライバ、プリプロセッサおよび本来のコンパイラの
各バージョン番号も表示します。
-pipe コンパイル時のステージの間のデータの受け渡しに、テンポラリファイルではなく
パイプを使用します。いくつかのシステムではアセンブラがパイプからの入力を受け
付けることがで-
ないために、このオプションを指定すると失敗します。 GNU
アセンブラでは問題なく使用でい泙后
以下のオプションは、コンパイラが受け付ける C
の方言に関する制御を行ないます:
-ansi 全ての ANSI 標準の C プログラムをサポートします。
このオプションは、GNU C が持つ ANSI C
との非互換な機能を全て排除します。 例えば、asm, inline, typeof
などのァ璽錙璽匹筺unix や vax
などの現在使用しているシステムを規定する定義済みマクロなどが抑制されます。
さらに、好ましくなくかつほとんど使用されない ANSI
のトライグラフの機能を使 用可能とし、さらに `$'
を識別子の一部として使用でい覆い茲Δ砲靴泙后
代替ァ璽錙璽匹任△__asm__, __extension__, __inline__, __type-
of__ は、 `-ansi'
が指定された場合でも使用することが可能です。もちろん、 これらを
ANSI C
プログラムで使用することが望ましくないのは当然ですが、`-ansi'
をつけてコンパイルされる場合でも、インクルードされるヘッダファイル中に
これらが欺劼任るということは様僂任后 __unix__ や __vax__
などの代替定義済みマクロは、 `-ansi'
を指定する場合でも指定しない場合でも、利用可能となっています。
`-ansi' オプションは、ANSI
準拠でないプログラムを不必要に拒否することは
ありません。もしこのような動作を行なわせたい場合には`-an-
si'に加えて-pedantic' オプションを指定する必要があります。
プリプロセッサ定義済みマクロ __STRICT_ANSI__ が `-ansi'
オプションを使用した際には定義されます。いくつかのヘッダファイルは、この
マクロを識別して、ANSI
標準が望まない関数やマクロの定義を抑制します。 これは、
それらの関数やマクロと同じ名前を別の目的で使用するプログラム
を混乱させないようにするためです。
-fno-asm
asm, inline, typeof をァ璽錙璽匹箸靴堂鮗瓩靴泙擦鵝
これらの単語は識別子として解釈されるようになります。これらの代用として
__asm__, __inline__, __typeof__ が使用でい泙后 `-ansi'
を指定すると、暗黙のうちに `-fno-asm'
を指定したものとみなされます。
-fno-builtin
ビルトイン関数のうち、2
つのアンダースコアで始まるもの以外を認識しなくなり
ます。現在、この指定は_exit, abort, abs, alloca, cos, exit,
fabs, labs, memcmp, memcpy, sin, sqrt, strcmp, strcpy, strlen
の関数に影響を及ぼします。
`-ansi' オプションを指定すると、alloca と _exit
はビルトイン関数として扱われなくなります。
-fhosted
ホスト実行環 (hosted environment) 用にコンパイルを行います。
これにより、`-fbuiltin' オプションが邑になり、また、不審な main
宣言に対して警告を発するようになります。
-ffreestanding
フリースタンディング実行環 (freestanding environment) 用に
コンパイルを行います。 これにより、`-fno-builtin' オプションが-
効になり、また、 main に特別な条件は不要とみなします。
-fno-strict-prototype
`int foo ();' のような、引数を指定しない関数宣言を、C
言語のように引数の数や
型について何の仮定もしないという扱いにします (C++
のみ)。通常はこのよう な宣言は、C++ では foo という関数が 1
つも引数をとらないことを意味します。
-trigraphs
ANSI C のトライグラフを使用可能とします。`-ansi'
オプションを指定すると、暗黙のうちに `-trigraphs'
を指定したものとみなされます。
-traditional
伝統的な C コンパイラのいくつかの特徴をサポートします。詳しくは
GNU C の
マニュアルを参照してください。以前はここにそのリストの複製を載せていましたが、
それらが完全に時代遅れになった時に我々に文句が来ないように削除してしまいま
した。
しかし、C++ のプログラムだけについて (C ではありません) 特-
しておくこと が 1 つあります。 `-traditional' オプションは C++
に対して 1 つだけ特別な効果を持ちます。それは、 this
への代入を許可するというものです。これは `-fthis-is-vari-
able'オプションの指定が及ぼす効果と同一のものです。
-traditional-cpp
伝統的な C
プリプロセッサのいくつかの特徴をサポートします。これは上に挙
げた中で特にプリプロセッサに関係したものを含みますが、 `-tradi-
tional' の指定によって引-
起こされる以外の効果を及ぼすことはありません。
-fdollars-in-identifiers
識別子中の `$' の使用を許可します (C++ のみ)。 `-fno-dol-
lars-in-identifiers' を使用することによって、明示的に
`$'の使用を禁止することも可能です。(GNU C++ では、デフォルトで
`$' を許可しているシステムと禁止しているシステムがあります)。
-fenum-int-equiv
int から列挙型への暗黙の変換を許可します (C++ のみ)。通常は GNU
C++ は enum から int への変換は許可していますが、
逆は許していません。
-fexternal-templates
テンプレート関数について、その関数が定義された場所にのみ単一のコピー
を生成することによって、テンプレート宣言に対してより小さなコードを生成
します (C++
のみ)。このオプションを使用して正しいコードを得るためには、
テンプレートを使用する全てのファイルにおいて、`#pragma implemen-
tation' (定義) または `#pragma interface' (宣言) を-
述しておく必要があります。
`-fexternal-templates'
を指定してコンパイルを行なう場合には、全てのテンプレートの
実体は external
となります。全ての使用される実体はインプリメンテーション
ファイル中にまとめて-
述しておかなければなりません。これはその必要とされ
る実体に対応した typedef 宣言を行なうことによって実現でい泙后
逆に、デフォルトのオプション `-fno-external-templates'
でコンパイルした場合には全てのテンプレートの実体は internal と
なります。
-fall-virtual
可能な限り全てのメンバ関数を暗黙のうちに仮想関数として扱います。
全てのメンバ関数 (コンストラクタと new , delete
メンバ演算子を除い泙)
は、出現した時点でそのクラスの仮想関数とし て扱われます。
これは、これらのメンバ関数への全ての呼び出しが仮想関数のための内部
テーブルを参照して間接的に決定されるということを意味しません。特定の状況
においては、コンパイラは与えられた仮想関数への呼び出しを直接決定で-
ます。
このような場合にはその関数呼び出しは常に直接呼び出しとなります。
-fcond-mismatch
条件演算子の第 2, 第 3 引数の型が異なる-
述を許します。このような式の型は void となります。
-fthis-is-variable
this への代入を許可します (C++ のみ)。ユーザ定義による-
憶管理が可 能となった現在では、 `this'
への代入は時代遅れのものとなりました。従ってデフォルトでは、クラスの
メンバ関数からの this
への代入は不当なものとして扱われています。しかし、後方互換-
のために、 `-fthis-is-variable'
を指定することによってこの効果を得ることがでい泙后
-funsigned-char
char 型を unsigned char のように符号無しとして扱います。
それぞれのマシンには char がどちらであるべ-
かというデフォルトがあります。 デフォルトで unsigned char
であることもあれば、デフォルトで signed char
であることもあります。
理想的には、可搬世里△襯廛蹈哀薀爐蓮▲ブジェクトの符号の楊気飽
存する欺劼鮃圓覆場合には常に signed char、もしくは unsigned
char を使用すべい任后 しかし実際には多くのプログラムが単なる
char を用いて欺劼気譴討り、さらにそのプログラムを欺劼靴 環-
に依存して、符号付-
である、あるいは符号無しであるという暗黙の仮定が
行なわれています。このオプション、あるいはこの逆のオプションは、デフォル
トと逆の動作を行なわせることにより、これらのプログラムを正しく動作させ
ることを可能にします。
char 型は常に signed char あるいは unsigned char
とは区別された型として扱われます。常にそれらの振舞いがそのどち
らかと全く同じであるということに関わらず、このような扱いを行います。
-fsigned-char
char 型を signed char 型のように符号付い箸靴動靴い泙后
ただし、このオプションは `-fno-unsigned-char' と等価です。これは
`-funsigned-char'の否定形です。同様に `-fno-signed-char' は
`-funsigned-char' と等価です。
-fsigned-bitfields
-funsigned-bitfields
-fno-signed-bitfields
-fno-unsigned-bitfields
これらのオプションは、明示的に `signed' または `unsigned'
の指定が行なわれていないビットフィールドに対して、符号つ-
であるかある
いは符号なしであるかを制御します。デフォルトではこのようなビットフィール
ドは符号つい箸覆辰討い泙后なぜなら、 int
のような基本的な型は符号つい任△襪箸いε世如∪姐臉-
がとれるからです。
ただし、`-traditional'
を指定した場合は、ビットフィールドは常に全て符号無しであるとされます。
-fwritable-strings
文字列定数を書-
込み可能なデータセグメントに配置し、同内容の文字列を 1 つの共-
オブジェクトにする処理を行いません。これは、文字定数に書すむ
ことがでい襪海箸魏渉蠅靴神里離廛蹈哀薀爐箸慮澳浩-
をとるために提供され ています。`-traditional'
オプションも同様の効果を含みます。
文字定数に書すむという考えは非常によくない考えです。"定数"
はまさに定数であり、変化すべい任呂△蠅泙擦鵝
これらのオプションは C プリプロセッサを制御します。 各 C
ソースファイルは、実際にコンパイルする前に、C プリプロセッサに
かけられます。
`-E' オプションを使用すると、GCC はプリプロセス以外の処理を行いません。
以下に示すオプションのうちのいくつかは、`-E'
と同時に使用された時のみ意味をもちます。なぜならば、これらのオプション
によって、実際のコンパイルには不適当なプリプロセッサ出力が生成されるためです。
-include file
file を、通常の入力ファイルが処理される前に処理します。結果的に
file
に含まれる内容は、一番最初にコンパイルされることになります。コマンドラ
インに指定されたすべての `-D' や `-U' オプションは、その-
述された順番に関わらず常に `-include file'
が処理される前に処理されます。全ての `-include' や `-imacros'
オプションは、それらが欺劼気譴申臠崢未蠅暴萢されます。
-imacros file
通常の入力ファイルを処理する前にfile
を入力として処理しますが、その結果の出力を捨てます。 file
によって生成された出力は捨てられるため、`-imacros file'
の処理結果の影響は、file 中に-
述されたマクロがメインの入力ファイル中で使用可能になることだけです。
プリプロセッサは、`-imacros file' が-
述された順番に関わらず、これを処理する前に、
コマンドラインから与えられた全ての `-D' や `-U'
オプションを評価します。全ての `-include' および `-imacros'
オプションは、それらが欺劼気譴申臠崢未蠅暴萢されます。
-idirafter dir
ディレクトリ dir を第 2 インクルードパスに加えます。第 2
インクルードパス中のディレクトリは、 メインインクルードパス
(オプション `-I' によって追加されます)
中にヘッダファイルを探した結果発見でい
かった場合に検索されます。
-iprefix prefix
prefix を、その後に続く `-iwithprefix'
オプション用のプレフィックスとして使用します。
-iwithprefix dir
ディレクトリを第 2
インクルードパスに追加します。ディレクトリ名は prefix と dir
を連結することによって得られます。ここで prefix は、`-iprefix'
オプションによって指定されたものです。
-nostdinc
ヘッダファイルのための標準のシステムディレクトリを検索しません。`-I'
オプションによって指定したディレクトリ (またはカレントディレクト
リ) のみを検索します。
`-nostdinc' と
`-I-'を使用することにより、インクルードファイルの検索パスを明示的に指
定したディレクトリのみに限定することが可能となります。
-nostdinc++
ヘッダファイルの検索に、C++-固-
の標準ディレクトリを用いません。ただ
しそれ以外の標準ディレクトリは検索されます。 (このオプションは
`libg++' の構築に使用されます。)
-undef 標準でない定義済みマクロ(アー-
テクチャフラグも含めて)を定義しません。
-E C プリプロセッサの処理のみを行います。指定された全ての C
のソースファイル
に対してプリプロセスを行ない、標準出力、または指定された出力ファイルに
対して出力を行います。
-C プリプロセッサに対してコメントの削除を行なわないように指示します。
`-E' オプションとともに使用されます。
-P プリプロセッサに対して `#line'
コマンドを生成しないように指示します。 `-E'
オプションとともに使用されます。
-M [ -MG ]
プリプロセッサに対してmake
で使用可能な、オブジェクト間の依存関係を-
述した出力を生成するように指示
します。それぞれのソースファイルに対して、プリプロセッサはmake
のための規則を 1 つ出力します。この出力は、ターゲットとして
そのソースファイルから生成されるオブジェクトファイルのファイル名をとり、
依存するファイルのリストとしては `#include'
によってソースファイルに
読み込まれる全てのファイルの名前が並びます。この 規則は 1
行、あるいは長い場合には`\'
と改行を入れて複数行で出力されます。この規則のリストは、プリプロセス済
みの C プログラムのかわりに、標準出力へと出力されます。
`-M' は暗黙のうちに `-E' を含みます。
`-MG'
を指定すると、見つからないヘッダファイルは生成されたファイルであり、
それらはソースファイルと同じディレクトリに存在するとみなします。
これは `-M' と同時に指定しなければなりません。
-MM [ -MG ]
`-M' と似ていますが、`#include
"file"'によってインクルードされるユーザ定義のヘッダファイルのみを対象に
した出力ファイルを生成します。`#include <file>'
によってインクルードされるシステムヘッダファイルは省略されます。
-MD `-M' と似ていますが、依存情報は出力ファイル名の最後の `.o' を
`.d' に置ご垢┐織侫．ぅ詭召離侫．ぅ襪紡个靴峠侘呂気譴泙后 `-MD'
を指定したファイルのコンパイルもこれに加えて行なわれ、 `-M'
のように通常のコンパイルを抑制することはありません。
Mach のユーティリティである`md' は、これらの複数の `.d'
ファイルを `make' コマンドによって使用でい訝碓譴琉預元-
述ファイルへとマージするのに使用 することがでい泙后
-MMD `-MD'
と似ていますが、ユーザヘッダファイルのみを対象とし、システムヘッダ
ファイルを無視します。
-H 通常の動作に加えて、使用されたヘッダファイルの名前を表示します。
-Aquestion(answer)
questionに対するアサーション answer を定義します。これは `#if
#question(answer)'
のようなプリプロセッサ条件節によってテストされます。`-A-'
は標準のアサーション(通常はターゲットマシンに関
する情報を表している)を禁止します。
-Dmacro
マクロ macro に対して文字列 `1' を定義として与えます。
-Dmacro=defn
マクロ macro を defn として定義します。コマンドライン上の全ての
`-D' オプションは `-U'
オプションの処理を行なう前に処理されます。
-Umacro
マクロ macro の定義を無効にします。`-U' オプションは全ての `-D'
オプションの処理が終了した後、`-include' と `-imacros'
オプションの処理の前に処理されます。
-dM プリプロセッサに対して、プリプロセス終了時に-
効であったマクロの定義の みを出力するように指示します。`-E'
オプションとともに使用します。
-dD プリプロセッサに対して、全てのマクロ定義を適切な順番で出力中にそのまま
出力するように指示します。
-dN `-dD' と似ていますが、マクロの引数と内容を削除します。
出力には`#define name' のみが含まれます。
-Wa,option
option をアセンブラに対するオプションとして渡します。option
がコンマを含む場合は、そのコンマで区切られた複数のオプションとして与え
られます。
これらのオプションは、コンパイラがオブジェクトファイル群をリンクして 1
つ
の実行可能ファイルを出力する際に使用されるものです。これらはコンパイラが
リンクステップを行なわない場合には意味を持ちません。
object-file-name
特別に認識される拡張子で終っていないファイル名は、オブジェクトファイル、
またはライブラリであると認識されます。(オブジェクトファイルとライブラリ
はリンカがその内容を参照することで区別されます。) GCC
がリンクステップを
行なう場合は、これらのファイルはリンカへの入力として使用されます。
-llibrary
名前が library であるライブラリをリンク時に使用します。
リンカは、標準のライブラリ用ディレクトリのリスト中から、
実際のファイル名が `liblibrary.a'
であるファイルを検索します。リンカはこのファイルを、ファイル
名で直接指定した場合と同様に使用します。
検索するディレクトリには、いくつかの標準システムディレクトリと、`-L'
によって指定したディレクトリが含まれます。
通常、この方法で発見されるファイルはライブラリファイル、つまりいくつかの
オブジェクトファイルをメンバとして含むアーカイブファイルです。
リンカは、アーカイブファイルの中を検索して、
参照されているが定義されていないシンボルを定義しているメンバを
探し出します。
しかし、もしリンカがライブラリでなく通常のオブジェクトファイルを発見した
場合は、そのオブジェクトファイルを通常の方法でリンクします。`-l'
オプションを使用する場合とファイル名を直接指定する場合の違いは、`-l'
の場合が library を `lib' と `.a'
で囲み、いくつものディレクトリを検索することだけです。
-lobjc Objective C のプログラムをリンクする場合は、この特別な -l
オプションを指定する必要があります。
-nostartfiles
リンク時に、標準のシステムスタートアップファイルを使用しません。
標準ライブラリは通常通りに使用されます。
-nostdlib
リンク時に、標準のシステムライブラリとスタートアップファイルを使用しません。
指定したファイルのみがリンカに渡されます。
-static
ダイナミックリンクをサポートするシステムにおいて、このオプションは共-
ライブラリとのリンクを抑制します。それ以外のシステムではこのオプションは
意味を持ちません。
-shared
他のオブジェクトとリンクして実行可能プログラムを形成し得る共-
オブジェクトを
生成します。ごく少数のシステムでのみ、このオプションはサポートされ
ています。
-symbolic
共-
オブジェクトを構築する際に、グローバルなシンボルへの参照をバインド
します。全ての解決でい覆った参照に対して警告を与えます
(ただしリンクエディタオプション `-Xlinker -z -Xlinker defs'
によってこれを無効化した場合を除-
ます)。ごく少数のシステムでのみ、
このオプションはサポートされています。
-Xlinker option
オプション option
をリンカに対して渡します。リンカに渡すシステム固-
のオプションが、 GNU CC が理解でい覆い發里任△訃豺腓僕用で-
ます。
引数を持ったオプションを渡したい場合は、 `-Xlinker' を 2
度使用すれば可能です。1 度目でオプションを渡し、2 度目で引数を
渡します。例えば `-assert definitions' を渡すには、 `-Xlinker
-assert -Xlinker definitions' のように欺劼垢譴于椎修任后
`-Xlinker "-assert definitions"'
のように指定した場合は正常に動作しません。なぜならこれは、文字列全
体を 1
つの引数として渡してしまい、リンカの期待する形式と異なってしま
うからです。
-Wl,option
オプション option をリンカに渡します。option
がコンマを含む場合は、それらのコンマで複数のオプションとして分割されます。
-u symbol
シンボル symbol
が未定義であるかのように振舞います。これは強制的にこのシンボルを定義してい
るライブラリモジュールをリンクするために使用します。`-u'
は異なったシンボルに対して複数回使用することがで-
ます。これによっ
て、さらに多くのライブラリモジュールを読み込ませることがで-
ます。
これらのオプションは、ヘッダファイル、ライブラリ、コンパイラの一部を検
索するディレクトリを指定するために使用されます。
-Idir ディレクトリ dir
を、インクルードファイルの検索するディレクトリのリスト中に追加します。
-I- `-I-' オプション指定前に `-I'
オプションによって指定された全てのディレクトリは、`#include
"file"' の形式によってのみ検索されます。 これらのディレクトリは
`#include <file>' によっては検索されません。
` -I-' オプション指定後に `-I' で指定したディレクトリは、全ての
`#include' 命令によって検索されます。(通常は `-I'
で指定されたディレクトリは この方法で検索されます。)
これに加えて `-I-' オプションは、カレントディレクトリ
(現在の入力ファイルが存在する ディレクトリ) が `#include "file"'
に対する最初の検索対象となることを抑制します。`-I-'
によるこの効果を上書い垢詈法はありません。`-I.'
を指定することによって、コンパイラが起動されたディレクトリが検索
されることを指定することは可能です。これはプリプロセッサが行なう
デフォルトの動作とは異なりますが、たいていはこれで十分です。
`-I-'
は、ヘッダファイルの検索に標準のシステムディレクトリを使うことを抑制
するわけではありません。 従って、`-I-' と `-nostdinc' は
独立です。
-Ldir ディレクトリdir を `-l'
による検索が行なわれるディレクトリのリストに加えます。
-Bprefix
このオプションはコンパイラ自身の実行形式、ライブラリ、データファイルの
検索場所を指定します。
コンパイラドライバはサブプログラム `cpp', `cc1' (または C++
においては `cc1plus'), `as', そして `ld' を 1
つ、あるいはそれ以上起動します。コンパイラドライバは、
起動するプログラムのプレフィックスとして prefix に `machine/ver-
sion/' をつけたものとつけないものの双方を 使用します。
コンパイラドライバは各サブプログラムの起動時に、 `-B'
プレフィックスの指定がある場合は、それを最初に利用します。もしその
名前が見つからなければ、または `-B'
が指定されていなければ、ドライバは 2 つの標準プレフィックス
`/usr/lib/gcc/' と `/usr/local/lib/gcc-lib/'
を試します。このどちらにも見つからなければ、コンパイラドライバは、
環曲竸 `PATH'
のディレクトリリストを利用して、そのプログラム名を検索します。
ランタイムサポートファイル `libgcc.a' も、必要ならば `-B'
プレフィックスを用いて検索されます。もしそこに見つからなければ、
前 2
つの標準プレフィックスが試みられますが、それで終りです。この場合は
リンクの対象から外されます。ほとんどの場合、またほとんどのマシンでは、`libgcc.a'
は実際には必要ではありません。
これと同じ効果を、環曲竸 GCC_EXEC_PREFIX
によっても得ることがでい泙后もしこの環-
変数が定義されていれば、こ
の値がプレフィックスとして同様に使用されます。もし `-B'
オプションと GCC_EXEC_PREFIX 環曲竸瑤料佇が存在した場合は、`-B'
オプションが最初に使用され、環曲竸瑤麓，忙藩僂気譴泙后
警告は、本質的に間違いであるわけではありませんが、危険な構造を報告したり、
エラーがあるかもしれないような部分を示唆する診断メッセージです。
以下のオプションは、GNU CC が生成する警告の量と種類を制御します。
-fsyntax-only
コードの文法エラーをチェックしますが、一切出力は行いません。
-w 全ての警告メッセージを抑制します。
-Wno-import
#import の利用による警告メッセージを抑制します。
-pedantic
厳密な ANSI 標準 C
言語で規定している全ての警告を表示し、許されていない拡張を
使用したプログラムを全て拒否します。
正当な ANSI 標準 C プログラムは、このオプションの楊気亡悗錣蕕
コンパイルでい襪戮です (もっとも、ほんのわずかではありますが
`-ansi'
を必要とするものはあります)。しかし、このオプションを使用しない場合、
GNU 拡張や伝統的な C
の特徴も、これに加えてサポートされます。このオプション
を使用すれば、それらは拒絶されます。このオプションをν由はありませんが、こだわりのある人々を満-
させるためにのみ 存在しています。
`-pedantic' は、始まりと終りとが `__' である代替-
ーワードの使用については、警告しません。 同様に __extension__
に続く表現についても警告しません。しかし、システムヘッダファイルのみ
がこの抜け道を使用すべ-
であり、アプリケーションプログラムはこれを避け るべい任后
-pedantic-errors
`-pedantic' と似ていますが、警告のかわりにエラーを出します。
-W 以下のイベントに対して、特別な警告メッセージを表示します。
+o volatile でない自動変数が longjmp
の呼び出しによって変更され得る場合です。これらの警告は、最適化コンパイル
の時のみ問題になり得ます。
コンパイラは setjmp
の呼び出しのみを見ています。コンパイラは、どこで longjmp
が呼び出されるかを知ることはで-
ません。実際には、シグナルハンドラは コード中の任意の場所で
longjmp を呼び出すことがでい泙后従って、実際には longjmp
への呼び出しが危険な部分からはおこなわれていないために問題のないプ
ログラムであっても、警告が発せられることになります。
+o 関数が、値を伴ってリターンする場合と、値を伴わずにリターンする場合の両方
が起こりうる場合です。
(関数の最後を抜けていくことは、値を伴わずに関数をリターンするとみなされます。)
例えば、次の関数がこの種類の警告を引さこします。
foo (a)
{
if (a > 0)
return a;
}
ある関数 (abort やlongjmp を含む)
が決してリターンしないということを GNU CC が理解で-
ないために、にせの警告 が発生するかもしれません。
+o 式文 (expression-statement) またはコンマ式の左部分が
一切の副作用を含まない場合です。
警告を抑制するには、使用しない式を void にゥ礇好箸靴堂爾気ぁ
例えば `x[i,j]' といった式は警告されますが、`x[(void)i,j]'
は警告されません。
+o 符号無しの値が 0 と `>' または `<=' で比較される場合です。
-Wimplicit-int
型を指定していない宣言に対して警告します。
-Wimplicit-function-declaration
宣言に先立って用いられた関数に対して警告します。
-Wimplicit
-Wimplicit-int および -Wimplicit-function-declaration
と同じです。
-Wmain main
関数が不審な型で宣言あるいは定義されている場合に警告します。
通常、main は外部リンケージを持ち、 int を返し、0 個または 2
個の引数をとる関数です。
-Wreturn-type
関数の戻り値の型が、デフォルトである int
に定義された時に常に警告します。また、戻り値の型が
voidでない関数内に、戻り値のない return
文がある場合にも常に警告します。
-Wunused
ローカル変数が宣言されたにも関わらず使用されていない場合、静的に宣言さ
れた関数の実体が定義されていない場合、計算結果が明らかに
利用されていない場合に常に警告します。
-Wswitch
switch
文がインデックスとして列挙型をとっている時、その列挙型中のいくつ
かの値に対する case が欠けている場合に常に警告します。(default
ラベルが存在する場合、この警告は出ません。)
このオプションを使用した場合 には、列挙型の範囲を越えた case
ラベルも、常に警告されます。
-Wcomment
コメントの開始文字列 `/*'
がコメント中に現れた時に常に警告します。
-Wtrigraphs
トライグラフの出現を常に警告します
(トライグラフが使用可能であると仮定します)。
-Wformat
printf, scanf
などへの呼び出しに対して、与えられた引数が、フォーマット文字列の指
定を満造垢觀燭鮖っているかを検査します。
-Wchar-subscripts
配列の添字の型が char
であった場合に警告します。これはよくある間違いのもとです。
いくつかのマシンにおいてはこの型が符号付い任△襪海箸髻
プログラマはしばしば忘れてしまいます。
-Wuninitialized
初期化されていない自動変数が使用されています。
これらの警告は、最適化コンパイルを行なう時のみ発生します。なぜなら、
コンパイラは最適化を行なう時にのみデータフロー情報を必要とするからです。
もし `-O' を指定しなかった場合は、この警告を得ることはで-
ません。
これらの警告は、レジスタ割り当ての対象となった変数についてのみ発生します。
従って、volatile
であると宣言された変数や、アドレス上に割り当てられた変数、サイズが
1, 2, 4, 8
バイト以外の変数に関してはこれらの警告は発生しません。
さらに、構造体、共用体、配列については、たとえそれらがレジスタに
割り当てられたとしても、これらの警告は発生しません。
ある変数によって計算された値が結局使用されないような変数については、一切の
警告が生じないことに注意して下さい。このような計算は、警告が表示される前に
データフロー解析によって削除されます。
これらの警告をオプションにした理由の一つは、GNU CC
がまだあまり犬なくて、
あるコードが一見間違いを含むかのように見えても
それは実は正しいものかもしれない、 ということを GNU CC
が理解でい覆ぁ△箸いΔ發里任后 ここにその 1 つの例を挙げます。
{
int x;
switch (y)
{
case 1: x = 1;
break;
case 2: x = 4;
break;
case 3: x = 5;
}
foo (x);
}
もし y の値が常に 1, 2 あるいは 3 である限りは x は常に
初期化されます。しかし GNU CC はこれを知ることはでい泙擦鵝もう
1 つの一般 的な例を挙げます。
{
int save_y;
if (change_y) save_y = y, y = new_y;
...
if (change_y) y = save_y;
}
これはバグを含みません。なぜなら save_y
は、その値が設定された時のみ使用されるからです。
いくつかのにせの警告は、使用している決してリターンしない関数全てに対して
volatile と宣言することによって防ぐことが可能です。
-Wparentheses
ある特定の文脈中で括弧が省略されていた場合に警告します。
-Wtemplate-debugging
C++
プログラムにおいてテンプレートを使用している際に、デバッグが完全に
可能でない場合を警告します (C++ のみ)。
-Wall 全ての上に挙げた `-W'
オプションを結合したものです。これらのオプションは全て、
たとえマクロとの組み合わせ
であっても、避けたほうがいいと我々が推奨する用法や、
簡単に避けることがでい襪伐罅垢信じている用法に関するものです。
残りの `-W...' オプションは `-Wall'
によっては暗黙のうちに指定されません。なぜならこれらは、クリーンなプ
ログラムにおいても、ある状況においては使用することが妥当であると我々が
考える構造についての警告を行なうオプションだからです。
-Wtraditional
伝統的な C と ANSI C
において異なった振舞いをする特定の構造について警 告します。
+o マクロ引数がマクロ本体内の文字列定数に現れるものです。これは、伝統的な
C に おいてはその引数で置換しましたが、ANSI C
においては定数の一部として扱わ れます。
+o ブロック内で外部宣言であると宣言され、かつそのブロックの終端の後で
使用されている関数です。
+o オペランドとして long 型をとる switch 文です。
-Wshadow
ローカル変数が他のローカル変数を隠している時に常に警告します。
-Wid-clash-len
2 つの全く別の識別子の最初の len
文字が一致した時に警告します。これはある種の旧式な
おばかさんコンパイラでコンパイルされ得るプログラムを作る場合に役に立ちます。
-Wpointer-arith
関数型や void の "サイズ" に依存するものを全て警告します。GNU C
はこれらに対して、 サイズ 1 を割り当てています。これは void *
ポインタと関数へのポインタにおける計算を簡便にするためです。
-Wcast-qual
ポインタが、型修飾子が削除されるように-
ャストされる全ての場合に警告します。 例えば const char * を
普通の char * にゥ礇好箸靴疹豺腓坊拗陲なされます。
-Wcast-align
ポインタのゥ礇好箸砲いて、そのターゲットに要求される恭条件が
大いなるようなゥ礇好箸鯀瓦瞳拗陲靴泙后Ｎ磴┐ char * が int *
へとゥ礇好箸気譴襪函∪或瑤 2、あるいは 4 バイト-
界でしかアクセスで い覆ぅ泪轡鵑砲いては警告が発せられます。
-Wwrite-strings
文字定数に対して、型 const char[length] を与え、非-const の char
*
ポインタへのアドレスのコピーに対して警告するようにします。この警告は、
宣言とプロトタイプにおいて const
の使用を非常に注意深くおこなっていさえすれば、 文字列定数に書-
込みをしそうなコードをコンパイル時に発見することを助けますが、
そうでない場合は由果輝廚併慊蠅任后これが、我々がこの警告を
`-Wall' のリクエストに含めなかった理由です。
-Wconversion
同じ引数が与えられた時に、プロトタイプが存在する場合とプロトタイプが
存在しない場合とで、異なった型変換を引-
起こす場合について警告します。
これは固定小数点から浮動小数点への変換やその逆、デフォルトの動作と異なる固定
小数点引数の幅や符号の楊気諒儡垢含まれます。
-Waggregate-return
構造体や共用体を返す関数を定義した場合や、
それらを呼び出す全ての場合に警告します。 (配列を返すことがで-
る言語においても、これは警告を引さこします。)
-Wstrict-prototypes
引数の型を指定せずに関数を宣言、あるいは定義した場合に警告します。
(以前に引数の型を指定した宣言が存在する場合には、旧式の関数宣言に対しては
警告をしません。)
-Wmissing-declarations
グローバルな関数を、その前にプロトタイプ宣言をせずに定義した場合に
警告します。
この警告は、たとえその定義自身がプロトタイプを含んでいたとしても発生します。
この警告の目的は、ヘッダファイル中にグローバル関数の定義を忘れるこ
とを防ぐことにあります。
-Wredundant-decls
同一スコープ中で複数回、同一対象を宣言した場合に、たとえそれが正当で何も
変化させない場合であっても警告します。
-Wnested-externs
関数内で extern 宣言を行なった場合に警告します。
-Wenum-clash
異なる列挙型の間で変換を行なった際に警告します (C++ のみ)。
-Wlong-long
long long
型が使用されている場合に警告します。これはデフォルトです。
この警告メッセージを抑止するには `-Wno-long-long'
フラグを用いて下さい。フラグ `-Wlong-long' および
`-Wno-long-long' は、フラグ `-pedantic' 使用時のみ考慮されます。
-Woverloaded-virtual
(C++ のみ。)
導出クラスにおいて、仮想関数の定義は基底クラスで定義された仮想関数の型
の-
述と一致していなければなりません。このオプションを使用することによっ
て、基底クラスにおける仮想関数と同一の名前を持ち、基底クラスのいかなる
仮想関数とも異なった型の-
述を持つ関数に対して警告が行われます。これに
よって、導出クラスが仮想関数を定義しようとして失敗する場合を警告するこ
とがでい泙后
-Winline
関数がインライン宣言されている、あるいは -finline-functions
オプションが与えられている場合に、関数をインライン展開で-
なかった場合 に警告します。
-Werror
警告をエラーとして扱います。警告の後にコンパイルを中断します。
GNU CC は、ユーザのプログラムや GCC の双方をデバッグするために、
多くのオプションを備えています。
-g オペレーティングシステムのネイティブのフォーマット (stabs, COFF,
XCOFF, DWARF) でデバッグ情報を生成します。GDB
はこのデバッグ情報に基づい て動作することがでい泙后
stabs フォーマットを使用するほとんどのシステムにおいては、`-g'
を指定すると、GDB だけが使用でい詬省なデバッグ情報が使用可能に
なります。 この特別の情報は GDB
に対してはよりよいデバッグを行なうことを可能
としますが、おそらく他のデバッガに対してはクラッシュ、あるいはそのプログラムを
読めなくしてしまいます。この特別な情報の生成を制御するためには
`-gstabs+', `-gstabs', `-gxcoff+', `-gxcoff', `-gdwarf+',
`-gdwarf' を使用してください (下技仮)。
他の多くの C コンパイラと異なり、GNU CC は `-g' を `-O'
とともに使用することを許しています。最適化されたコードが通る近道は、
時には驚くべし覯未鮴犬濬个垢もしれません。
定義したはずの変数が存在しなかったり、
制御の流れが予想もしなかった場所に移動したり、結果が定数とわかる計算や、
結果がすでに手元にある文は実行されなくなり、ある文がループの外に追い出されて
別の場所で実行されたりします。
それにも関わらず、このオプションは最適化された出力のデバッグを可能とし
ています。これによって、バグを含むかもしれないプログラムに対して
オプティマイザを使用することがでい襪茲Δ砲覆蠅泙后
以下のオプションは、GNU CC を 1 つ以上のデバッグフォーマットを扱
えるように作成してある場合に猶廚任后
-ggdb (もしサポートされていれば)ネイティブのフォーマットでデバッグ情報を生成
します。これは可能な限りの全ての GDB 拡張を含みます。
-gstabs
(もしサポートされていれば) stabs
フォーマットでデバッグ情報を生成します。 ただし GDB
拡張は含みません。このフォーマットはほとんどの BSD システム上 の
DBX で利用でい襯侫ーマットです。
-gstabs+
(もしサポートされていれば) stabs
フォーマットでデバッグ情報を生成します。 ただし GNU デバッガ
(GDB) でしか理解でい覆 GNU 拡張を使用します。
この拡張を使用すると、他のデバッガでは、クラッシュや
プログラムが読めなくなるなどの影響がおそらく出ます。
-gcoff (サポートされていれば) COFF
フォーマットでデバッグ情報を生成します。 これは、System V Re-
lease 4 より前の ほとんどの System V 上の SDB で利用で-
るフォーマットです。
-gxcoff
(サポートされていれば) XCOFF
フォーマットでデバッグ情報を生成します。こ れは IBM RS/6000
システムにおいて DBX デバッガによって使用される
フォーマットです。
-gxcoff+
(もしサポートされていれば) XCOFF
フォーマットでデバッグ情報の生成を行 います。ただし、GNU
デバッガ (GDB) によってのみ理解され得る GNU 拡張を使
用します。これらの拡張を使用すると、他のデバッガに対してはクラッシュやプ
ログラムを読みとり不能にするなどの影響を及ぼし得ます。
-gdwarf
(もしサポートされていれば) DWARF
フォーマットでデバッグ情報の生成を行 います。これはほとんどの
System V Release 4 システムにおいて SDB によっ
て使用される形式です。
-gdwarf+
(もしサポートされていれば) DAWRF
フォーマットでデバッグ情報の生成を行 います。ただし、GNU
デバッガ (GDB) によってのみ理解され得る GNU 拡張を使
用します。これらの拡張を使用すると、他のデバッガに対してはクラッシュや
プログラムを読みとり不能にするなどの影響を及ぼし得ます。
-glevel
-ggdblevel
-gstabslevel
-gcofflevel -gxcofflevel
-gdwarflevel
デバッグ情報を要求しますが、同時に level
によってどの程度の情報が必要かを指定します。デフォルトのレベルは
2 です。
レベル 1
は、デバッグを予定しないプログラムの部分に対してバックトレース
を生成するに十分な最低限の情報を生成します。これは関数と外部変数の-
述 を含みますが、ローカル変数や行番号に関する情報は含みません。
レベル 3
はプログラムに含まれる全てのマクロ定義などの特別な情報を含みます。
いくつかのデバッガは `-g3'
の使用によってマクロの展開をサポートします。
-p プログラム prof によって使用されるプロファイル情報を書-
込む特別なコードを生成します。
-pg プログラム gprof によって使用されるプロファイル情報を書-
込む特別なコードを生成します。
-a 基本ブロックのプロファイル情報を書-
込む特別なコードを生成します。これは
それぞれのブロックが何回実行されたかを杵燭靴泙后このデータは
tcov
のようなプログラムによって解析されます。ただし、このデータフォーマットは
tcov が期待するものとは異なっています。最終的には、GNU gprof
が処理でい襪茲Δ乏板イ気譴襪戮です。
-ax ファイル `bb.in'
から基本ブロックプロファイルパラメータを読み出し、 ファイル
`bb.out' にプロファイル結果を書そ个垢燭瓩痢
特別なコードを生成します。 `bb.in'
は関数のリストを保持しています。
このリストに含まれる関数に入ると、プロファイリングがオンになります。
最外側関数を抜けると、プロファイリングはオフになります。
関数名が `-' で始まっている場合、その関数はプロファイル対象外に
なります。もし関数名が唯一に定まらない場合は、 `/path/file-
name.d:functionname' と欺劼垢襪海箸任海譴蕕魘菠未任ます。
`bb.out' には、いくつかの利用可能な関数がリストされます。
特別な意味をもつ関数が 4 つあります: `__bb_jumps__'
はジャンプ頻度を `bb.out' に書そ个靴泙后 `__bb_trace__'
は基本ブロック列を `gzip' にパイプし、 ファイル `bbtrace.gz'
に書そ个靴泙后 `__bb_hidecall__' は call
命令をトレースから除外します。 `__bb_showret__' は return
命令をトレースに含めるようにします。
-dletters
コンパイル中の letters
で指定されるタイミングに、デバッグ用のダンプを生成するように指示します。
これはコンパイラをデバッグするために使用されます。ほとんどのダンプのファイル
名はソースファイル名に 1
単語をつなげたものになります。(例えば、`foo.c.rtl' や
`foo.c.jump' などです)。
-dM 全てのマクロ定義をダンプし、プリプロセス終了時に出力に書-
出します。 その他には何も書そ个靴泙擦鵝
-dN 全てのマクロ名をダンプし、プリプロセス終了時に出力に書-
出します。
-dD 全てのマクロ定義をプリプロセス終了時に通常の出力に加えてダンプします。
-dy パース中にデバッグ情報を標準エラー出力にダンプします。
-dr RTL 生成後に `file.rtl' に対してダンプします。
-dx 関数をコンパイルするかわりに、RTL
を生成するのみの処理を行います。通常は `r'
とともに使用されます。
-dj 最初のジャンプ最適化の後に、`file.jump' に対してダンプします。
-ds 共通部分式削除
(しばしば共通部分式削除に続くジャンプ最適化も含みます) の終了
時に `file.cse' に対してダンプします。
-dL ループ最適化終了時に `file.loop' に対してダンプします。
-dt 第 2 共通部分式削除段階
(しばしば共通部分式削除に続くジャンプ最適化も 含みます)
の終了時に、`file.cse2' に対してダンプします。
-df フロー解析終了後に、`file.flow' に対してダンプします。
-dc 命令コンビネーション終了時に `file.combine'
に対してダンプします。
-dS 第 1 命令スケジューリング段階終了時に `file.sched'
に対してダンプします。
-dl ローカルレジスタ割り当て終了時に `file.lreg'
に対してダンプします。
-dg グローバルレジスタ割り当て終了時に `file.greg'
に対してダンプします。
-dR 第 2 命令スケジューリング段階終了時に `file.sched2'
に対してダンプします。
-dJ 最終ジャンプ最適化終了時に `file.jump2' に対してダンプします。
-dd 遅延分岐スケジューリング終了時に `file.dbr'
に対してダンプします。
-dk レジスタからスタックへの転換終了時に `file.stack'
に対してダンプします。
-da 以上の全てのダンプを生成します。
-dm 処理の終了時に、メモリ使用に関する統計情報を標準エラー出力に出力します。
-dp どのようなパターンや選択肢が使用されたかを示すコメントをアセンブラ出力
中のコメントで解説します。
-fpretend-float
クロスコンパイラで処理を行なう際に、ホストマシンと同じ浮動小数点フォーマット
をターゲットマシンが持つかのように振舞わせます。これは浮動小数点定
数の誤った出力を引さこしますが、実際の命令列はおそらく GNU CC
を ターゲットマシンで起動した場合と同じものとなるでしょう。
-save-temps
通常の "一時" 中間ファイルを消去せずに保存します。これらは
カレントディレクトリに置かれ、ソースファイルに基づいた名前が付けられます。
従って、`foo.c' を `-c -save-temps'
を使用してコンパイルした場合は、 `foo.cpp', `foo.s' が、`foo.o'
と同様に生成されます。
-print-libgcc-file-name=library
ライブラリファイル `library '
の完全な絶対名を表示します。このファイルはリンクの際のみに使用され、
それ以外の働い呂△蠅泙擦鵝このオプションが指定された場合は、GNU
CC は
コンパイルやリンクを何も行なわず、ただファイル名を表示するのみです。
-print-libgcc-file-name
`-print-file-name=libgcc.a' と同じです。
-print-prog-name=program
`-print-file-name' と似ていますが、`cpp' のような program
を検索します。
これらのオプションは様々な種類の最適化処理を制御します。
-O
-O1 最適化を行います。最適化コンパイルは幾分長めの処理時間と、大-
な関数に対 する非常に多くのメモリを必要とします。
`-O'
が指定されなかった場合は、コンパイラの目標はコンパイルのコストを
低減することや、目的の結果を得るためのデバッグを可能とすることに置かれ
ます。それぞれの文は独立しています。つまり、ブレークポイントでプログラムを
停止させることによって、任意の変数に新し
い値を代入したり、プログラムカウンタを他の文へと変更することを可能とし、
そのソースコードにプログラマが望む正しい結果を得ることを可能にします。
`-O' を指定しなかった場合は、register
と宣言した変数のみがレジスタへと割り当てられます。コンパイルの結果と
して得られるコードは、PCC を `-O'
なしで使用した場合と比較して若干良くないものとなります。
`-O'
が指定されると、コンパイラはコードのサイズと実行時間を減少させる
ことを試みます。
`-O' を指定することによって、 `-fthread-jumps' と `-fdefer-pop'
のフラグが指定されます。遅延スロットをもつマシンでは `-fde-
layed-branch'
が指定されます。フレームポインタを使わないデバッグをサポートしている
マシンでは、`-fomit-frame-pointer'
も指定されます。マシンによってはさらにその他のフラグが
指定されることもあります。
-O2 さらに最適化を行います。サポートされている最適化手段のうち、
空間と速度のトレードオフを含まないものはほとんどの全て使用されます。
例えばループのアンローリングや関数のインライン化は行われません。
-O と比較して、このオプションはコンパイル時間と生成コードの-
能の双方を増加 させます。
-O3 さらなる最適化を行います。これは -O2
が行う全ての最適化手段に加えて -finline-functions も-
効にします。
-Os サイズ優先で最適化します。
普通、コードを増大させることのない全ての -O2 最適化が-
効になります。
更に、コードサイズを減らすように設計された最適化も行います。
-O0 最適化を行いません。
複数の -O オプションを指定した場合は、レベル番号の-
無に関わらず、最後に指定した ものが邑になります。
`-fflag' の形式を持ったオプションは、マシン独立のフラグです。ほとんどの
フラグは邑形式と無効形式の双方を持っています。`-ffoo' の無効形式は
`-fno-foo'
です。以下のリストでは、デフォルトではない方の形式のみを示します。
これに対して `no-'
を削除する、あるいは追加することによって双方の形式を生成すること
が可能です。
-ffloat-store
浮動小数点変数をレジスタに格納しません。このオプションは 68000
のように (68881 の) 浮動小数点レジスタが double
よりも高い精度を持っていると思われるマシンにおいて、望まない超過精度を
抑制することを可能にします。
ほとんどのプログラムにおいては、超過精度は単に良い結果を生むだけですが、
いくつかのプログラムは正確な IEEE
の浮動小数点フォーマット定義に依 存しています。
このようなプログラムに対して `-ffloat-store' を使用します。
-fmemoize-lookups
-fsave-memoized
コンパイルを高速に行なうために、ヒューリスティックスを使用します
(C++ のみ)。これらのヒューリスティックスはデフォルトでは-
効になってい
ません。なぜなら、これはある種の入力ファイルにしか効果がなく、その他の
ファイルではかえってコンパイルが低速になるからです。
最初に、コンパイラはメンバ関数への呼び出し
(あるいはデータメンバへの参 照) を構築します。これは (1)
どのクラスでその名前のメンバ関数が実装さ れているかを決定し、(2)
どのメンバ関数への呼び出しであるかという問題
(これはどの種類の型変換が必要となるかという決定も含みます)
を解決し、(3) 呼び出し側に対するその関数の可視-
を検査するという作業を行なう必要があります。
これらは全て、コンパイルをより低速にしてしまいます。通常は、そのメンバ
関数への 2
度目の呼び出しが起こった場合も、この長い処理がまた行なわれ
ることになります。これは次のようなコード
cout << "This " << p << " has " << n << " legs.\n";
は、これらの 3 つの手順を 6
回繰り返すということを意味します。これに対し て、ソフトウェア-
ャッシュを使用すると、そのゥ礇奪轡紊悗"ヒット
"は、コストを劇的に低減することが期待でい泙后Ｉ垤なことに、-
ャッシュ
の導入によって異なったレイヤの機構を実装することが必要となり、それ
自身のオーバヘッドが生じてしまいます。`-fmemoize-lookups'
はこのソフトウェアゥ礇奪轡紊鰺効にします。
メンバとメンバ関数へのアクセス特権 (可視)
はある関数におけるコンテゥ好
と別の関数におけるものとでは異なるので、 g++ は-
ャッシュをフラッシュしなければなりません。`-fmemoize-lookups'
フラグを使用すると、全ての関数をコンパイルするたびに毎回-
ャッシュを フラッシュします。`-fsave-memoized'
フラグは同一のソフトウェアゥ礇奪轡紊砲弔い董▲灰鵐僖ぅ蕕前回
コンパイルした関数のコンテゥ好箸、次にコンパイルするコンテ-
ストと同 一のアクセス特権を佑靴討い襪箸澆覆擦觧には、-
ャッシュを保持します。
これは同一クラス中に多くのメンバ関数を定義している時に特に-
効です。 他のクラスのフレンドになっているメンバ関数を除-
、同一のクラスに属して
いる全てのメンバ関数のアクセス特権は、全て同一です。このような場合は
ゥ礇奪轡紊鬟侫薀奪轡紊垢詆要はありません。
-fno-default-inline
クラススコープ中に定義されたメンバ関数をデフォルトでインライン関数とす
る処理を行ないません (C++ のみ)。
-fno-defer-pop
それぞれの関数呼び出しに対して、関数のリターン直後に常に引数をポップします。
関数呼出後に引数をポップしなければならないマシンにおいては、
コンパイラは通常、いくつかの関数の引数をスタックに積んで、
それらを同時にポップします。
-fforce-mem
メモリオペランドに対して、それらに対する演算が行なわれる前に、
レジスタにコピーします。これは全てのメモリ参照を、潜在的な共通部分式であると
定めることによって、より良いコードを生成します。もしそれが共通部分式でな
かった場合は、命令コンビネーションによってレジスタへの読み込みは削
除されます。私はこれがどのような違いを生み出すかということに興味があります。
-fforce-addr
メモリアドレス定数について、それらに対する演算が行なわれる前にレジスタ
にコピーします。これは `-fforce-mem'
と同じ手法でより良いコードを生成します。私はこれがどのような違いを
生み出すかということに興味があります。
-fomit-frame-pointer
フレームポインタをレジスタに格納する必要のない関数において、この処理を
行いません。これはフレームポインタの保存、設定、復帰にかかる命令を省略
し、さらに、多くの関数でレジスタ変数として使用で-
る余分なレジスタを
得ることを可能にします。
Vax
などのいくつかのマシンでは、このフラグは効果を持ちません。なぜならこ
れらのマシンでは標準の呼び出し手順が自動的にフレームポインタの設定を
行なってしまい、これが存在しないとしたところで何も節約がで-
ないからです。 マシン欺劵泪ロ FRAME_POINTER_REQUIRED
が、ターゲットマシンがこのフラグをサポートするかどうかを制御しています。
-finline-functions
全ての単純な関数を呼び出し側に組み込んでしまいます。コンパイラは
ヒューリスティックスを用いて、 どの関数がこの方法で組み込むに-
りるほど単純かを決定します。
もし、ある関数に対する全ての呼び出しを組み込むことがで-
、かつその関数が static と宣言されていた場合は、GCC
はその関数を独立したアセンブラコードと しては出力をしません。
-fcaller-saves
関数呼び出しにおいて破壊されるであろう値を、レジスタに保持することを可
能とします。これはこのような呼び出しの周囲にレジスタに対する保存、復帰の
特別なコードを出力することによって実現されます。このような割り当ては、そ
れが通常よりも良いコードを出力するとみなされる場合にのみ行われます。
このオプションは特定のマシンではデフォルトで-
効となっています。これらは
通常、このオプションの処理の代わりに使うことがで-
る呼び出し時保存 レジスタが存在しないマシンです。
-fkeep-inline-functions
ある関数への呼び出しが全て呼び出し側に組み込むことがで-
て、かつその関数が static
と宣言されていたとしても、実行時に呼び出し可能な関数も生成します。
-fno-function-cse
関数のアドレスをレジスタに置-
ません。つまり、定まった関数を呼び出すコードは、
それぞれ明示的な関数のアドレスを含むコードとなります。
このオプションは効率の低いコードを生成しますが、アセンブラ出力を書-
換え
るようなハックを行なう場合には、このオプションを使用しなければ
混乱させられることでしょう。
-fno-peephole
マシン固佑離圈璽廛曄璽觝播化を禁止します。
-ffast-math
このオプションは生成コードのスピードのために、GCC
に対して、いくつかの ANSI または IEEE
の規則/規格を侵させます。例えば、このオプションは sqrt
関数の引数は非負の数であることを仮定します。
このオプションはどの `-O' オプションによっても-
効とされません。なぜなら、このオプションは数 学関数に関する IEEE
または ANSI の規則/規格の厳密な実装に依存して書かれた
プログラムに対して誤った出力を与えるからです。
以下のオプションは特殊な最適化に関する制御を行います。`-O2'
オプションは`-funroll-loops' と `-funroll-all-loops'
を除くこれらの全てのオプションを邑にします。
`-O' オプションは通常 `-fthread-jumps' と `-fdelayed-branch' を-
効とします。ただし、特殊なマシンではデフォルトの最適化に対して
変更が加えられているかもしれません。
最適化に関する "い畉戮いチューニング" が必要な場合に、以下の
フラグを使用することが可能です。
-fstrength-reduce
ループのストレングスリダクションと繰り返し変数の除去を行います。
-fthread-jumps
分岐ジャンプによってある場所にジャンプした時に、最初の分岐に包括される
比較が存在した時に、最初の分岐のジャンプ先を後者の分岐先に変更します。
この変更先は、2 番目の分岐条件の真偽によって、2
番目の分岐のジャンプ先か、 あるいは2
番目の分岐の直後に定められます。
-funroll-loops
ループ展開の最適化を行います。これはループの繰り返し数がコンパイル時、
あるいはランタイムに決定でい觧においてのみ、実行されます。
-funroll-all-loops
ループ展開の最適化を行います。これは全てのループに対して行われます。この
オプションは大抵、より遅く動作するプログラムを生成します。
-fcse-follow-jumps
共通部分式削除の処理において、ジャンプ命令の行先が
他の経路から到達でい覆ぞ豺腓蓮△修離献礇鵐很仁瓩魃曚┐謄好-
ャンを行 ないます。例えば、共通部分式削除処理中に else
節を伴った if
文に出会った場合、条件が偽ならば分岐先に対しても共通部分式削除を続けます。
-fcse-skip-blocks
これは `-fcse-follow-jumps'
に似ていますが、ブロックを跨ぐジャンプに対しても共通部分式削除を継
続します。共通部分式削除処理中に、else 節を持たない単純な if
文にであった時、 `-fcse-skip-blocks' は if
のボディを跨いだジャンプに対する共通部分式削除処理を継続します。
-frerun-cse-after-loop
ループ最適化が行なわれた後に、再度共通部分式削除の処理を行います。
-felide-constructors
コンストラクタへの呼び出しが省略で-
るように思われる場合に、その呼び出 しを省略します (C++
のみ)。このフラグを指 定した場合は、GNU C++
は以下のコードに対して、一時オブジェクトを経由せずに y を foo
への呼び出しの結果から直接初期化します。
A foo (); A y = foo ();
このオプションを使用しない場合は、GNU C++ は最初に y をA
型の適切なコンストラクタを呼び出すことによって初期化します。そして、
foo の結果を一時オブジェクトに格納し、最終的には `y'
の値を一時オブジェクトの値に入れ換えます。
デフォルトの振舞い (`-fno-elide-constructors') が、ANSI C++
標準のドラフトには規定されています。コンストラクタ
が副作用を含むプログラムに対して、`-felide-constructors'
を指定すると、そのプログラムは異なった動作をする可能-
があります。な
ぜなら、いくつかのコンストラクタの呼び出しが省略されるからです。
-fexpensive-optimizations
比較的コストの高いいくつかの些細な最適化を行います。
-fdelayed-branch
ターゲットマシンにおいてこのフラグがサポートされている場合は、遅延分岐
命令後の命令スロットを命令の順番変更によって利用するように設定します。
-fschedule-insns
ターゲットマシンにおいてこのフラグがサポートされている場合は、必要な
データを利用可能になるまで待つことによる実行の遅滞を防ぐために、命令
の順番の変更を行います。これは遅い浮動小数点命令やメモリ読み込み命令の実
行において、それらの結果を必要とする命令の前に他の命令を詰め込みます。
-fschedule-insns2
`-fschedule-insns'
と似ていますが、レジスタ割当て処理の後にもう一度命令スケジューリングの
段階を置-
ます。これは、比較的レジスタ数が少なく、メモリロード命令 が 1
サイクルよりも多くを要するマシンにおいて、特に効果的です。
デフォルトでは、GNU CC
コンパイラは、現在使用しているマシンと同じタイプの
コードをコンパイルします。しかし、GNU CC はクロスコンパイラ
としてもインストールすることが可能です。実際には、異なったターゲット
マシンのための様々なコンフィギュレーションの GNU CC は、同時にいくつ
もインストールすることが可能です。そこで、どの GNU CC を使用するかを
指定するために、`-b' オプションを使用することがでい泙后
これに加えて、古い、あるいはより新しいバージョンの GNU CC も同時にいく
つもインストールしていくことがでい泙后これらのうち 1 つ (おそらくもっ
とも新しいもの)
がデフォルトとなります。しかし、ひょっとしたら別のものを使
いたくなるかもしれません。
-b machine
引数 machine
は、コンパイルのターゲットマシンを規定します。これは GNU CC
をクロス コンパイラとしてインストールした時に様僂任后
machine に指定する値は、GNU CC
をクロスコンパイラとしてコンフィギュレーション
した時に与えたマシンタイプと同じです。例えば、80386 上の System
V で実行されるプログラムのために `configure i386v'
というコンフィギュレーションを行なったクロスコンパイラを起動した
い場合は、`-b i386v' と指定します。
`-b'
の設定を省略した場合は、通常は使用しているマシンと同タイプのマシン
のためのコンパイルが行われます。
-V version
引数 version は、起動される GNU CC
のバージョンを規定します。これは複数のバージョンが
インストールされている場合に様僂任后Ｎ磴┐弌 version が `2.0'
ならば、GNU CC バージョン 2.0 を起動することを意味します。
`-V' を指定しなかった場合のデフォルトのバージョンは、GNU CC
をインストール
する時に調整可能です。通常は、もっとも一般的な使用に勧めることがで-
る バージョンがここに指定されます。
それぞれのターゲットマシンタイプは、それぞれの特別なオプションを持つ
ことが可能です。`-m' で始まるオプション群は、様々なハードウェアモデルや
コンフィギュレーション--例えば 68010 と 68020、
浮動小数点コプロセッサの楊-- などを選択で-
ます。このオプションを指定することによって、コンパイラは どれか 1
つのモデル、
あるいはコンフィギュレーションに対するコンパイルが可能です。
いくつかのコンフィギュレーションは、通常はそのプラットフォーム上の
他のコンパイラとのコマンドラインに関するの互換世鬚箸襪燭
の特別なオプションを用意しています。
以下は 68000 シリーズのために定義された `-m' オプションです。
-m68000
-mc68000
68000 のためのコードを生成します。これは 68000
ベースのシステムに対して
コンフィギュレーションを行なったコンパイラのデフォルトです。
-m68020
-mc68020
(68000 ではなく) 68020 のためのコードを生成します。これは 68020
ベースの
システムに対してコンフィギュレーションを行なったコンパイラのデフォルト
です。
-m68881
浮動小数点演算のために 68881
命令を含んだ出力を行います。これはほとんどの 68020
ベースのシステムにおいて、コンパイラのコンフィギュレーション時に
-nfp を指定されなかった場合のデフォルトです。
-m68030
68030 のためのコードを生成します。これは 68030
ベースのシステムに対して
コンフィギュレーションを行なったコンパイラのデフォルトです。
-m68040
68040 のためのコードを生成します。これは 68040
ベースのシステムに対して
コンフィギュレーションを行なったコンパイラのデフォルトです。
-m68020-40
68040
のためのコードを生成しますが、新しい命令を使用しません。この結果とし
て得られるコードは、68020/68881, 68030, 68040
のいずれのシステムにおいても、 比較的高い税修鮖ちます。
-mfpa 浮動小数点演算のために Sun FPA 命令を含んだ出力を行います。
-msoft-float