[Contents] [Back] [Prev] [Up] [Next] [Forward]

GNU CC コマンド・オプション

GNU CC を起動すると、通常は、前処理（preprocessing）、コンパイル、アセンブル、リンクが行われます。「全体的（overall）オプション」によって、この一連の処理を中途の段階で停止することができます。例えば、 `-c' オプションはリンカを起動しないよう指示するものです。この場合、アセンブラによって生成されるオブジェクト・ファイルが出力となります。

他のオプションは、一連の処理の中の１つの段階に渡されるものです。オプションの中には、プリプロセッサを制御するものもあり、コンパイラ自体を制御するものもあります。また、アセンブラやリンカを制御するオプションもありますが、それらのほとんどは、ここではドキュメント化されていません。というのは、このようなオプションを使うことが必要になることはめったにないからです。

GNU CC において使うことのできるコマンドライン・オプションのほとんどは、 C のプログラムに対して役に立つものです。他の言語（通常は C++）においてのみ役に立つオプションの場合は、説明の中でその旨を明記します。ある特定のオプションの記述の中にソース言語に関する言及がなければ、そのオプションは、サポートされているすべての言語において使うことができます。

C++ のプログラムをコンパイルする際に使用する特殊なオプションの要約については、 See section C++ プログラムのコンパイル。

gcc プログラムは、オプションとファイル名をオペランドとして受け取ります。多くのオプションは、複数文字からなる名前を持ちます。このため、単一文字からなる名前を持つオプションを複数まとめてグループ化することはできません。 `-dr' は、 `-d -r' とはまったく別ものです。

オプションと他の引数とを混在させることができます。多くの場合、順序は意味を持ちません。同じ種類のオプションをいくつか使う場合には、順序が意味を持つようになります。例えば、 `-L' を複数回指定すると、ディレクトリは指定された順序で調べられます。

多くのオプションは、 `-f' もしくは `-W' で始まる長い名前を持ちます。例えば、 `-fforce-mem'、 `-fstrength-reduce'、 `-Wformat' 等です。これらのオプションのほとんどには、肯定形式と否定形式とがあります。 `-ffoo' というオプションがあるとすると、その否定形式は `-fno-foo' となります。このマニュアルでは、これら２つの形式のうち、デフォルトではないものだけをドキュメント化してあります。

オプションの要約

以下に、種類ごとにグループ化した形で、すべてのオプションの要約を掲げます。オプションの説明は、後続のセクションにあります。

全体的（overall）オプション

See section 出力の種類を制御するオプション.

-c  -S  -E  -o file  -pipe  -v  -x language

C 言語オプション

See section C の方言を制御するオプション.

-ansi  -fallow-single-precision  -fcond-mismatch  -fno-asm
-fno-builtin  -ffreestanding  -fhosted  -fsigned-bitfields  -fsigned-char
-funsigned-bitfields  -funsigned-char  -fwritable-strings
-traditional  -traditional-cpp  -trigraphs

C++ 言語オプション

See section C++ の方言を制御するオプション.

-fall-virtual  -fdollars-in-identifiers  -felide-constructors
-fenum-int-equiv  -fexternal-templates  -ffor-scope  -fno-for-scope
-fhandle-signatures  -fmemoize-lookups  -fname-mangling-version-n
-fno-default-inline  -fno-gnu-keywords -fnonnull-objects -fguiding-decls
-foperator-names  -fstrict-prototype  -fthis-is-variable
-ftemplate-depth-n  -nostdinc++  -traditional  +en

警告オプション

See section 警告を要求もしくは抑制するオプション.

-fsyntax-only  -pedantic  -pedantic-errors
-w  -W  -Wall  -Waggregate-return  -Wbad-function-cast
-Wcast-align  -Wcast-qual  -Wchar-subscript  -Wcomment
-Wconversion  -Werror  -Wformat
-Wid-clash-len  -Wimplicit -Wimplicit-int 
-Wimplicit-function-declarations -Wimport  -Winline
-Wlarger-than-len  -Wmain  -Wmissing-declarations
-Wmissing-prototypes  -Wnested-externs
-Wno-import  -Wold-style-cast  -Woverloaded-virtual  -Wparentheses
-Wpointer-arith  -Wredundant-decls  -Wreorder  -Wreturn-type  -Wshadow
-Wsign-compare  -Wstrict-prototypes  -Wswitch  -Wsynth
-Wtemplate-debugging  -Wtraditional  -Wtrigraphs
-Wundef  -Wuninitialized  -Wunused  -Wwrite-strings

デバッグ・オプション

See section ユーザ・プログラムもしくは GNU CC をデバッグするためのオプション.

-a  -ax  -dletters  -fpretend-float
-fprofile-arcs  -ftest-coverage
-g  -glevel  -gcoff  -gdwarf  -gdwarf-1  -gdwarf-1+  -gdwarf-2
-ggdb  -gstabs  -gstabs+  -gxcoff  -gxcoff+
-p  -pg  -print-file-name=library  -print-libgcc-file-name
-print-prog-name=program  -print-search-dirs  -save-temps

最適化オプション

See section 最適化を制御するオプション.

-fbranch-probabilities
-fcaller-saves  -fcse-follow-jumps  -fcse-skip-blocks
-fdelayed-branch   -fexpensive-optimizations
-ffast-math  -ffloat-store  -fforce-addr  -fforce-mem
-ffunction-sections  -finline-functions
-fkeep-inline-functions  -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  -O0  -O1  -O2  -O3

プリプロセッサ・オプション

See section プリプロセッサを制御するオプション.

-Aquestion(answer)  -C  -dD  -dM  -dN
-Dmacro[=defn]  -E  -H
-idirafter dir
-include file  -imacros file
-iprefix file  -iwithprefix dir
-iwithprefixbefore dir  -isystem dir
-M  -MD  -MM  -MMD  -MG  -nostdinc  -P  -trigraphs
-undef  -Umacro  -Wp,option

アセンブラ・オプション

See section アセンブラへのオプション渡し.

-Wa,option

リンカ・オプション

See section リンク処理用のオプション.

object-file-name  -llibrary
-nostartfiles  -nodefaultlibs  -nostdlib
-s  -static  -shared  -symbolic
-Wl,option  -Xlinker option
-u symbol

ディレクトリ・オプション

See section ディレクトリ探索のためのオプション.

-Bprefix  -Idir  -I-  -Ldir  -specs=file

ターゲット・オプション

See section ターゲット・マシンとコンパイラ・バージョンの指定.

-b machine  -V version

マシン依存オプション

See section ハードウェアのモデルとコンフィギュレーション.

M680x0 オプション
-m68000  -m68020  -m68020-40  -m68020-60  -m68030  -m68040
-m68060  -m5200  -m68881  -mbitfield  -mc68000  -mc68020  -mfpa
-mnobitfield  -mrtd  -mshort  -msoft-float  -malign-int

VAX オプション
-mg  -mgnu  -munix

SPARC オプション
-mcpu=cpu type
-mtune=cpu type
-mcmodel=code model
-malign-jumps=num  -malign-loops=num
-malign-functions=num
-m32  -m64
-mapp-regs  -mbroken-saverestore  -mcypress  -mepilogue
-mflat  -mfpu  -mhard-float  -mhard-quad-float
-mimpure-text  -mlive-g0  -mno-app-regs  -mno-epilogue
-mno-flat  -mno-fpu  -mno-impure-text
-mno-stack-bias  -mno-unaligned-doubles
-msoft-float  -msoft-quad-float  -msparclite  -mstack-bias
-msupersparc  -munaligned-doubles  -mv8

Convex オプション
-mc1  -mc2  -mc32  -mc34  -mc38
-margcount  -mnoargcount
-mlong32  -mlong64
-mvolatile-cache  -mvolatile-nocache

AMD29K オプション
-m29000  -m29050  -mbw  -mnbw  -mdw  -mndw
-mlarge  -mnormal  -msmall
-mkernel-registers  -mno-reuse-arg-regs
-mno-stack-check  -mno-storem-bug
-mreuse-arg-regs  -msoft-float  -mstack-check
-mstorem-bug  -muser-registers

ARM オプション
-mapcs-frame  -mapcs-26  -mapcs-32
-mlittle-endian  -mbig-endian  -mwords-little-endian
-mshort-load-bytes  -mno-short-load-bytes
-msoft-float  -mhard-float
-mbsd  -mxopen  -mno-symrename

MN10300 オプション
-mmult-bug
-mno-mult-bug

M32R/D オプション
-mcode-model=model type  -msdata=sdata type
-G num

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

RS/6000、PowerPC オプション
-mcpu=cpu type
-mtune=cpu type
-mpower  -mno-power  -mpower2  -mno-power2
-mpowerpc  -mno-powerpc
-mpowerpc-gpopt  -mno-powerpc-gpopt
-mpowerpc-gfxopt  -mno-powerpc-gfxopt
-mnew-mnemonics  -mno-new-mnemonics
-mfull-toc   -mminimal-toc  -mno-fop-in-toc  -mno-sum-in-toc
-mxl-call  -mno-xl-call  -mthreads  -mpe
-msoft-float  -mhard-float  -mmultiple  -mno-multiple
-mstring  -mno-string  -mupdate  -mno-update
-mfused-madd  -mno-fused-madd  -mbit-align  -mno-bit-align
-mstrict-align  -mno-strict-align  -mrelocatable
-mno-relocatable  -mrelocatable-lib  -mno-relocatable-lib
-mtoc  -mno-toc  -mtraceback  -mno-traceback
-mlittle  -mlittle-endian  -mbig  -mbig-endian
-mcall-aix  -mcall-sysv  -mprototype  -mno-prototype
-msim  -mmvme  -mads  -myellowknife  -memb
-msdata  -msdata=opt  -G num

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 オプション
-mabicalls  -mcpu=cpu type  -membedded-data
-membedded-pic  -mfp32  -mfp64  -mgas  -mgp32  -mgp64
-mgpopt  -mhalf-pic  -mhard-float  -mint64  -mips1
-mips2  -mips3  -mlong64  -mlong-calls  -mmemcpy
-mmips-as  -mmips-tfile  -mno-abicalls
-mno-embedded-data  -mno-embedded-pic
-mno-gpopt  -mno-long-calls
-mno-memcpy  -mno-mips-tfile  -mno-rnames  -mno-stats
-mrnames  -msoft-float
-m4650  -msingle-float  -mmad
-mstats  -EL  -EB  -G num  -nocpp

i386 オプション
-mcpu=cpu type
-march=cpu type
-mieee-fp  -mno-fancy-math-387
-mno-fp-ret-in-387  -msoft-float  -msvr3-shlib
-mno-wide-multiply  -mrtd  -malign-double
-mreg-alloc=list  -mregparm=num
-malign-jumps=num  -malign-loops=num
-malign-functions=num

HPPA オプション
-mbig-switch  -mdisable-fpregs  -mdisable-indexing  -mfast-indirect-calls
-mgas  -mjump-in-delay  -mlong-load-store  -mno-big-switch  -mno-disable-fpregs
-mno-disable-indexing  -mno-fast-indirect-calls  -mno-gas
-mno-jump-in-delay
-mno-long-load-store
-mno-portable-runtime  -mno-soft-float  -mno-space  -mno-space-regs
-msoft-float
-mpa-risc-1-0  -mpa-risc-1-1  -mportable-runtime
-mschedule=list  -mspace  -mspace-regs

Intel 960 オプション
-mcpu type  -masm-compat  -mclean-linkage
-mcode-align  -mcomplex-addr  -mleaf-procedures
-mic-compat  -mic2.0-compat  -mic3.0-compat
-mintel-asm  -mno-clean-linkage  -mno-code-align
-mno-complex-addr  -mno-leaf-procedures
-mno-old-align  -mno-strict-align  -mno-tail-call
-mnumerics  -mold-align  -msoft-float  -mstrict-align
-mtail-call

DEC Alpha オプション
-mfp-regs  -mno-fp-regs -mno-soft-float  -msoft-float
-malpha-as -mgas
-mieee  -mieee-with-inexact  -mieee-conformant
-mfp-trap-mode=mode  -mfp-rounding-mode=mode
-mtrap-precision=mode  -mbuild-constants
-mcpu=cpu type
-mbwx -mno-bwx -mcix -mno-cix -mmax -mno-max

Clipper オプション
-mc300  -mc400

H8/300 オプション
-mrelax  -mh -ms -mint32  -malign-300

SH オプション
-m1  -m2  -m3  -m3e  -mb  -ml  -mrelax

System V オプション
-Qy  -Qn  -YP,paths  -Ym,dir

V850 オプション
-mlong-calls -mno-long-calls -mep -mno-ep
-mprolog-function -mno-prolog-function -mspace
-mtda=n -msda=n -mzda=n
-mv850 -mbig-switch

コード生成オプション

See section コード生成規約に対するオプション.

-fcall-saved-reg  -fcall-used-reg
-ffixed-reg  -finhibit-size-directive
-fcheck-memory-usage  -fprefix-function-name
-fno-common  -fno-ident  -fno-gnu-linker
-fpcc-struct-return  -freg-struct-return
-fshared-data  -fpic  -fPIC  -fexceptions
-fshort-enums  -fshort-double  -fvolatile  -fvolatile-global
-fverbose-asm  -fpack-struct  -fstack-check  +e0  +e1

出力の種類を制御するオプション

コンパイル処理には、４つの段階が含まれます。それは、前処理、狭義のコンパイル処理、アセンブル処理、リンク処理であり、常にこの順序で実行されます。最初の３つの段階は、個々のソース・ファイルに対して適用され、オブジェクト・ファイルを生成することによって終了します。リンク処理では、すべてのオブジェクト・ファイル（新たにコンパイルされたオブジェクト・ファイルと入力として指定されたオブジェクト・ファイル）を結合して、１つの実行可能ファイルを生成します。

入力ファイルが与えられると、そのファイル名の接尾語が、実行されるコンパイル処理の種類を決定します。

file.c: 前処理が実行されなければならない C のソース・コード
file.i: 前処理が実行されてはならない C のソース・コード
file.ii: 前処理が実行されてはならない C++ のソース・コード
file.m: Objective-C のソース・コード。 Objective-C のプログラムが動作するようにするためには、ライブラリ `libobjc.a' をリンクしなければならないことに注意してください。
file.h: （コンパイルもリンクも実行されない）C のヘッダ・ファイル
file.cc
file.cxx
file.cpp
file.C: 前処理が実行されなければならない C++ のソース・コード。 `.cxx' では、最後の２つの文字は字義どおり `x' でなければならないことに注意してください。同様に、 `.C' は字義どおり大文字の C を指しています。
file.s: アセンブラ・コード
file.S: 前処理が実行されなければならないアセンブラ・コード
その他: リンク処理にそのまま入力されるオブジェクト・ファイル。認識可能な接尾語を持たないファイル名は、すべてこのように扱われます。

`-x' オプションによって、入力の言語を明示的に指定することができます。

-x language

後続の入力ファイルの言語を、（ファイル名の接尾語によって決まる、デフォルトの言語をコンパイラに選択させるのではなく） language によって明示的に指定します。このオプションは、後続の入力ファイルのうち、次の `-x' オプションよりも前に指定されたものすべてに対して適用されます。 language に指定することのできる値は以下のとおりです。

c  objective-c  c++
c-header  cpp-output  c++-cpp-output
assembler  assembler-with-cpp

-x none

言語の指定をすべて無効にします。これにより、後続のファイルは（`-x' オプションがまったく使われない場合のように）ファイル名の接尾語にしたがって処理されます。

（広義の）コンパイル処理の一部の段階だけを実行したい場合には、 `-x' オプション（もしくは、ファイル名の接尾語）を使って、どの段階から始めるかを、また、 `-c'、 `-S'、 `-E' のうち１つのオプションを使って、どの段階で停止すべきかを gcc に対して指示することができます。組み合わせによっては（例えば、 `-x cpp-output -E'） gcc に対して何も実行しないよう指示したことになるということに注意してください。

-c: ソース・ファイルのコンパイル、もしくは、アセンブルを行いますが、リンクは行いません。リンク処理段階は実行されません。最終的な出力形態は、個々のソース・ファイルに対応するオブジェクト・ファイルとなります。デフォルトでは、ソース・ファイルに対応するオブジェクト・ファイルの名前は、ソース・ファイル名の接尾語 `.c'、 `.i'、 `.s' 等を `.o' によって置き換えることによって作られます。接尾語が認識されない入力ファイルは、コンパイルもアセンブルも必要とされないので、無視されます。
-S: 狭義のコンパイル処理段階の後に停止し、アセンブル処理を実行しません。出力形態は、指定された入力ファイルのうちアセンブラ・コードで記述されていないものに対するアセンブラ・コードのファイルとなります。デフォルトでは、ソース・ファイルに対応するアセンブラ・ファイルの名前は、ソース・ファイル名の接尾語 `.c'、 `.i' 等を `.s' によって置き換えることによって作られます。コンパイルの必要がない入力ファイルは無視されます。
-E: 前処理段階の後に停止し、狭義のコンパイル処理を実行しません。出力形態は、前処理済みのソース・コードとなり、これは標準出力に出力されます。前処理の必要がない入力ファイルは無視されます。
-o file: file によって指定されるファイルを出力先とします。これは、生成される出力の種類に関係なく適用されます。出力が、実行可能ファイル、オブジェクト・ファイル、アセンブラ・ファイル、前処理済みの C コードのいずれであっても、無関係に適用されます。出力ファイルは１つしか指定できないので、複数の入力ファイルをコンパイルする際に `-o' を使うのは、出力として実行可能ファイルを生成しようとしている場合を除けば、意味のないことです。 `-o' が指定されないと、デフォルトでは、実行可能ファイルは `a.out' に、 `source.suffix' に対応するオブジェクト・ファイルは `source.o' に、 `source.suffix' に対応するアセンブラ・ファイルは `source.s' に、また、すべての前処理済みの C のソースは標準出力に、それぞれ出力されます。
-v: （広義の）コンパイル処理の各段階において実行されたコマンドを（標準エラー出力に）表示します。また、コンパイラ・ドライバ・プログラム、プリプロセッサ、狭義のコンパイラの各バージョン番号も表示します。
-pipe: （広義の）コンパイル処理の各段階の間で通信を行うのに、一時ファイルではなくパイプを使用します。これは、パイプからの読み込みができないアセンブラを持つシステムでは正しく機能しません。 GNU アセンブラを使えば、まったく問題がありません。

C++ プログラムのコンパイル

C++ のソース・ファイルは、慣習的に `.C'、 `.cc'、 `cpp'、 `.cxx' のいずれかを接尾語として使います。また、前処理済みの C++ ファイルは、 `.ii' という接尾語を使います。 C のプログラムをコンパイルするのと同一の方法で（通常は、 gcc という名前で）コンパイラを呼び出した場合でも、 GNU CC はこのような名前を持つファイルを認識して、それを C++ のプログラムとしてコンパイルします。

しかしながら、 C++ のプログラムは、 C++ 言語を理解するコンパイラに加えて、クラス・ライブラリを必要とすることがしばしばあります。また、状況によっては、標準入力から受け取ったプログラムをコンパイルしたい場合もあるでしょうし、 C++ プログラムであることを示す接尾語を持たないファイルをコンパイルしたい場合もあるでしょう。 g++ は、デフォルトの言語を C++ に設定して GNU CC を呼び出すプログラムであり、 C++ ライブラリとのリンクを自動的に指定します。 (1) 多くのシステムでは、スクリプト g++ は c++ という名前でもインストールされています。

C++ プログラムをコンパイルする場合に指定することのできるオプションは、任意の言語で記述されたプログラムをコンパイルするのに使う多くのコマンドライン・オプション、 C とその関連言語に対して意味を持つコマンドライン・オプション、 C++ プログラムに対してのみ意味を持つコマンドライン・オプションです。 C の関連言語に対するオプションの説明については、 See section C の方言を制御するオプション。 C++ プログラムに対してのみ意味を持つオプションの説明については、 See section C++ の方言を制御するオプション。

C の方言を制御するオプション

以下のオプションは、コンパイラが受け付ける C （あるいは、 C++ や Objective C のように、 C から派生した言語）の方言を制御するものです。

-ansi

すべての ANSI 標準 C プログラムをサポートします。これは、キーワード asm、 inline、 typeof や、使用しているシステムの種類を識別する unix や vax 等の事前定義マクロ（predefined macro）のように、 ANSI C とは互換性のない GNU C の特定の機能を無効にします。また、これにより、望ましくなく、めったに使われることもない ANSI の３文字表記（trigraph）機能が使えるようになり、 C++ 方式の `//' によるコメントが認識されなくなります。代替キーワード __asm__、 __extension__、 __inline__、 __typeof__ は、 `-ansi' が指定された場合でも、引き続き機能します。もちろん、 ANSI C プログラムの中でこれらを使いたいということはないでしょうが、 `-ansi' が指定されたコンパイルにおいて組み込まれるかもしれないヘッダ・ファイルの中でこれらを使うと役に立ちます。 __unix__ や __vax__ のような代替事前定義マクロもまた、 `-ansi' の指定の有無にかかわらず、利用することができます。 `-ansi' オプションを使っても、非 ANSI プログラムが理由もなく拒絶されるわけではありません。拒絶されるようにするためには、 `-ansi' に加えて `-pedantic' が必要です。 See section 警告を要求もしくは抑制するオプション。 `-ansi' オプションが使われている時には、マクロ __STRICT_ANSI__ が事前定義されます。ヘッダ・ファイルの中には、このマクロが定義されていると、 ANSI 標準が必要としない特定の関数の宣言や特定のマクロの定義を行わなくなるものがあります。これらの関数やマクロの名前を他の用途に使う可能性のあるプログラムの邪魔になるのを回避するためです。 `-ansi' が使われている時には、関数 alloca、 abort、 exit、 _exit は組み込み関数ではありません。

-fno-asm

asm、 inline、 typeof をキーワードとして認識しません。これにより、ソース・コードの中でこれらの単語を識別子として使うことができます。これらの代わりに、キーワード __asm__、 __inline__、 __typeof__ を使うことができます。 `-ansi' は、暗黙のうちに `-fno-asm' を意味します。 C++ では、 asm と inline は標準のキーワードなので、このオプションは typeof キーワードにだけ影響を与えます。 `-fno-gnu-keywords' フラグは、 headof のような C++ に固有の他の拡張キーワードも使えないようにするので、これを代わりに使うと良いでしょう。

-fno-builtin

名前の先頭が２つのアンダースコアで始まらない組み込み関数を認識しません。現在のところ、影響を受ける関数には、 abort、 abs、 alloca、 cos、 exit、 fabs、 ffs、 labs、 memcmp、 memcpy、 sin、 sqrt、 strcmp、 strcpy、 strlen があります。 GCC は通常、特定の組み込み関数をより効率的に処理するために特殊なコードを生成します。例えば、 alloca の呼び出しは、スタックを直接調整する単一の命令になることがあります。また、 memcpy の呼び出しは、コピー命令のループをインライン展開したものになることがあります。結果として生成されるコードは、多くの場合、より小さく、かつ、より速いものになりますが、関数を呼び出している部分が実際にはもはや関数呼び出しには見えなくなるため、その関数呼び出しに対してブレイクポイントを設定することはできなくなりますし、異なるライブラリとリンクすることによって、その関数の振る舞いを変更することもできなくなります。 `-ansi' オプションは、 alloca や ffs が組み込み関数となることを防ぎます。というのは、これらの関数は ANSI 標準においては意味を持たないからです。

-fhosted

コンパイル処理は付属環境（hosted environment）で実行されるものと断定します。これは、暗黙のうちに `-fbuiltin' を意味します。付属環境（hosted environment）とは、標準ライブラリ全体が利用可能であり、かつ、 main が int 型の戻り値を持つ環境のことです。カーネルを除外すれば、ほとんどすべての環境がこれに当てはまります。このオプションは、 `-fno-freestanding' と同等です。

-ffreestanding

コンパイル処理は自立環境（freestanding environment）で実行されるものと断定します。これは、暗黙のうちに `-fno-builtin' を意味します。自立環境（freestanding environment）とは、標準ライブラリが存在しない可能性があり、かつ、プログラムが必ずしも main から開始されるとは限らない環境のことです。最も明白な例は、 OS のカーネルです。このオプションは、 `-fno-hosted' と同等です。

-trigraphs

ANSI C の３文字表記（trigraph）をサポートします。脳が破壊されているとしか思えない３文字表記のことを知りたい人はいないでしょう。 `-ansi' オプションは、暗黙のうちに `-trigraphs' を意味します。

-traditional

伝統的な C コンパイラが持ついくつかの特性をサポートするよう試みます。具体的には、

すべての extern 宣言は、たとえそれが関数定義の内部において記述された場合でも、広域的に有効になります。これには、暗黙のうちに行われる関数宣言も含まれます。
新しいキーワードである typeof、 inline、 signed、 const、 volatile は認識されません（__typeof__、 __inline__ のような代替キーワードを使うことはできます）。
ポインタと整数との比較は常に許されます。
整数型である unsigned short と unsigned char は unsigned int に拡張されます。
有効範囲外の浮動小数点リテラルはエラーではありません。
例えば `0xe-0xd' のように、 ANSI では不当な１個の前処理数（preprocessing number）とみなされる構成が、式として扱われます。
文字列「定数」は必ずしも定数ではありません。それは書き込み可能な領域に置かれ、見掛け上は同一の複数の定数が別個に割り当てられます（これは `-fwritable-strings' が持つ効果と同じです）。
register 宣言されていないすべての自動変数は、 longjmp により保存されます。通常、 GNU C は ANSI C に従うので、 volatile 宣言されていない自動変数の内容は破壊される可能性があります。
文字のエスケープ・シーケンスである `\x' や `\a' 等は、それぞれ字義どおりの文字 `x' や `a' として評価されます。 `-traditional' を指定しないと、 `\x' は文字の 16 進数表記の接頭語となり、 `\a' はベルを表すことになります。
C++ のプログラムでは、 `-traditional' を指定すると、 this への代入が許されるようになります（オプション `-fthis-is-variable' も同様の効果を持ちます）。

GNU C の組み込み関数として通常使われている名前を、プログラムの中で別の目的で使うのであれば、 `-traditional' だけではなく `-fno-builtin' も使うと良いでしょう。 ANSI C の特徴に依存しているヘッダ・ファイルを組み込む場合には、 `-traditional' を使うことはできません。いくつかのベンダは、 ANSI C ヘッダ・ファイルを組み込んだシステムの提供を始めています。このようなシステム上では、システム・ヘッダを組み込むファイルをコンパイルする際に `-traditional' を使うことはできません。 `-traditional' オプションは、 `-traditional-cpp' オプションも有効にします。これについては、次に説明します。

-traditional-cpp

伝統的な C プリプロセッサが持ついくつかの特性をサポートするよう試みます。具体的には、

コメントは空白に変換されるのではなく、完全に消去されます。これにより、古くから行われているトークンの連結ができるようになります。
前処理の指示子（preprocessing directive）の中の `#' シンボルは、行の先頭の文字でなければなりません。
マクロ引数は、マクロ定義内の文字列定数の中でも認識されます（このようなコンテキストの中にマクロ引数が現れる場合には、その値は文字列化されますが、引用符は付加されません）。プリプロセッサは常に、文字列定数は改行をもって終了するものとみなします。
`-traditional' を使うと、事前定義マクロ __STDC__ は定義されませんが、 __GNUC__ は定義されます（というのは、 __GNUC__ が示唆する GNU の拡張機能は `-traditional' による影響を受けないからです）。 `-traditional' の指定の有無によって異なる機能を持つようなヘッダ・ファイルを書く必要がある場合には、両方の事前定義マクロをテストすることによって４つの状況を区別することができます。ここで４つの状況とは、 GNU C、伝統的な GNU C、他のANSI C コンパイラ、他の旧式の C コンパイラがそれぞれ使われている状況のことです。 `-traditional' を使うと、事前定義マクロ __STDC_VERSION__ も定義されません。これらの事前定義マクロ、および、その他の事前定義マクロに関する詳細については、 See section `Standard Predefined Macros' in The C Preprocessor。
プリプロセッサは、（改行が `\' によってエスケープされていなければ）文字列定数は改行をもって終了するものとみなします（`-traditional' を指定しなければ、文字列定数は、入力されたとおりに改行文字を含むことができます）。

-fcond-mismatch

条件式の第２引数と第３引数に、異なる型を使うことができるようにします。このような式の値は void です。

-funsigned-char

型 char を、 unsigned char のように無符号（unsigned）にします。個々の種類のマシンごとに、 char のデフォルトがあります。デフォルトが unsigned char のようになる場合と signed char のようになる場合の２つに１つです。理想的には、移植性のあるプログラムでは、オブジェクトの符号の有無に依存するような場合には常に、 signed char もしくは unsigned char のいずれかを使うべきです。しかし、多くのプログラムは既に単なる char を使って書かれていて、対象となるマシンによって、それが有符号もしくは無符号になるものと期待しています。このオプション、および、これの逆のオプションを使うことによって、期待とは異なるデフォルトを持つ環境でもそのようなプログラムが動作するようにすることができます。型 char は、たとえその振る舞いが signed char と unsigned char のいずれか一方と同様であるにしても、常にこれらの型とは異なる別個の型です。

-fsigned-char

型 char を、 signed char のように有符号（signed）にします。これは、 `-funsigned-char' の否定形式である `-fno-unsigned-char' と同等であることに注意してください。同様に、オプション `-fno-signed-char' は `-funsigned-char' と同等です。 (2)

-fsigned-bitfields

-funsigned-bitfields

-fno-signed-bitfields

-fno-unsigned-bitfields

これらのオプションは、ビット・フィールドの宣言において signed と unsigned のいずれも使われていない場合に、ビット・フィールドが有符号であるか無符号であるかを制御するものです。デフォルトでは、他の場合との整合性の理由で、このようなビット・フィールドは有符号になります。 int のような基本的な整数型は有符号の型です。しかし、 `-traditional' が使われると、いかなる場合でもビット・フィールドはすべて無符号になります。

-fwritable-strings

文字列定数を書き込み可能なデータ・セグメントに置きます。また、見掛け上同一の文字列を複数持つことができるようにします。これは、文字列定数の中への書き込みができると想定している古いプログラムとの互換性のためのものです。オプション `-traditional' もこれと同じ効果を持ちます。文字列定数の中に書き込みを行うというのは、非常に良くない考えです。「定数」の内容は不変であるべきです。

-fallow-single-precision

`-traditional' を指定してコンパイルする場合でも、単精度の数学演算を倍精度に拡張しません。伝統的な K&R C では、オペランドのサイズにかかわらず、すべての浮動小数点演算は倍精度に拡張されます。コンパイルの対象となるアーキテクチャ上では、単精度の方が倍精度よりも高速であることがありえます。 `-traditional' を使わなければならないが、オペランドが単精度の場合には単精度演算を使用したいのであれば、このオプションを使ってください。このオプションは、（デフォルトの）ANSI C や GNU C の慣例に従ってコンパイルする場合には、まったく効果を持ちません。

C++ の方言を制御するオプション

このセクションでは、 C++ プログラムに対してのみ意味を持つコマンドライン・オプションを説明します。しかし、プログラムが記述された言語が何であれ、ほとんどの GNU コンパイラ・オプションを使うことができます。例えば、 firstClass.C というファイルを以下のようにコンパイルすることがあるかもしれません。

g++ -g -felide-constructors -O -c firstClass.C

この例では、 `-felide-constructors' だけが C++ プログラム専用のオプションです。これ以外のオプションは、 GNU CC でサポートされている任意の言語において使うことができます。

以下に、 C++ プログラムをコンパイルする場合のみを対象とするオプションの一覧を示します。

-fno-access-control

すべてのアクセス・チェックを行わないようにします。このオプションは、主としてアクセス制御コード（access control code）のバグを回避するのに役に立ちます。

-fall-virtual

可能であれば、すべてのメンバ関数を、暗黙のうちに仮想関数として扱います。（生成関数とメンバ演算子 new、 delete を除く）すべてのメンバ関数は、それらが現れるところではそのクラスの仮想関数として扱われます。このことは、これらのメンバ関数に対するすべての呼び出しが、内部的な仮想関数テーブルを通じて行われることを意味するわけではありません。状況によっては、コンパイラが、ある与えられた仮想関数への呼び出しを直接行うことができると決定することができます。このような状況においては、どのような場合でも呼び出しは直接行われます。

-fcheck-new

割り当てられた記憶域の内容の変更を試みる前に、演算子 new により返されたポインタがヌル・ポインタでないことをチェックします。現在の Working Paper の要件では、演算子 new は決してヌル・ポインタを返してはならないとされているので、このチェックは普通は必要ありません。

-fconserve-space

初期化されない広域変数、もしくは、実行時に初期化される広域変数を、 C のように共通セグメント（common segment）に置きます。これにより、重複する定義の有無を診断するのを犠牲にして、実行ファイルの中の領域が節約されることになります。このフラグを指定してコンパイルを行ってから以降、プログラムが main() の完了後に不可解な異常終了をするようになったのであれば、あるオブジェクトの定義が２個所にあって、それらが１つにまとめられてしまった一方で、そのオブジェクトの破棄が２回実行されているのかもしれません。

-fdollars-in-identifiers

識別子の中に `$' があっても、これを受け付けます。オプション `-fno-dollars-in-identifiers' を指定して、 `$' の使用を明示的に禁止することもできます（GNU C は、ほとんどのターゲット・システム上において、デフォルトで `$' を受け付けます。しかし、若干例外があります）。伝統的な C では、識別子の一部に文字 `$' を含めることができました。しかし、 ANSI C および ANSI C++ では、識別子の中に `$' を使うことを禁止しています。

-fenum-int-equiv

古い C++ のように int 型から列挙型への暗黙の変換を許します。現在の C++ では、 enum から int への変換は許されますが、逆の変換は許されません。

-fexternal-templates

テンプレートのインスタンス生成が、 `#pragma interface' と `#pragma implementation' に従って行われるようにします。テンプレートのインスタンスは、テンプレート定義の存在箇所に応じて、生成されたり生成されなかったりします。詳細については、 See section テンプレート・インスタンスの存在箇所。このオプションを使用することには賛成できません。

-falt-external-templates

-fexternal-templates に似ていますが、テンプレートのインスタンスは、最初にそのインスタンスが生成される箇所に応じて、生成されたり生成されなかったりします。詳細については、 See section テンプレート・インスタンスの存在箇所。このオプションを使用することには賛成できません。

-ffor-scope

-fno-for-scope

-ffor-scope が指定されると、 for 文の初期設定式（for-init-statement）の中で宣言された変数のスコープは、 C++ のドラフト標準によって指定されるとおり、その `for' ループ自体に制限されます。 -fno-for-scope が指定されると、 for 文の初期設定式の中で宣言された変数のスコープは、古いバージョンの gcc や他の（伝統的な） C++ の実装がそうであるように、その for 文を包含するスコープの終端にまで拡大されます。どちらのフラグも指定されない場合のデフォルトは標準に従います。ただし、標準を基準にすると、不当であったり、異なる振る舞いをしたりするような旧式のコードも許されます。このような旧式のコードに対しては、警告が出力されます。

-fno-gnu-keywords

classof、 headof、 signature、 sigof、 typeof をキーワードとして認識しません。よって、プログラムのソース・コードの中でこれらの単語を識別子として使うことができます。これらの代わりとして、キーワード __classof__、 __headof__、 __signature__、 __sigof__、 __typeof__ を使うことができます。 `-ansi' は、暗黙のうちに `-fno-gnu-keywords' を意味します。

-fguiding-decls

ある関数テンプレートの潜在的なインスタンスと同一の型を持つ関数宣言を、それが通常の関数ではなく、その関数テンプレートのインスタンスを宣言しているかのように扱います。その翻訳単位（ターゲット・システムが弱いシンボル（weak symbol）をサポートしていれば、別の翻訳単位でも可）の中において、後にその関数の定義が与えられた場合には、その定義が使用されます。その関数の定義が与えられない場合には、そのテンプレートのインスタンスが生成されます。この振る舞いは、 1996 年の９月に案内宣言（guiding declaration）が削除されるよりも前の C++ 言語の仕様を反映しています。このオプションは、暗黙のうちに `-fname-mangling-version-0' を意味しており、他の名前マングル処理（name mangling）のバージョンではうまく機能しません。

-fno-implicit-templates

暗黙のうちに（つまり、使用されることによって）インスタンス生成されるテンプレートのコードを決して出力しません。明示的なインスタンス生成のコードだけを出力します。詳細については、See section テンプレート・インスタンスの存在箇所。

-fhandle-signatures

抽象型を指定するための signature キーワードと sigof キーワードを認識します。デフォルト（`-fno-handle-signatures'）では、これらのキーワードは認識されません。 See section シグニチャを使った型の抽象化。

-fhuge-objects

１つの `short int' で表すことのできるサイズを超えるオブジェクトに対する仮想関数の呼び出しをサポートします。デフォルトでは、ユーザはこのフラグを使うべきではありません。このフラグを使う必要がある場合には、コンパイラがその旨知らせてくれます。ソース・コードの一部をこのフラグを指定してコンパイルするのであれば、（もし C++ ライブラリを使っているのであれば、そのライブラリのソース・コードも含めて） すべてのソース・コードをこのフラグを指定してコンパイルしなければなりません。このフラグは、 -fvtable-thunks を指定してコンパイルをする場合には役に立ちません。

-fno-implement-inlines

領域を節約するために、 `#pragma implementation' により制御されるインライン関数に対して、その関数のインライン展開されないコピーを出力しません。このような関数が、呼び出されているところすべてにおいてインライン展開されるわけではない場合、リンカのエラーが発生することになります。

-fmemoize-lookups

-fsave-memoized

より高速にコンパイルするために、発見的方法（heuristics）を使用します。発見的方法はデフォルトでは使用可能ではありません。というのは、それは特定の入力ファイルに対してのみ効果があるからです。そのような入力ファイル以外では、コンパイル速度はより遅くなります。あるメンバ関数の呼び出し（もしくは、あるデータ・メンバへの参照）のコードをコンパイラが最初に構築する時、コンパイラは、 (1) そのクラスによるその名前のメンバ関数の実装の有無の決定 (2) 呼び出すべきメンバ関数の解決（これには、どのような種類の型変換を行う必要があるかを解決することが含まれます） (3) そのメンバ関数の呼び出し側に対する可視性（visibility ）のチェックを行わなければなりません。これらはすべて、コンパイル処理をさらに遅くすることになります。通常は、そのメンバ関数に対する呼び出し（もしくは、そのデータ・メンバへの参照）が２度目に行われる時に、コンパイラは、この同じ長い過程を再び実行しなければなりません。このことは、

cout << "This " << p << " has " << n << " legs.\n";

のようなコードがある場合に、上記の３つのステップがすべて６回実行されることを意味します。ソフトウェア・キャッシュを使うと、「ヒット（hit）」によりこのコストは大きく減少します。残念なことに、キャッシュを使うと、実装しなければならない機構がもう１つ増えることになり、それ自体のオーバーヘッドを被ることになります。 `-fmemoize-lookups' は、このソフトウェア・キャッシュを使用可能にします。メンバやメンバ関数に対するアクセス権限（可視性（visibility））は関数のコンテキストによって変わるかもしれないので、 G++ はキャッシュを破棄（flush）する必要がある可能性があります。 `-fmemoize-lookups' フラグを指定すると、コンパイルされる個々の関数ごとに、キャッシュは破棄（flush）されます。 `-fsave-memoized' フラグは、同じソフトウェア・キャッシュを使用可能にしますが、最後にコンパイルされた関数のコンテキストにおけるアクセス権限と次にコンパイルされる関数のアクセス権限とが同一であるとコンパイラが決定した場合には、コンパイラはそのキャッシュを維持します。これは、同一のクラスに対して多くのメンバ関数を定義する場合に最も役に立ちます。他のクラスのフレンドになっているメンバ関数を除外すれば、個々のメンバ関数はお互いにまったく同一のアクセス権限を持っているので、キャッシュを破棄（flush）する必要はありません。これらのフラグを実装しているコードは使い物にならなくなってきました。これらのフラグを使うのはおそらく避けた方が良いでしょう。

-fstrict-prototype

`extern "C"' の結合指定において、引数が指定されていない `int foo ();' のような関数宣言は、引数を取らない関数を宣言しているものとして扱います。通常、そのような宣言は、 C の場合と同様、関数 foo が任意の組み合わせの引数を取ることができるということを意味します。 `-pedantic' は、 `-fno-strict-prototype' の指定によって無効にされない限り、暗黙のうちに `-fstrict-prototype' を意味します。このフラグはもはや、 C++ 結合における宣言には影響を与えることはありません。

-fname-mangling-version-n

名前がマングル（mangle）される方法を制御します。バージョン 0 は、バージョン 2.8 より前の g++ と互換性があります。バージョン 1 がデフォルトです。バージョン 1 では、関数テンプレートの正しいマングル処理（mangling）ができるようになります。例えば、以下のような宣言が与えられた場合、バージョン 0 のマングル処理（mangling）では、 foo<int, double> と foo<int, char> をマングル（mangle）することができません。

template <class T, class U> void foo(T t);

-fno-nonnull-objects

参照は正当なオブジェクトを参照するよう初期化されていると想定しません。現在の C++ Working Paper は、ヌル参照（null reference）を禁止していますが、ヌル参照に依存する古いコードが存在するかもしれません。 `-fno-nonnull-objects' を使って、チェックを有効にすることができます。現在のところ、コンパイラは、仮想基底クラスへの変換に際してのみこのチェックを実行します。

-foperator-names

演算子名キーワード and、 bitand、 bitor、 compl、 not、 or、 xor を、それぞれの名前が指すシンボルの同義語として認識します。 `-ansi' は、暗黙のうちに `-foperator-names' を意味します。

-fthis-is-variable

this への代入を許します。ユーザ定義による空き記憶域管理が C++ に組み込まれたために、 `this' への代入は時代錯誤になってしまいました。したがって、デフォルトでは、クラスのメンバ関数の中で this に対して代入を行うのは不当です。言い換えると、 GNU C++ は、クラス X のメンバ関数の中での `this' を、型 `X *' の非ロケータ値（non-lvalue）として扱います。しかし、古いコードとの互換性のために、 `-fthis-is-variable' を指定して、 `this' への代入を正当なものとすることができます。

-fvtable-thunks

仮想関数のディスパッチ・テーブル（`vtable'）を実装するのに「サンク」を使います。伝統的な（cfront 方式の） vtable の実装方法では、その関数へのポインタと、呼び出し箇所における `this' ポインタの調整に使われる２つのオフセットとを格納していました。これよりも新しい実装では、必要な調整を行った後に対象となる関数を呼び出す「サンク」関数へのポインタを１つ格納します。このオプションは、 vtable の生成を制御する発見的方法も使用可能にします。あるクラスが、インライン指定されていない仮想関数を１つでも持っていれば、そのような関数のうち最初のものを含む翻訳単位の中に vtable が出力されます。

-ftemplate-depth-n

テンプレート・クラスのインスタンス生成の最大の深さを n に設定します。テンプレートのインスタンス生成の深さの制限は、テンプレート・クラスのインスタンス生成時に無限の再帰を検出するために必要です。 ANSI/ISO C++ に適合するプログラムは、最大の深さが 17 よりも大きいことをあてにしてはなりません。

-nostdinc++

ヘッダ・ファイルを探す際に C++ に固有の標準ディレクトリを調べません。しかし、その他の標準ディレクトリは調べます（このオプションは、 C++ ライブラリを構築する時に使われます）。

-traditional

このオプションは、 C++ プログラムに対して（C と C++ の両方に適用される効果に加えて） `-fthis-is-variable' と同等の効果を持ちます。 See section C の方言を制御するオプション。

さらに加えて、以下の最適化オプション、警告オプション、コード生成オプションが、 C++ プログラムに対してのみ意味を持ちます。

-fno-default-inline: クラス・スコープの中で定義された関数に対して `inline' が指定されていると想定しません。 See section 最適化を制御するオプション。
-Wold-style-cast
-Woverloaded-virtual
-Wtemplate-debugging: C++ プログラムに対してのみ適用される警告です。 See section 警告を要求もしくは抑制するオプション。
-Weffc++: Scott Myers 著「Effective C++」に記されているいくつかのスタイル規則に対する違反に対して警告を出力します。
+en: cfront 1.x と互換性のある流儀で、仮想関数の定義がどのように使われるかを制御します。 See section コード生成規約に対するオプション。

警告を要求もしくは抑制するオプション

警告とは、本質的には誤りではないが、危険であったり誤りのある可能性を示唆していたりする構文（construction）を報告する診断メッセージです。

`-W' で始まるオプションを指定することで、多くの特定の警告を要求することができます。例えば、暗黙的な宣言に対する警告を要求するには `-Wimplicit' を指定します。これらの特定の警告オプションのそれぞれには、 `-Wno-' で始まる、警告を出力させないための否定形式があります。例えば、 `-Wno-implicit' です。このマニュアルでは、これら２つの形式のうち、デフォルトではないものだけを載せてあります。

以下のオプションは、 GNU CC により生成される警告の量と種類を制御します。

-fsyntax-only

ソース・コードに構文エラーがあるか否かをチェックするだけで、それ以上のことは一切行いません。

-pedantic

厳密な ANSI 標準 C により要求される警告をすべて出力します。禁止されている拡張機能を使うプログラムをすべて拒絶します。正当な ANSI 標準 C プログラムであれば、このオプションの指定の有無にかかわらず正しくコンパイルされるはずです（まれに、 `-ansi' オプションを必要とするものがあります）。しかし、このオプションが指定されないと、特定の GNU 拡張機能や伝統的な C の機能もまたサポートされることになります。このオプションが指定されると、これらは拒絶されます。 `-pedantic' を指定しても、名前の先頭と末尾に `__' が付く代替キーワードの使用に関しては、警告メッセージは出力されません。また、 __extension__ の後ろに記述される式については、 `-pedantic' による警告は無効化されます。しかし、このような逃げ道を使うのは、システム・ヘッダ・ファイルのみであるべきです。アプリケーション・プログラムの中でこれを使うのは避けるべきです。 See section 代替キーワード。このオプションは、何かの役に立つことを意図したものではありません。このような機能がないと「GNU CC は ANSI 標準を正しくサポートしていない」と主張し始める学者ぶった人々を黙らせるためだけの目的で存在するものです。ユーザの中には、厳密な ANSI C に対するプログラムの適合性をチェックするために `-pedantic' を使おうとする人々もいます。このような人々は、このオプションが彼らの期待どおりに振る舞わないことに、やがて気が付くことになります。それは、いくつかの非 ANSI 的な慣習を見つけ出してはくれますが、そのようなものすべてを見つけ出すわけではありません。 ANSI C が診断メッセージ（diagnostic）の出力を要求するようなものだけが見つけ出されます。場合によっては、 ANSI C に対するあらゆる非適合を報告してくれる機能があると、役に立つことがあるかもしれません。しかし、このような機能を実装するとなるとかなりの量の追加作業が必要になるでしょうし、その機能は `-pedantic' とは大きく異なるものになるでしょう。それよりもむしろ、 GNU C の拡張機能を活用して、他のコンパイラでの制限については無視することをお勧めします。特定のスーパー・コンピュータやすたれてしまった小規模コンピュータを除外すれば、 GNU CC のブートストラップを行うという理由のほかに、 GNU CC 以外の C コンパイラを使う理由は、ますます少なくなってきています。

-pedantic-errors

警告ではなくエラーが出力される点を除けば、 `-pedantic' と同様です。

-w

すべての警告メッセージの出力を禁止します。

-Wno-import

`#import' の使用に関する警告メッセージの出力を禁止します。

-Wchar-subscripts

配列の添字の型が char である場合に警告を出力します。これはよくあるエラー原因です。いくつかのマシンではこの型が有符号であるということをプログラマがしばしば忘れるからです。

-Wcomment

コメントの開始を示す `/*' という文字の並びが `/*' 式のコメントの中に現れた場合に、常に警告を出力します。また、 `//' 式のコメントの中において、バックスラッシュの直後に改行がある場合にも、常に警告を出力します。

-Wformat

printf、 scanf 等の呼び出しをチェックして、提供されている引数の型が、指定された書式文字列に対して適切であることを確認します。

-Wimplicit-int

宣言に型が指定されていない場合に警告を出力します。

-Wimplicit-function-declarations

宣言される前に関数が使われている場合に、常に警告を出力します。

-Wimplicit

`-Wimplicit-int' `-Wimplicit-function-declaration' と同一です。

-Wmain

`main' の型に疑わしい点がある時に警告を出力します。 `main' は、 int 型の値を返し、適切な型の引数を０（ゼロ）個、２個、もしくは、３個取る、外部結合の関数でなければなりません。

-Wparentheses

特定のコンテキストにおいて丸括弧 () が省略されると警告を出力します。例えば、真理値（truth value）が期待されているコンテキストに代入があったり、演算子が入れ子になっていて、その優先度に関してしばしば混乱がもたらされるような場合です。また、 else がどの if 文に対応するかという点について混乱がもたらされる可能性のある構文（construction）についても、警告を出力します。以下に、このようなケースの例を示します。

{
  if (a)
    if (b)
      foo ();
  else
    bar ();
}

C では、個々の else は、候補となる if 文のうち最も内側にあるものに対応します。上の例では、それは if (b) です。これは、上の例でプログラマが選択したインデントが示すように、プログラマが期待するところと一致しないことがよくあります。このフラグが指定されていると、このような混乱の発生する可能性があるところで、 GNU C は警告を出力します。このような警告が出力されないようにするためには、最も内側にある if 文のまわりに明示的に波括弧 {} を追加することにより、最も内側にある if 文を包含する if 文に else が対応することができないようにしてください。その結果、ソース・コードは次のようになるでしょう。

{
  if (a)
    {
      if (b)
        foo ();
      else
        bar ();
    }
}

-Wreturn-type

戻り値の型がデフォルトで int になるように定義された関数がある場合に、常に警告を出力します。また、戻り値の型が void ではない関数の中に、戻り値を取らない return 文が１つでもあれば、警告を出力します。

-Wswitch

switch 文が列挙型のインデックスを持つ場合で、その列挙型により名前付けされた定数（named code）に対応する case が１つでも存在しない場合には、常に警告を出力します（default ラベルが存在すると、この警告メッセージの出力は行われません）。このオプションが使われると、列挙型の値の範囲にない case ラベルが存在する場合にも、警告が出力されることになります。

-Wtrigraphs

３文字表記（が使用可能になっていると仮定して）が１つでも見つかると、警告を出力します。

-Wunused

ある変数が宣言以外の箇所で使われていない場合、ある関数が静的関数として宣言されているが定義されていない場合、あるラベルが宣言されているが使われていない場合、ある文によって評価された結果が明示的には使われていない場合、常に警告を出力します。使われない関数パラメータに関する警告メッセージを出力させるためには、 `-W' と `-Wunused' の両方を指定しなければなりません。ある式に関してこの警告を出力させないようにするには、単にその式を void にキャストしてください。使われない変数やパラメータに関してこの警告を出力させないようにするには、 `unused' 属性を使ってください（see section 変数属性の指定）。

-Wuninitialized

初期化されずに使われている自動変数について、警告を出力します。この警告は、最適化コンパイルにおいてのみ可能です。というのは、最適化の過程においてのみ評価されるデータ・フローに関する情報が必要とされるからです。 `-O' を指定しなければ、この警告が出力されることはありません。この警告は、レジスタを割り当てる候補となる変数に対してのみ出力されます。したがって、この警告は、 volatile 宣言されている変数、アドレスが取られている変数、サイズが 1、 2、 4、 8 バイトのいずれでもない変数に対して出力されることはありません。また、構造体、共用体、配列に対しては、たとえそれらがレジスタの中に割り当てられている場合でも、この警告が出力されることはありません。ある値を計算するためだけに使われている変数に対しては、その計算結果自体が使われることがないのであれば、警告は出力されないかもしれないという点に注意してください。これは、警告が出力されるよりも前に、データ・フロー解析によって、そのような計算を行うコードが削除されるかもしれないからです。あるソース・コードにエラーがあるように見えるにもかかわらず、実際にはそのソース・コードが正しいという場合に、その正しさの根拠をすべて見抜くことができるほど GNU CC は賢くないので、この警告は任意選択となっています。以下に、このようなことが起こり得る例を１つ示します。

{
  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 にはこのことが分かりません。以下に、もう１つよくあるケースを示します。

{
  int save_y;
  if (change_y) save_y = y, y = new_y;
  ...
  if (change_y) y = save_y;
}

save_y は、値が設定されている時にしか使われないので、ここにはバグはありません。使われる関数のうち、決して復帰することのないものすべてを noreturn として宣言することによって、見せ掛けだけで意味のない警告のいくつかを回避することができます。 See section 関数属性の宣言。

-Wreorder (C++ のみ)

ソース・コードの中で与えられたメンバ初期化子の順序が、実行されるべき順序と一致しない場合に、警告を出力します。以下に例を示します。

struct A {
  int i;
  int j;
  A(): j (0), i (1) { }
};

この例では、 `i' と `j' に対するメンバ初期化子の順序は、これらのメンバの宣言の順序に合致するよう再調整されることを、コンパイラが警告します。

-Wtemplate-debugging

C++ プログラムの中でテンプレートが使われている場合に、そのデバッグを行うために必要な機能がまだ完全に利用可能でなければ、警告メッセージを出力します（C++ のみ）。

-Wall

ここまでで説明してきたすべての `-W' オプションを組み合わせたものです。このオプションにより、ユーザによっては疑わしいとみなす構文で、簡単に回避する（あるいは、警告が出ないように修正する）ことができるものに関して警告が出力されるようになります。マクロに関連する構文であっても、警告が出力されます。

以下の `-W...' オプションは、 `-Wall' によって暗黙のうちに指定されることのないオプションです。これらのオプションのいくつかは、通常はユーザによって疑わしいものとはみなされない構文で、時にはチェックしたくなるかもしれないようなものに関して警告を出力するものです。これ以外のオプションは、状況によっては回避することが必要であったり困難であったりする構文で、警告が出力されないようにソース・コードを変更する簡単な方法が存在しないようなものに関して、警告を出力するものです。

-W

以下の事象に対して特別の警告メッセージを表示します。

volatile 宣言されていない自動変数が、 longjmp の呼び出しによって値が変更される可能性がある。この警告もまた、最適化コンパイルにおいてしか出力されません。コンパイラは、 setjmp の呼び出しだけを認識します。コンパイラには、どこで longjmp が呼び出されるのか分かりません。実際、シグナル・ハンドラは、ソース・コードの中の任意の箇所でそれを呼ぶことができます。この結果、問題を引き起こすような箇所で longjmp が呼び出されることがあり得ないため、実際にはまったく問題がないような場合であっても、警告が出力されることになるかもしれません。
関数が、戻り値を持って復帰することも、戻り値を持たずに復帰することもできるようになっている（関数本体の終端に達することは、戻り値を持たずに復帰することとみなされます）。例えば、以下の関数はそのような警告を出力させることになります。
```
foo (a)
{
  if (a > 0)
    return a;
}
```
式文、もしくは、カンマ式（comma expression）の左側の部分がまったく副作用を持たない。警告が出力されないようにするためには、使われない式を void にキャストします。例えば、 `x[i,j]' のような式は警告を出力させることになりますが、 `x[(void)i,j]' は出力させません。
無符号の値が `<' や `<=' を使ってゼロと比較されている。
`x<=y<=z' のような比較が行われている。これは、 `(x<=y ? 1 : 0) <= z' と同一であり、通常の数学的表記法における解釈とは異なるものです。
static のような記憶クラス指定子が、宣言の中で最初に記述されていない。 C の標準によれば、このような使い方はすたれてきています。
`-Wall' もしくは `-Wunused' も指定されると、使われない引数に関して警告を出力します。
有符号の値と無符号の値との比較は、有符号の値が無符号に変換されると、正しくない結果をもたらすことがあります（`-Wno-sign-compare' も指定されていれば、警告を出力しません）。
集合体の初期化子を囲む波括弧 {} が部分的にしか記述されていない。例えば、以下のソース・コードは、 x.h に対応する初期化子のまわりの波括弧 {} が欠けているために、このような警告を出力させることになります。
```
struct s { int f, g; };
struct t { struct s h; int i; };
struct t x = { 1, 2, 3 };
```

-Wtraditional

伝統的な C における振る舞いと ANSI C における振る舞いが異なる特定の構文（construct）に関して、警告を出力します。

マクロ本体の中の文字列定数の中にマクロ引数が現れる。このような場合、伝統的な C では引数の代替が行われますが、 ANSI C では定数の一部となります。
あるブロックの中で external 宣言されている関数が、そのブロックの終端よりも後ろで使われている。
switch 文が long 型のオペランドを持つ。

-Wundef

`#if' 指示子の中で未定義の識別子が評価されると警告を出力します。

-Wshadow

ある局所変数が別の局所変数を隠す（shadow）場合に、常に警告を出力します。

-Wid-clash-len

２つの別個の識別子の、先頭から数えて len で示される文字数までが一致している場合に、常に警告を出力します。これは、古くさくて脳が破壊されているとしか思えない特定のコンパイラを使ってコンパイルするプログラムを準備するのに役に立つことがあるかもしれません。

-Wlarger-than-len

len により示されるバイト数よりも大きいオブジェクトが定義されている場合に、常に警告を出力します。

-Wpointer-arith

関数型の「サイズ」、もしくは、 void の「サイズ」に依存するものに対して警告を出力します。 GNU C は、 void * 型のポインタや関数ポインタを使う計算の便宜のために、これらの型に 1 というサイズを割り当てています。

-Wbad-function-cast

関数呼び出しが、マッチしない型にキャストされる場合に、常に警告を出力します。例えば、 int malloc() が任意の型へのポインタにキャストされると、警告が出力されます。

-Wcast-qual

ポインタの指す型から型修飾子を削除するためにポインタがキャストされる場合に、常に警告を出力します。例えば、 const char * がただの char * にキャストされると、警告が出力されます。

-Wcast-align

ポインタの指す型に要求される境界整列の値が大きくなるようなキャストがポインタに対して行われる場合に、常に警告を出力します。例えば、２バイト境界、もしくは、４バイト境界においてのみ整数にアクセスすることができるマシン上において、 char * が int * にキャストされると、警告が出力されます。

-Wwrite-strings

文字列定数のアドレスを const 指定されない char * 型のポインタにコピーしようとすると警告が出力されるように、文字列定数に対して const char[length] という型を与えます。この警告は、文字列定数の中への書き込みを試みるソース・コードをコンパイル時に発見するのに役に立ちます。しかし、これが役に立つのは、宣言やプロトタイプにおいて、非常に注意深く const が使われている場合だけです。そうでない場合には、この警告メッセージは迷惑なだけです。 `-Wall' がこの警告の出力を要求するようにしなかったのは、これが理由です。

-Wconversion

プロトタイプの存在により引き起こされる引数の型変換が、プロトタイプが存在しなかった場合に同じ引数に対して行われるであろう変換と異なる場合に、警告を出力します。これには、固定小数点から浮動小数点への変換やその逆の変換が含まれます。また、固定小数点引数の大きさ（width）や符号の有無を変更する変換も、それがデフォルトの拡張（promotion）と同等である場合を除外して、対象となります。また、負の整数定数式が暗黙のうちに無符号の型に変換される場合にも、警告が出力されます。例えば、 x が無符号であると、代入 x = -1 に対して警告が出力されます。しかしその一方で、 (unsigned) -1 のような明示的なキャストに対しては、警告は出力されません。

-Wsign-compare

有符号の値が無符号に変換されると、有符号の値と無符号の値との比較が正しくない結果をもたらす可能性がある場合に、警告が出力されます。この警告は、 `-W' によっても出力されるようになります。 `-W' の他の警告は出力されるようにして、この警告だけが出力されないようにするためには、 `-W -Wno-sign-compare' を使ってください。

-Waggregate-return

構造体や共用体を返す任意の関数が定義されていたり、呼び出されていたりすると、警告を出力します（配列を返すことのできる言語では、配列を返す関数についても警告が出力されます）。

-Wstrict-prototypes

関数が、引数の型を指定されずに宣言もしくは定義されると、警告を出力します（引数の型を指定する宣言が前にあれば、旧式の関数定義を、警告を出力することなく使用することができます）。

-Wmissing-prototypes

広域関数が、事前にプロトタイプ宣言が行われることなく定義されると、警告を出力します。この警告は、定義そのものがプロトタイプを提供する場合でさえ、出力されます。その目的は、ヘッダ・ファイルの中で正しく宣言されていない広域関数を見つけることにあります。

-Wmissing-declarations

広域関数が、事前に宣言されることなく定義されると、警告を出力します。定義そのものがプロトタイプを提供する場合でさえ、警告が出力されます。ヘッダ・ファイルの中で宣言されていない広域関数を見つけるには、このオプションを使ってください。

-Wredundant-decls

同一のスコープの中で２回以上宣言されているものがあると、たとえ複数回の宣言が正当であり、複数回宣言されることによって何も変更されないようなケースであっても、警告を出力します。

-Wnested-externs

関数の内部で extern 宣言が見つかると、警告を出力します。

-Winline

関数をインライン展開することができず、かつ、その関数がインライン関数として宣言されているか、もしくは、 `-finline-functions' オプションが指定されている場合に、警告を出力します。

-Wold-style-cast

旧式の（C 方式の）キャストがプログラムの内部で使われていると、警告メッセージを出力します。

-Woverloaded-virtual

派生クラスの関数宣言において、仮想関数の定義に誤りのある可能性がある場合に、警告を出力します（C++ のみ）。派生クラスにおいて、仮想関数の定義は、基底クラスにおいて宣言された仮想関数の型シグニチャと一致していなければなりません。このオプションを指定すると、仮想関数と同じ名前を持つ関数を定義したにもかかわらず、その関数の型シグニチャが、基底クラスのどの宣言とも一致しない場合に、コンパイラが警告を出力します。

-Wsynth (C++ のみ)

g++ の合成（synthesis）の振る舞いが、 cfront の合成（synthesis）の振る舞いと一致しない場合に、警告を出力します。例えば、

struct A {
  operator int ();
  A& operator = (int);
};

main ()
{
  A a,b;
  a = b;
}

この例では、 g++ はデフォルトの `A& operator = (const A&);' を合成（synthesize）することになります。一方、 cfront はユーザ定義の `operator =' を使います。

-Werror

すべての警告メッセージをエラー・メッセージにします。

ユーザ・プログラムもしくは GNU CC をデバッグするためのオプション

GNU CC には、ユーザ・プログラム、もしくは、 GCC をデバッグするために使われる様々な特殊オプションがあります。

-g

オペレーティング・システム本来の形式（スタブ、 COFF、 XCOFF、 DWARF）でデバッグ情報を生成します。 GDB は、このデバッグ情報を取り扱うことができます。スタブ形式を使うほとんどのシステム上では、 `-g' によって、 GDB だけが使える追加的なデバッグ情報を使うことができるようになります。この追加情報によって、 GDB によるデバッグはより良く機能するようになりますが、おそらく他のデバッガは、異常終了したりプログラムの読み込みを拒否したりするようになるでしょう。このような追加情報を生成するか否かを確実に制御したいのであれば、 `-gstabs+'、 `-gstabs'、 `-gxcoff+'、 `-gxcoff'、 `-gdwarf-1+'、 `-gdwarf-1' を使ってください（下記参照）。ほとんどの他の C コンパイラとは異なり、 GNU CC では、 `-g' を `-O' と一緒に使うことができます。コードの最適化によって、時々驚くべき結果がもたらされることがあります。宣言された変数のいくつかがまったく存在しないということがあります。制御の流れが、予想していなかった箇所へ一時的に移動することもあります。いくつかの文は、その評価結果が不変である、もしくは、その値が既に手元にあるという理由によって、実行されないことがあります。また、いくつかの文は、ループの外部に移動されたために、異なる箇所で実行されることもあります。それにもかかわらず、最適化されて生成されたコードをデバッグすることは可能であることが分かっています。よって、バグがあるかもしれないプログラムに対して最適化を行うことは合理的なことです。以下のオプションは、複数のデバッグ形式を生成できるように GNU CC が構築されている場合に、役に立つものです。

-ggdb

GDB で使うためのデバッグ情報を生成します。このことは、 GDB の拡張形式が使える場合にはそれも含めて、利用可能な形式（DWARF 2、スタブ、もしくは、これら２つがどちらもサポートされていない場合にはＯＳ本来の形式）のうち、最も多くの情報を提供する形式を使うということを意味しています。

-gstabs

（スタブ形式がサポートされていれば） GDB による拡張を使わないスタブ形式でデバッグ情報を生成します。これは、ほとんどの BSD システム上において DBX によって使われている形式です。 MIPS、 Alpha、 System V Release 4 上においてこのオプションを使うと、 DBX や SDB には理解できないスタブ・デバッグ情報が出力として生成されます。 System V Release 4 上においてこのオプションを使うには、 GNU アセンブラが必要になります。

-gstabs+

（スタブ形式がサポートされていれば） GNU デバッガ（GDB）だけが理解する GNU による拡張を使ったスタブ形式でデバッグ情報を生成します。この拡張を使うと、おそらく他のデバッガは、異常終了するか、プログラムの読み込みを拒否するようになるでしょう。

-gcoff

（COFF 形式がサポートされていれば） COFF 形式でデバッグ情報を生成します。これは、 System V Release 4 よりも前のほとんどの System V システム上において、 SDB によって使われている形式です。

-gxcoff

（XCOFF 形式がサポートされていれば） XCOFF 形式でデバッグ情報を生成します。これは、 IBM RS/6000 システム上において、 DBX デバッガによって使われている形式です。

-gxcoff+

（XCOFF 形式がサポートされていれば） GNU デバッガ（GDB）だけが理解する GNU による拡張を使った XCOFF 形式でデバッグ情報を生成します。この拡張を使うと、おそらく他のデバッガは、異常終了するか、プログラムの読み込みを拒否するようになるでしょう。また、 GNU アセンブラ（GAS）以外のアセンブラは、エラー終了するようになるでしょう。

-gdwarf

（DWARF バージョン 1 形式がサポートされていれば） DWARF バージョン 1 形式でデバッグ情報を生成します。これは、ほとんどの System V Release 4 システム上において、 SDB によって使われている形式です。

-gdwarf+

（DWARF バージョン 1 形式がサポートされていれば） GNU デバッガ（GDB）だけが理解する GNU による拡張を使った DWARF バージョン 1 形式でデバッグ情報を生成します。この拡張を使うと、おそらく他のデバッガは、異常終了するか、プログラムの読み込みを拒否するようになるでしょう。

-gdwarf-2

（DWARF バージョン 2 形式がサポートされていれば） DWARF バージョン 2 形式でデバッグ情報を生成します。これは、 IRIX 6 において DBX によって使われている形式です。

-glevel

-ggdblevel

-gstabslevel

-gcofflevel

-gxcofflevel

-gdwarflevel

-gdwarf-2level

デバッグ情報を要求します。また、 level を使って、どの程度の情報を要求するかを指定します。デフォルトのレベルは 2 です。レベル 1 では、デバッグをする予定のないプログラム部分に関してバックトレースを行うのに十分な、最低限の情報だけを出力します。これには、関数や外部変数に関する記述が含まれますが、局所変数や行番号に関する情報は含まれません。レベル 3 には、プログラムの中に存在するすべてのマクロ定義などの追加情報が含まれます。デバッガによっては、 `-g3' が使われている場合に、マクロ展開をサポートするものもあります。

-p

解析プログラム prof に適するプロファイル情報を出力するための追加的なコードを生成します。プロファイル・データを入手したいソース・ファイルをコンパイルする際に、このオプションを使わなければなりません。また、リンクを行う際にも、このオプションを使わなければなりません。

-pg

解析プログラム gprof に適するプロファイル情報を出力するための追加的なコードを生成します。プロファイル・データを入手したいソース・ファイルをコンパイルする際に、このオプションを使わなければなりません。また、リンクを行う際にも、このオプションを使わなければなりません。

-a

基本ブロック（basic block）に関するプロファイル情報を出力するための追加的なコードを出力します。この追加的なコードによって、個々の基本ブロックに関して、それが実行された回数、その開始アドレス、それを包含する関数の名前が記録されます。 `-g' が使われると、基本ブロックの先頭の行番号とファイル名もまた記録されます。マシン記述によって無効にされなければ、デフォルトのアクションは、 `bb.out' というテキスト・ファイルの末尾に情報を追加するというものです。このデータは、本来 tcov のようなプログラムによって解析することができるはずのものです。しかし、このデータの形式は、 tcov が期待している形式とは異なることに注意してください。最終的には、このデータを処理できるように、 GNU gprof を拡張しなければならないでしょう。

-ax

基本ブロック（basic block）をプロファイルするための追加的なコードを生成します。実行ファイルは、 `-a' が使われた場合に出力される情報だけでなく、さらにそれ以上の情報を出力します。追加の出力情報は、ジャンプが発生する基本ブロックのジャンプ元アドレスとジャンプ先アドレス、ジャンプが実行された回数です。さらに、実行された基本ブロックの完全な実行順序が出力されることもあります。この出力は、ファイル `bb.out' の末尾に追加されます。再コンパイルすることなく、異なる視点からプロファイル情報を調べることができます。実行ファイルは、ファイル `bb.in' から関数名の一覧を読み込みます。一覧の中にある関数の実行が開始された時にプロファイル処理が開始され、その関数の実行が終了した時にプロファイル処理も停止します。ある関数をプロファイル処理の対象から外すには、その関数の名前の前に `-' を付けます。関数の名前が一意でない場合には、 `/path/filename.d:functionname' のような形式で記述することによって曖昧さを取り除くことができます。実行プログラムは、パスとファイル名が分かっている場合には、それらをファイル `bb.out' に出力します。いくつかの関数名には、特殊な意味があります。

__bb_jumps__: ジャンプ元、ジャンプ先、ジャンプの回数を、ファイル `bb.out' に出力します。
__bb_hidecall__: 関数の呼び出しを、回数のカウントから除外します。
__bb_showret__: 関数からの復帰を、回数のカウントに含めます。
__bb_trace__: 実行された基本ブロックの実行順序をファイル `bbtrace.gz' に出力します。このファイルは、 `gzip' というプログラムを使って圧縮されます。 `gzip' は PATH の指すディレクトリの中になければなりません。 `popen' 関数のないシステム上においては、このファイルには `bbtrace' という名前が付けられ、圧縮は行われません。 このようなシステム上においては、ほんの２、３秒のプロファイルであっても、非常に大きなファイルが作成されることになります。 注意: __bb_hidecall__ と __bb_showret__ を使っても、 `bbtrace.gz' に出力される順序情報に変化はありません。

ファイル `bb.in' の中で異なるプロファイル処理パラメータを使った場合の、短い例を以下に示します。関数 foo には基本ブロック 1 と基本ブロック 2 があり、この関数 foo は関数 main のブロック 3 から２回呼び出されるものとします。また、これらの呼び出しの後に、ブロック 3 は main のブロック 4 に制御を移すものとします。ファイル `bb.in' に __bb_trace__ と main とが含まれていると、 0 3 1 2 1 2 4 というブロックの順序が、ファイル `bbtrace.gz' に書き込まれます。ブロック 2 からブロック 3 への復帰が示されていないのは、この復帰が、ブロック内部のある箇所への復帰であって、ブロックの先頭への復帰ではないからです。ブロック・アドレス 0 は、観察されている関数の外部のどこかから制御が移ってきたことを常に示しています。 `bb.in' に `-foo' が追加されると、関数 foo の中のブロックは追跡情報から削除され、したがって、 0 3 4 だけが残されます。ファイル `bb.in' に __bb_jumps__ と main とが含まれていると、ファイル `bb.out' にジャンプの回数が出力されます。この回数は、ブロックの実行を追跡した情報を組み立て、その追跡情報の中で隣接するブロックの組み合わせをすべてカウントすることによって得られます。 0 3 1 2 1 2 4 という追跡情報があると、以下のようなジャンプ回数が表示されます。

Jump from block 0x0 to block 0x3 executed 1 time(s)
Jump from block 0x3 to block 0x1 executed 1 time(s)
Jump from block 0x1 to block 0x2 executed 2 time(s)
Jump from block 0x2 to block 0x1 executed 1 time(s)
Jump from block 0x2 to block 0x4 executed 1 time(s)

__bb_hidecall__ を指定すると、関数呼び出し命令による制御の移動は、追跡情報から削除されます。すなわち、追跡情報は３つの部分、 0 3 4、 0 1 2、 0 1 2 に分割されます。 __bb_showret__ を指定すると、復帰命令による制御の移動は、追跡情報に加えられます。その結果、追跡情報は 0 3 1 2 3 1 2 3 4 となります。この追跡情報は、 `bbtrace.gz' に出力される実行順序の情報と同一ではないことに注意してください。この追跡情報は、ジャンプ回数をカウントするためにだけ使われます。

-fprofile-arcs

コンパイル時に、 アーク（arc）に対して計測用のコードを出力します。プログラムの中の個々の関数に対して、 GNU CC はプログラム・フローのグラフを作成し、そのグラフをまたがるツリーを見つけます。このツリー上にないアークのみに対して、計測用のコードが出力されなければなりません。コンパイラは、これらのアークが実行された回数をカウントするコードを追加します。あるアークが、あるブロックの唯一の出口、もしくは、入り口である場合、計測用のコードをブロックに対して追加することができます。このような場合以外では、計測用のコードを保持するために新たに基本ブロックが作成されなければなりません。プログラムの中のすべてのアークに対して計測用のコードが出力されなければならないわけではないので、このオプションを指定してコンパイルされたプログラムは、 `-a' を指定してコンパイルされたプログラムよりも、実行速度が速くなります。 `-a' を指定してコンパイルされたプログラムでは、プログラムの中のすべての基本ブロックに対して計測用のコードが追加されます。この見返りとして、すべての分岐部分の実行回数が手に入らないため、 gcov は、計測用のコードが組み込まれた分岐部分の実行回数はそのまま使い、それ以外の分岐部分については、プログラム・フローのグラフ全体の調査が完了するまで、グラフを繰り返し調べなければならなくなります。したがって、 `-a' によって入手できる情報を使うプログラムと比べて、 gcov の実行速度は少し遅くなります。 `-fprofile-arcs' によって、分岐の確率を概算することや基本ブロックの実行回数を計算することも可能になります。一般に、基本ブロックの実行回数は、すべての分岐の確率を概算するのに十分な情報を与えてはくれません。コンパイルされたプログラムは、終了する時に、 `sourcename.da' という名前のファイルに、アークの実行回数の情報を保存します。概算された分岐の確率情報を使って最適化を行うためには、再コンパイルの際に、コンパイル・オプション `-fbranch-probabilities' （see section 最適化を制御するオプション）を使ってください。

-ftest-coverage

gcov ユーティリティ（@xref{Gcov,, gcov: a GNU CC Test Coverage Program}）用のデータ・ファイルを作成します。データ・ファイルの名前は、ソース・ファイルの名前で始まります。

sourcename.bb: 基本ブロックから行番号へのマッピング情報です。 gcov は、基本ブロックの実行回数を行番号に関連付けるために、この情報を使います。
sourcename.bbg: プログラム・フローのグラフの中のすべてのアークの一覧です。これによって gcov は、 sourcename.da ファイル（このファイルは、 `-fprofile-arcs' の出力です）の中の情報からすべての基本ブロックの実行回数とすべてのアークの実行回数を計算することができるようにするために、プログラム・フローのグラフを再構成することができるようになります。

-Q

コンパイラに、個々の関数をコンパイルしている際に、その関数の名前を表示させ、かつ、個々のパスが終了する際に、そのパスに関する統計情報を表示させます。

-dletters

コンパイルを実行している際、 letters によって指定されるタイミングで、デバッグ情報をダンプするよう指示します。これは、コンパイラをデバッグするのに使われます。ほとんどのダンプ情報のファイル名は、ソース・ファイル名の末尾に単語を付け加えて作られます（例えば、 `foo.c.rtl' や `foo.c.jump'）。以下に、 letters として使うことのできる文字とその意味を示します。

`M': 前処理の終了時点で、すべてのマクロ定義をダンプします。通常の出力は行われません。
`N': 前処理の終了時点で、すべてのマクロ名をダンプします。
`D': 前処理の終了時点で、通常の出力に加えて、すべてのマクロ定義をダンプします。
`y': パース（parse）処理の実行中に、標準エラー出力にデバッグ情報をダンプします。
`r': RTL を生成後、ファイル `file.rtl' にダンプします。
`x': 関数をコンパイルするのではなく、その関数の RTL だけを生成します。通常は、 `r' と一緒に使われます。
`j': 最初のジャンプ最適化の後に、ファイル `file.jump' にダンプします。
`s': CSE(3) の後に、（CSE に続いて時々実行されるジャンプの最適化も含めて）ファイル `file.cse' にダンプします。
`D': ADDRESSOF を除去した後に、ファイル `file.addressof' にダンプします。
`L': ループの最適化の後に、ファイル `file.loop' にダンプします。
`t': ２回目の CSE パスの後に、（CSE に続いて時々実行されるジャンプの最適化も含めて）ファイル `file.cse2' にダンプします。
`b': 分岐の確率を計算した後に、ファイル `file.bp' にダンプします。
`f': フロー解析の後に、ファイル `file.flow' にダンプします。
`c': 命令の結合（instruction combination）の後に、ファイル `file.combine' にダンプします。
`S': 最初の命令スケジューリングのパスの後に、ファイル `file.sched' にダンプします。
`l': 局所的なレジスタの割り当ての後に、ファイル `file.lreg' にダンプします。
`g': 広域的なレジスタの割り当ての後に、ファイル `file.greg' にダンプします。
`R': ２回目の命令スケジューリングのパスの後に、ファイル `file.sched2' にダンプします。
`J': 最後のジャンプ最適化の後に、ファイル `file.jump2' にダンプします。
`d': 遅延分岐スケジューリング（delayed branch scheduling）の後に、ファイル `file.dbr' にダンプします。
`k': レジスタからスタックへの変換の後に、ファイル `file.stack' にダンプします。
`a': 上記のすべてのダンプを生成します。
`m': メモリ使用に関する統計情報を、コンパイラ実行の最後に標準エラー出力に表示します。
`p': どのようなパターンおよび代替パターン（alternative）が使われたかを示すコメントによって、アセンブラの出力に注釈を加えます。
`A': 種々雑多なデバッグ情報によって、アセンブラの出力に注釈を加えます。

-fpretend-float

クロス・コンパイラを実行している際に、ホスト・マシンと同一の浮動小数点形式がターゲット・マシンでも使われるものと想定します。これによって、正しくない浮動小数点定数が出力されることになりますが、命令シーケンス（instruction sequence）は、 GNU CC がターゲット・マシン上で実行された場合に作成されるものと、おそらく同じになるでしょう。

-save-temps

通常は「一時的に」作成される中間ファイルを、永続的に保存します。これらの中間ファイルは、カレント・ディレクトリに置かれ、ソース・ファイルに基づく名前が与えられます。よって、 `foo.c' を `-c -save-temps' を指定してコンパイルすると、 `foo.o' だけでなく、ファイル `foo.i'、 `foo.s' もまた生成されることになります。

-print-file-name=library

リンク時に使われるであろうライブラリ・ファイル library の完全な絶対パス名を表示し、それ以外には何も行いません。このオプションが指定されると、 GNU CC はコンパイルもリンクも一切行いません。ファイル名が表示されるだけです。

-print-prog-name=program

`-print-file-name' と似ていますが、このオプションは `cpp' などのプログラムを探します。

-print-libgcc-file-name

`-print-file-name=libgcc.a' と同じです。これは、 `-nostdlib' や `-nodefaultlibs' を使うが、 `libgcc.a' とはリンクしたいという場合に役に立ちます。次のような使い方ができます。

gcc -nostdlib files... `gcc -print-libgcc-file-name`

-print-search-dirs

設定（configure）されたインストール・ディレクトリの名前と gcc が探索するプログラム・ディレクトリやライブラリ・ディレクトリの一覧を表示します。これ以外には、何も行いません。これは、 gcc が `installation problem, cannot exec cpp: No such file or directory' というエラー・メッセージを表示する場合に役に立ちます。これを解決するためには、 `cpp' や他のコンパイラ構成要素を、 gcc がそれらを見つけることができると期待しているディレクトリに置く必要があります。あるいは、それらをインストールしたディレクトリを環境変数 GCC_EXEC_PREFIX に設定することもできます。この場合、末尾に `/' を付けることを忘れないでください。 See section GNU CC に影響を与える環境変数。

最適化を制御するオプション

以下のオプションは、様々な種類の最適化を制御します。

-O
-O1: 最適化を行います。最適化にはいくらか多くの時間がかかります。また、関数のサイズが大きい場合には、かなり多くのメモリが追加的に必要になります。 `-O' が指定されないと、コンパイル処理にかかるコストを削減することとデバッグ処理が期待される結果をもたらすようにすることが、コンパイラの目標になります。文の間にブレイクポイントを設定してプログラムを停止させると、任意の変数に新しい値を代入したり、プログラム・カウンタの値をその関数の中の任意の他の文に変更したりすることができ、その際、ソース・コードから期待されるのとまったく同じ結果を得ることができます。 `-O' が指定されないと、コンパイラは、 register を宣言された変数だけをレジスタに割り当てます。その結果としてコンパイルされたコードは、 `-O' が指定されない場合に PCC によって生成されるコードと比べて、少し劣るものになります。 `-O' が指定されると、コンパイラは、コードのサイズと実行時間を削減するよう試みます。 `-O' を指定すると、すべてのマシン上においてコンパイラは、 `-fthread-jumps' と `-fdefer-pop' を有効にします。また、コンパイラは、遅延スロット（delay slot）のあるマシン上では `-fdelayed-branch' を有効にし、フレーム・ポインタがなくてもデバッグ処理をサポートできるマシン上では `-fomit-frame-pointer' を有効にします。マシンによっては、コンパイラはさらに他のフラグも有効にします。
-O2: さらに最適化を行います。 GNU CC は、サポートされている最適化のうち、サイズとスピードとのトレードオフを伴わないほとんどすべてのものを実行します。 `-O2' を指定した場合には、コンパイラは、ループ展開（loop unrolling）や関数のインライン展開を実行しません。 `-O' と比較すると、このオプションにより、コンパイル時間はより長くなり、生成されるコードの性能は向上します。 `-O2' により、ループ展開と関数インライン展開を除いて、すべての任意選択の最適化が有効になります。また、すべてのマシン上において `-fforce-mem' オプションを有効にします。さらに、フレーム・ポインタの除去（frame pointer elimination）がデバッグ処理に対する妨げにならないマシン上においては、フレーム・ポインタの除去も有効にします。
-O3: さらに一層、最適化を行います。 `-O3' は、 `-O2' により指定されるすべての最適化を有効にした上に、さらに `inline-functions' オプションも有効にします。
-O0: 最適化を行いません。レベル番号の指定の有無にかかわらず、複数の `-O' オプションを使うと、そのうち最後に指定されたものが有効になります。

`-fflag' という形式のオプションは、マシンに依存しないフラグを指定します。ほとんどのフラグには、肯定形式と否定形式の両方があります。 `-ffoo' の否定形式は `-fno-foo' となります。以下の表においては、肯定形式、否定形式のうち、デフォルトではない方だけを載せてあります。もう一方の形式は、 `no-' を削除もしくは追加することによって、導き出すことができます。

-ffloat-store: 浮動小数点変数をレジスタに格納しません。また、浮動小数点値がレジスタとメモリのどちらから取られるかを変更する可能性のある他のオプションを禁止します。このオプションは、 68000 のように、 double が持つことになっている精度よりも高い精度を（68881 の）浮動小数点レジスタが持っているマシン上において、望ましくない余分の精度が持たれてしまうことを防ぎます。 x86 アーキテクチャに関しても、同様です。ほとんどのプログラムにとっては、余分の精度があるのは好都合なだけですが、プログラムによっては、 IEEE 浮動小数点の厳密な定義をあてにしているものも少しあります。そのようなプログラムに対しては、 `-ffloat-store' を使ってください。
-fno-default-inline: メンバ関数がクラス・スコープの内部において定義されているというだけの理由で、デフォルトでメンバ関数をインライン展開することをしません（C++ のみ）。 `-O' を指定した場合、これを指定しないと、クラス・スコープの内部において定義されたメンバ関数は、デフォルトでインライン展開されてコンパイルされます。すなわち、メンバ関数の名前の前に `inline' と書く必要はありません。
-fno-defer-pop: 関数から復帰すると、その関数呼び出しにおいて渡した引数を、常に即座にポップします。関数呼び出しのあとに引数をポップしなければならないマシンでは、コンパイラは通常、数回分の関数呼び出しの引数をスタック上に蓄積させて、それらすべてを一度にポップします。
-fforce-mem: メモリ・オペランドに対する算術演算が実行される前に、それをレジスタに強制的にコピーします。これにより、すべてのメモリ参照を潜在的な共通部分式（common subexpression）とすることによって、より良いコードが生成されます。メモリ参照が共通部分式でない場合、生成される命令の組み合わせは、個別に値をレジスタにロードするようなことをするべきではありません。 `-O2' オプションは、このオプションを有効にします。
-fforce-addr: メモリ・アドレス定数に対する算術演算が実行される前に、それをレジスタに強制的にコピーします。これにより、 `-fforce-mem' と同様、より良いコードが生成される可能性があります。
-fomit-frame-pointer: フレーム・ポインタを必要としない関数においては、フレーム・ポインタをレジスタ内に保持しません。これにより、フレーム・ポインタの待避、セットアップ、復元を行う命令を使わずに済むようになります。また、多くの関数において、レジスタを余分に利用することができるようになります。 いくつかのマシン上では、これによりデバッグが不可能になってしまいます。 Vax のようないくつかのマシン上においては、このフラグは何の効果も持ちません。というのは、標準的な命令呼び出しシーケンスによってフレーム・ポインタが自動的に処理されるので、フレーム・ポインタが存在しないということにしても、節約できることは何もないからです。マシン記述マクロ FRAME_POINTER_REQUIRED によって、ターゲット・マシンがこのフラグをサポートするか否かが制御されます。 @xref{Registers}。
-fno-inline: inline キーワードを無視します。通常、このオプションは、コンパイラがどの関数もインラインに展開することがないようにするために使われます。最適化を行っていないのであれば、関数はまったくインライン展開されないことに注意してください。
-finline-functions: 単純な関数はすべて、呼び出し側に統合します。このような方法で統合する値打ちがあるほど単純である関数はどれかということを、コンパイラは、発見的方法により決定します。ある与えられた関数が、呼び出されているすべての箇所において統合され、かつ、 static 宣言されているのであれば、その関数は通常、関数として独立したアセンブラ・コードとしては出力されません。
-fkeep-inline-functions: ある与えられた関数が、呼び出されているすべての箇所において統合され、かつ、 static 宣言されていてる場合でも、実行時に呼び出すことが可能な別個の関数として出力します。このフラグは、 extern inline として宣言されている関数には影響を与えません。
-fkeep-static-consts: 最適化が行われていない場合には、 static const 宣言された変数を、たとえその変数が参照されていなくても、出力します。 GNU CC は、このオプションをデフォルトで有効にします。最適化が行われているか否かにかかわらず、その変数が参照されていることをコンパイラに強制的にチェックさせたいのであれば、 `-fno-keep-static-consts' オプションを使ってください。
-fno-function-cse: レジスタに関数アドレスを入れません。ある決まった関数を呼び出す命令の１つ１つに、その関数のアドレスを明示的に持たせます。このオプションを使うと、効率の劣るコードが生成されますが、アセンブラ出力を変更するような奇妙な技巧（hacking）の中には、このオプションを使わずに実行された最適化によって混乱を引き起こされるものもあるかもしれません。
-ffast-math: このオプションは、スピードの向上を目的とするコードの最適化を行うために、 GCC が ANSI や IEEE の規則や仕様のいくつかに違反することを許します。例えば、コンパイラが、 sqrt 関数への引数は非負の数であると想定したり、すべての浮動小数点値は非数（NaNs）(4)ではないと想定したりすることを許します。どの `-O' オプションも、決してこのオプションを有効にするべきではありません。というのは、このオプションは、数学関数に対する IEEE や ANSI の規則や仕様の厳密な実装に依存するプログラムにとっては、正しくない出力を生成する結果になる可能性があるからです。

以下のオプションは、特定の最適化を制御するものです。 `-O2' オプションは、これらのうち `-funroll-loops' と `-funroll-all-loops' を除くすべての最適化を有効にします。ほとんどのマシン上において、 `-O' オプションは、 `-fthread-jumps' と `-fdelayed-branch' を有効にしますが、特定のマシンでは、 `-O' オプションに対して、異なる取り扱い方をするかもしれません。

実行される最適化の「微調整」が望ましいようなまれなケースに、以下のフラグを使うことができます。

-fstrength-reduce: ループ強度（loop strength）の削減と反復変数の除去による最適化を実行します。
-fthread-jumps: 比較によるジャンプの分岐先において、最初の比較に包含されるような別の比較があるかどうかをチェックすることにより、最適化を実行します。最初の比較が２番目の比較を包含するのであれば、２番目の比較の条件式が真偽いずれであるかが分かっているような場合には、真であれば、最初の分岐命令の分岐先を２番目の分岐命令の分岐先に、偽であれば、最初の分岐命令の分岐先を２番目の分岐命令の直後に、変更します。
-fcse-follow-jumps: 共通部分式の除去において、ジャンプ命令のジャンプ先がそのジャンプ命令以外のパスからは到達されない場合、そのジャンプ命令のジャンプ先を調べます。例えば、 CSE(5) が else 節を持つ if 文を見つけると、 CSE は、テストされる条件式が偽である場合のジャンプを追跡します。
-fcse-skip-blocks: これは `-fcse-follow-jumps' と似ていますが、条件に応じてブロックをスキップするジャンプを CSE に追跡させます。 `-fcse-skip-blocks' は、 else 節を持たない単純な if 文を CSE が見つけた場合に、 CSE に if の本体（body）を飛び越すジャンプを追跡させます。
-frerun-cse-after-loop: ループ最適化の実行後に再度、共通部分式の除去を実行します。
-fexpensive-optimizations: 相対的にコストのかかる（expensive）、重要ではない最適化をいくつか実行します。
-fdelayed-branch: 命令の実行順序を変更することがターゲット・マシンでサポートされていれば、遅延分岐命令の後に利用可能な命令スロットを活用するために、命令の実行順序の変更を試みます。
-fschedule-insns: 命令の実行順序を変更することがターゲット・マシンでサポートされていれば、必要なデータが利用できるようになっていないために発生する実行の一時的停止を除去するために、命令の実行順序の変更を試みます。速度の遅い浮動小数点命令やメモリ・ロード命令を持つマシンでは、ロード命令や浮動小数点命令の結果が必要になるまでの間、他の命令を実行することができるようにすることによって、これが役に立ちます。
-fschedule-insns2: `-fschedule-insns' と似ていますが、レジスタの割り当てが行われた後に、追加的に命令スケジューリングのパスの実行を要求します。レジスタの数が比較的少なく、メモリ・ロード命令が複数サイクルを要するマシン上において、これは特に役に立ちます。
-ffunction-sections: 任意のセクションを自由に選択することがターゲット・マシンによりサポートされていれば、出力ファイルの中において個々の関数を別個のセクションに置きます。関数の名前が、出力ファイルの中におけるセクションの名前を決定します。命令空間（instruction space）において参照の範囲を改善するための最適化をリンカが実行することができるようなシステム上において、このオプションを使ってください。 HP-UX を実行する HPPA プロセッサと Solaris 2 を実行する Sparc プロセッサには、このような最適化を行うリンカがあります。 AIX、および、 ELF オブジェクト形式を使う他のシステムも、将来このような最適化を行うようになるかもしれません。このオプションは、それを使うことによって重大な利益が得られる場合にのみ使うようにしてください。このオプションを指定すると、アセンブラとリンカはサイズのより大きいオブジェクト・ファイルと実行ファイルを作成するようになります。また、アセンブラとリンカの実行速度も遅くなります。このオプションを指定すると、すべてのシステム上において、 gprof を使うことができなくなります。また、このオプションと `-g' を一緒に指定すると、デバッグ処理に問題の出る可能性があります。
-fcaller-saves: 関数呼び出しによって内容の破壊されるレジスタの中に値を割り当てることができるようにします。これは、そのような関数呼び出しの前後に、レジスタの待避と復元を行う余分の命令を出力することにより実現されます。このような割り当てが行われるのは、それを行わない場合に生成されるコードよりも、それを行った場合に生成されるコードの方が、結果的により良いものになるように見える場合だけです。このオプションは、代替手段として使うことのできる、関数呼び出し時に内容が保存されるレジスタ（call-preserved register）を持たない特定のマシンにおいては、通常デフォルトで有効になっています。
-funroll-loops: ループ展開（loop unrolling）による最適化を実行します。コンパイル時、もしくは、実行時に反復回数が決定できるループに対してのみ、この最適化は実行されます。 `-funroll-loop' は暗黙のうちに、 `-fstrength-reduce' と `-frerun-cse-after-loop' の両方を意味します。
-funroll-all-loops: ループ展開（loop unrolling）による最適化を実行します。これは、すべてのループに対して実行され、通常、プログラムの実行速度はより遅くなります。 `-funroll-all-loops' は暗黙のうちに、 `-frerun-cse-after-loop' のほかに `-fstrength-reduce' も意味します。
-fno-peephole: マシン固有のピープホール（peephole）の最適化をすべて無効にします。
-fbranch-probabilities: `-fprofile-arcs' （see section ユーザ・プログラムもしくは GNU CC をデバッグするためのオプション）を指定してコンパイルしたプログラムを実行後、分岐命令が取るであろうパスの推測に基づいて最適化を改善するために、そのプログラムを `-fbranch-probabilities' を指定して再度コンパイルすることができます。 `-fbranch-probabilities' が指定されると、 GNU CC は、個々の基本ブロックの最初の命令に `REG_EXEC_COUNT' ノート（note）を記し、個々の`JUMP_INSN' と `CALL_INSN' に `REG_BR_PROB' ノートを記します。これらは、最適化を改善するために使うことができます。現在のところ、これらはただ１個所でのみ使われています。それは、ファイル `reorg.c' の中です。ある分岐命令が主にどのパスを取るかを推測する代わりに、どのパスが最も多く取られるかを正確に決定するために、 `REG_BR_PROB' の値が使われます。

プリプロセッサを制御するオプション

以下のオプションは、 C のプリプロセッサを制御するものです。 C のプリプロセッサは、実際にコンパイル処理が行われる前に個々の C のソース・ファイルに対して実行されます。

`-E' オプションを使うと、前処理（preprocessing）以外には何も実行されません。ここに挙げたオプションの中には、 `-E' と一緒に使わなければ意味をなさないものがいくつかあります。というのは、それらのオプションを指定すると、プリプロセッサの出力は、実際のコンパイル処理には不適切なものになるからです。

-include file: 通常の入力ファイルを処理する前に、 file により指定されるファイルを処理します。事実上、 file の内容が最初にコンパイルされることになります。コマンドライン上にある `-D' オプションと `-U' オプションは、それらが指定された順序に関係なく、常に `-include file' よりも前に処理されます。すべての `-include' オプションと `-imacros' オプションは、指定された順序に処理されます。
-imacros file: 通常の入力ファイルを処理する前に、 file により指定されるファイルを処理しますが、その出力結果は破棄します。 file から生成される出力は破棄されるので、 `-imacros file' の唯一の効果は、 file の中で定義されているマクロを、主要な入力ファイルの中で使用可能にすることにあります。コマンドライン上にある `-D' オプションと `-U' オプションは、それらが指定された順序に関係なく、常に `-imacros file' よりも前に処理されます。すべての `-include' オプションと `-imacros' オプションは、指定された順序に処理されます。
-idirafter dir: ディレクトリ dir を第２のインクルード・パスに追加します。第２のインクルード・パスに含まれるディレクトリは、あるヘッダ・ファイルがメイン・インクルード・パス（`-I' オプションはここにディレクトリを追加します）に含まれるどのディレクトリの中にも見つからない場合に探索されます。
-iprefix prefix: 後続の `-iwithprefix' オプションのための接頭語として prefix を指定します。
-iwithprefix dir: ディレクトリを第２のインクルード・パスに追加します。ディレクトリの名前は、事前に `-iprefix' により指定された接頭語 prefix と dir を連結することによって作られます。接頭語が事前に指定されていない場合には、コンパイラがインストールされたディレクトリがデフォルトの接頭語として使われます。
-iwithprefixbefore dir: メイン・インクルード・パスにディレクトリを追加します。 `-iwithprefix' の場合と同様、ディレクトリの名前は、 prefix と dir を連結することによって作られます。
-isystem dir: ディレクトリを第２のインクルード・パスの先頭に追加し、標準のシステム・ディレクトリに適用されるのと同等の特殊な取り扱いを受けられるようにするために、システム・ディレクトリとしてマークします。
-nostdinc: ヘッダ・ファイルを探す際に、標準のシステム・ディレクトリを探索しません。 `-I' オプションにより指定されたディレクトリ（および、カレント・ディレクトリを探索することが適切である場合には、カレント・ディレクトリ）だけが探索されます。 `-I' に関する情報については、 See section ディレクトリ探索のためのオプション。 `-nostdinc' と `-I-' を両方使用することにより、インクルード・ファイルの探索パスを、明示的に指定したディレクトリだけに限定することができます。
-undef: （アーキテクチャ・フラグも含めて）非標準のマクロを事前定義しません。
-E: C プリプロセッサだけを実行します。指定されたすべての C ソース・ファイルを前処理して、その結果を標準出力、もしくは、指定された出力ファイルに出力します。
-C: プリプロセッサに対して、コメントを破棄しないよう指示します。 `-E' オプションと一緒に使います。
-P: プリプロセッサに対して、 `#line' 指示子を生成しないよう指示します。 `-E' オプションと一緒に使います。
-M: プリプロセッサに対して、 make コマンドで使うのに適した、個々のオブジェクト・ファイルの依存関係を記述したルール情報を出力するよう指示します。プリプロセッサは、個々のソース・ファイルに対して、そのソース・ファイルに対応するオブジェクト・ファイル名が依存関係のターゲットであり、そのソース・ファイルが #include により取り込むすべてのヘッダ・ファイルが依存関係のソースであるような make ルールを出力します。(6) このルールは単一行の場合もありますが、長い場合には、改行の直前に `\' を置くことにより複数行に継続することもあります。ルールの一覧は、前処理された C プログラムの中にではなく、標準出力に表示されます。 `-M' は暗黙のうちに `-E' を意味します。 make ルールを出力するよう指定する別の方法に、環境変数 DEPENDENCIES_OUTPUT （see section GNU CC に影響を与える環境変数）を設定する方法があります。
-MM: `-M' と似ていますが、出力の中には、 `#include "file"' により取り込まれたユーザ・ヘッダ・ファイルだけが対象となります。 `#include <file>' により取り込まれたシステム・ヘッダ・ファイルは省かれます。
-MD: `-M' と似ていますが、依存関係の情報は、入力ファイル名の末尾の ".c" を ".d" に置き換えた名前のファイルに書き込まれます。指定されたファイルはコンパイルされ、それに加えて、このような処理が行われます。 `-MD' は、 `-M' のように通常のコンパイル処理を禁止することをしません。 Mach では、ユーティリティ md を使うことにより、複数の依存関係ファイルをマージして、 `make' コマンドで使うのに適した単一の依存関係ファイルを作成することができます。
-MMD: `-MD' と似ていますが、ユーザ・ヘッダ・ファイルだけが対象となり、システム・ヘッダ・ファイルが省かれる点が違います。
-MG: 見つからないヘッダ・ファイルは生成されるファイルとして取り扱い、ソース・ファイルと同じディレクトリに存在するものと想定します。 `-MG' を指定する場合には、 `-M' か `-MM' のいずれかをあわせて指定しなければなりません。 `-MD' や `-MMD' が指定されている場合には、 `-MG' はサポートされません。
-H: 通常の処理に加えて、使用される個々のヘッダ・ファイルの名前を表示します。
-Aquestion(answer): `#if #question(answer)' のような前処理の条件式でテストされる場合に備えて、 question に対する答え answer をアサート（assert）します。 `-A-' は、通常はターゲット・マシンを記述する標準のアサーション（assertion）を使用不可とします。
-Dmacro: マクロ macro を文字列 `1' として定義します。
-Dmacro=defn: マクロ macro を defn として定義します。コマンドライン上にあるすべての `-D' オプションは、どの `-U' オプションよりも前に処理されます。
-Umacro: マクロ macro の定義を取り消します。 `-U' オプションは、すべての `-D' オプションの評価が終わったあとで評価されますが、どの `-include' オプションや `-imacros' オプションよりも前に評価されます。
-dM: プリプロセッサに対して、前処理の終了時点において有効なマクロ定義の一覧だけを出力するよう指示します。 `-E' オプションと一緒に使います。
-dD: プリプロセッサに対して、マクロの正しい出現順序で、すべてのマクロ定義を出力へ渡すよう指示します。
-dN: `-dD' と似ていますが、マクロ引数とマクロ定義の内容が省かれる点が違います。 `#define name' という形式の情報だけが出力に含まれます。
-trigraphs: ANSI C の３文字表記をサポートします。 `-ansi' オプションも、同一の効果を持ちます。
-Wp,option: option をプリプロセッサへのオプションとして渡します。 option にカンマが含まれる場合は、カンマの位置で分割されて複数のオプションとして渡されます。

アセンブラへのオプション渡し

アセンブラにオプションを渡すことができます。

-Wa,option: option をアセンブラへのオプションとして渡します。 option にカンマが含まれる場合は、カンマの位置で分割されて複数のオプションとして渡されます。

リンク処理用のオプション

以下のオプションは、コンパイラがオブジェクト・ファイルをリンクして実行可能な出力ファイルを作成するときに作用し始めます。コンパイラがリンク処理を実行しない場合には、これらのオプションは無意味です。

object-file-name: 特別に認識される接尾語で終わらないファイル名は、オブジェクト・ファイルの名前、もしくは、ライブラリの名前とみなされます（オブジェクト・ファイルとライブラリとの区別は、ファイルの内容によってリンカが行います）。リンク処理が行われる場合、これらのオブジェクト・ファイルはリンカへの入力として使われます。
-c
-S
-E: これらのオプションのうちのどれかが使われると、リンカは実行されません。これらを使う場合は、オブジェクト・ファイル名を引数として使ってはなりません。 See section 出力の種類を制御するオプション。
-llibrary: リンク時に、 library により指定される名前のライブラリを探します。コマンドの中のどこにこのオプションを指定するかによって、違いが出てきます。リンカは、ライブラリとオブジェクト・ファイルを、それらが指定された順番に探して処理します。したがって、 `foo.o -lz bar.o' と指定すると、ライブラリ `z' は、ファイル `foo.o' よりもあとに探されますが、ファイル `bar.o' よりは前に探されます。もし `bar.o' が `z' の中の関数を参照しているとすると、それらの関数は組み込まれないかもしれません。リンカは、標準ディレクトリを探索して、ライブラリを探します。ライブラリとは、実際には `liblibrary.a' という名前のファイルです。リンカは、まさにこのような名前が指定されたかのように、このファイル名を使用します。探索されるディレクトリには、いくつかの標準システム・ディレクトリに加えて、 `-L' によって指定された任意のディレクトリが含まれます。通常、このような方法で見つかるファイルはライブラリ・ファイル、すなわち、オブジェクト・ファイルをメンバとして持つアーカイブ・ファイルです。リンカは、アーカイブ・ファイルの中を調べて、その時点までに参照されてはいるが定義されていないシンボルを定義しているメンバを探します。見つかったファイルが通常のオブジェクト・ファイルであれば、それは通常の方法によってリンクされます。 `-l' オプションを使うこととファイル名を指定することの唯一の違いは、 `-l' オプションの場合には、 library の前後に `lib' と `.a' とが付加されて、いくつかのディレクトリが探索されるという点にあります。
-lobjc: Objective C のプログラムをリンクするためには、この特別な `-l' オプションが必要になります。
-nostartfiles: リンク時に標準システム・スタートアップ・ファイルを使いません。標準システム・ライブラリは、 -nostdlib や -nodefaultlibs が使用されない限り、通常は使用されます。
-nodefaultlibs: リンク時に標準システム・ライブラリを使用しません。指定されたライブラリだけがリンカに渡されます。標準スタートアップ・ファイルは、 -nostartfiles が使われない限り、通常は使用されます。
-nostdlib: リンク時に標準システム・スタートアップ・ファイルや標準システム・ライブラリを使用しません。スタートアップ・ファイルは一切リンカに渡されません。指定されたライブラリだけがリンカに渡されます。 `-nostdlib' と `-nodefaultlibs' によって使用されなくなる標準ライブラリの１つに `libgcc.a' があります。これは、特定のマシンの欠点を克服したり、いくつかの言語の特殊な必要を満足したりするために、 GNU CC が使用する内部的なサブルーチンのライブラリです（See section GNU CCの出力とのインターフェイス, for more discussion of `libgcc.a'）。ほとんどの場合、他の標準ライブラリの使用は避けたいような場合であっても、 `libgcc.a' は必要です。言い換えると、 `-nostdlib' や `-nodefaultlibs' を指定する場合には、通常は `-lgcc' もあわせて指定するべきです。これにより、内部的な GNU CC ライブラリ・サブルーチンに対する未解決の参照が存在しないことが確実になります（例えば、 C++ の生成関数が呼び出されることを確実にするために使われる `__main' への参照など。 @xref{Collect2,,collect2}）。
-s: 実行可能ファイルからすべてのシンボル・テーブルと再配置情報を削除します。
-static: このオプションは、ダイナミック・リンクをサポートするシステム上において、共用ライブラリとのリンクを防止します。その他のシステム上では、このオプションには何の効果もありません。
-shared: 後に他のオブジェクトとリンクして実行可能ファイルを作成することのできる共用オブジェクトを作成します。すべてのシステム上においてこのオプションがサポートされているわけではありません。いくつかのシステムにおいては、このオプションを指定する時に、 `-fpic' か `-fPIC' をあわせて指定しなければなりません。
-symbolic: 共用オブジェクトを構築する際に、広域シンボルへの参照を結合（bind）します。（リンク・エディタ・オプション `-Xlinker -z -Xlinker defs' によって無効にされない限り）未解決の参照について警告を出力します。ほんの少数のシステムだけがこのオプションをサポートしています。
-Xlinker option: option をリンカへのオプションとして渡します。このオプションを使って、 GNU CC が認識する術を持たないシステム固有のリンカ・オプションを与えることができます。引数を取るオプションを渡したいのであれば、 `-Xlinker' を２回使わなければなりません。１回目はオプションを指定するため、２回目は引数を指定するためです。例えば、 `-assert definitions' を渡すためには、 `-Xlinker -assert -Xlinker definitions' と書かなければなりません。 `-Xlinker "-assert definitions"' のように書くと、文字列全体が単一の引数として渡されてしまうのでうまく行きません。これは、リンカが期待していることとは異なります。
-Wl,option: option をリンカへのオプションとして渡します。 option にカンマが含まれる場合は、カンマの位置で分割されて複数のオプションとして渡されます。
-u symbol: シンボル symbol が未定義であるものとして振る舞います。これにより、そのシンボルを定義するためにライブラリ・モジュールをリンクすることが強制されます。異なるシンボルを指定して `-u' を複数回使用することにより、追加的なライブラリ・モジュールの組み込みを強制することができます。

ディレクトリ探索のためのオプション

以下のオプションは、ヘッダ・ファイル、ライブラリ、および、コンパイラの構成要素を見つけるために探索するディレクトリを指定するものです。

-Idir: ヘッダ・ファイルを見つけるために探索するディレクトリの一覧の先頭にディレクトリ dir を追加します。これらのディレクトリはシステム・ヘッダ・ファイルのディレクトリよりも前に探索されるので、このオプションを使って、システム・ヘッダ・ファイルを無効にして、ユーザが独自に作成したヘッダ・ファイルで置き換えることができます。 `-I' オプションを複数回使用すると、指定されたディレクトリは左から右の順序で調べられます。標準システム・ディレクトリはそのあとで調べられます。
-I-: `-I-' オプションよりも前に `-I' オプションにより指定されたディレクトリは、 `#include "file"' という形式で組み込まれるヘッダ・ファイルについてのみ探索されます。 `#include <file>' という形式で組み込まれるヘッダ・ファイルについては探索されません。 `-I-' よりもあとに `-I' により追加のディレクトリが指定されると、それらのディレクトリは `#include' 指示子により組み込まれるすべてのヘッダ・ファイルについて探索されます（通常は、 `-I' により指定されるディレクトリはすべてこのように使用されます）。さらに `-I-' オプションにより、 `#include "file"' により組み込まれたヘッダ・ファイルについて、最初に探索するディレクトリとしてカレント・ディレクトリ（カレントな入力ファイルが置かれていたディレクトリ）を使用することが禁止されます。 `-I-' が持つこの効果を無効にする方法はありません。 `-I.' によって、コンパイラが起動された時点におけるカレント・ディレクトリの探索を指定することは可能です。これは、プリプロセッサがデフォルトで行うこととまったく同一ではありませんが、多くの場合これで十分です。 `-I-' は、ヘッダ・ファイルを見つけるのに標準システム・ディレクトリを使うことを禁止するものではありません。したがって、 `-I-' と `-nostdinc' とは互いに独立しています。
-Ldir: `-l' により指定されるライブラリを見つけるために探索されるディレクトリの一覧の先頭にディレクトリ dir を追加します。
-Bprefix: このオプションは、コンパイラ自身の実行可能ファイル、ライブラリ、インクルード・ファイル、データ・ファイルがどこにあるかを指定するものです。コンパイラ・ドライバ・プログラムは、サブプログラム `cpp'、 `cc1'、 `as'、 `ld' を１つ以上実行します。コンパイラ・ドライバ・プログラムは、実行しようとする個々のプログラムの名前の接頭語として、 `machine/version/' を付加した prefix と `machine/version/' を付加しない prefix の両方を試しに使ってみます（see section ターゲット・マシンとコンパイラ・バージョンの指定）。 `-B' が指定されている場合には、コンパイラ・ドライバは、実行される個々のサブプログラムについて、まず `-B' により指定されている接頭語を試します。そのファイル名のファイルが見つからない場合、もしくは、 `-B' が指定されていない場合、ドライバは２つの標準接頭語を試します。それらは、 `/usr/lib/gcc/' と `/usr/local/lib/gcc-lib/' です。これらを使ったファイル名のファイルがいずれも見つからない場合には、 `PATH' 環境変数に指定されているディレクトリを使って、何の変更も加えないファイル名でファイルを探します。コンパイラがこれらのオプションを使ってリンカ用の `-L' オプションを作成するので、有効なディレクトリ名を指定する `-B' の接頭語は、リンカにおけるライブラリ名にも適用されます。また、コンパイラがこれらのオプションを使ってプリプロセッサ用の `-isystem' オプションを作成するので、同じ接頭語が、プリプロセッサにおけるインクルード・ファイル名にも適用されます。この場合、コンパイラは、接頭語の後ろに `include' を付加します。必要であれば、実行時サポート・ファイル `libgcc.a' もまた、 `-B' の接頭語を使って探すことができます。そのファイル名ではファイルが見つからない場合には、上記の２つの標準接頭語が試され、それ以外の試みは行われません。これら２つの名前によってもファイルが見つからない場合には、このファイルはリンクの対象外となります。 `-B' による接頭語とほぼ同様の接頭語を指定する別の方法に、環境変数 GCC_EXEC_PREFIX を使うという方法があります。 See section GNU CC に影響を与える環境変数。
-specs=file: コンパイラが標準の `specs' ファイルを読み込んだあとで、 `gcc' ドライバ・プログラムが `cc1'、 `cc1plus'、 `as'、 `ld' 等に渡すオプションを決定する際に使うデフォルトの設定を無効にするために、 file を処理します。コマンドライン上において複数の `-specs='file を指定することができ、その場合、左から右の順序で処理されます。

ターゲット・マシンとコンパイラ・バージョンの指定

デフォルトでは、 GNU CC は、 GNU CC がその上で使われているマシンと同一のタイプのマシンをターゲットとしてコンパイルを行います。しかし、別のタイプのマシンをターゲットとするコンパイルを行うために、 GNU CC をクロス・コンパイラとしてインストールすることもできます。実際には、異なるターゲット・マシン用にコンフィギュレーションを行った異なる GNU CC をいくつか並べてインストールすることもできます。この場合、 `-b' オプションによってどの GNU CC を使うかを指定します。

さらに、古いバージョンの GNU CC と新しいバージョンの GNU CC を並べてインストールすることもできます。これら複数の GNU CC のうち１つ（おそらくは最も新しいもの）がデフォルトの GNU CC となりますが、時には別の GNU CC を使いたいという場合もあるでしょう。

-b machine: 引数 machine はコンパイルのターゲット・マシンを指定します。これは、 GNU CC をクロス・コンパイラとしてインストールした場合に役に立ちます。 machine に指定する値は、クロス・コンパイラとして GNU CC のコンフィギュレーションを行ったときに指定したマシン・タイプと同一です。例えば、 System V を実行する 80386 用にコンパイルすることを意図して、クロス・コンパイラのコンフィギュレーションが `configure i386v' を指定して行われたのであれば、そのクロス・コンパイラを実行するには、 `-b i386v' を指定することになるでしょう。 `-b' を指定しないと、使っているマシンと同一のタイプのマシン用にコンパイルするということを通常は意味します。
-V version: 引数 version は実行すべき GNU CC のバージョンを指定します。これは、異なるバージョンの GNU CC が複数インストールされている場合に役に立ちます。例えば、 version に `2.0' を指定すると、バージョン 2.0 の GNU CC を実行することになります。 `-V' が指定されない場合のデフォルトのバージョンは、最後にインストールされた GNU CC のバージョンになります。

`-b' オプションと `-V' オプションは、実際には、コンパイル処理に使われる実行ファイルやライブラリの名前の一部を調整することによって機能します。ある与えられたターゲット・マシン用のある与えられたバージョンの GNU CC は、通常は `/usr/local/lib/gcc-lib/machine/version' というディレクトリに置かれています。

したがって、これらのディレクトリの名前を変更したり別の名前（もしくはシンボリック・リンク）を追加することによって、 `-b' や `-V' の効果をカスタマイズすることができます。 `/usr/local/lib/gcc-lib/' というディレクトリにおいて `80386' が `i386v' へのリンクであれば、 `-b 80386' は `-b i386v' の別名となります。

`-b' と `-V' による異なるコンパイラへの切り替えは、ある一点において完全なものではありません。一番最初に起動されるトップ・レベルのドライバ・プログラム gcc は常に同じものが実行され、これが、実際の仕事を行う他の実行ファイル（プリプロセッサ、狭義のコンパイラ、アセンブラ、リンカ）を起動します。しかし、実際の仕事はドライバ・プログラムの中では一切行われないので、使用されるドライバ・プログラムが、指定されたターゲットとバージョンに対応したものでないことは通常は問題にはなりません。

ドライバ・プログラムの動きでターゲット・マシンに依存するのは、特殊なマシン固有オプションの解析と処理の部分だけです。しかし、この部分を実際に制御しているのは、指定されたバージョンとターゲット・マシンに対応したディレクトリの中に他の実行ファイルと一緒に置かれているあるファイルです。このため、インストールされているドライバ・プログラムがただ１つしかなくても、指定された任意のターゲット・マシンとコンパイラ・バージョンに適応することができるのです。

しかし、ドライバ・プログラムは１つ重要なことを制御します。それは、デフォルトのバージョンとターゲット・マシンです。このため、異なるターゲットやバージョンのためにコンパイルされた異なるドライバ・プログラムを、異なる名前を付けてインストールすることもありえます。

例えば、バージョン 2.0 用のドライバ・プログラムが ogcc という名前でインストールされていて、バージョン 2.1 用のものが gcc という名前でインストールされているのであれば、コマンド gcc を実行すればデフォルトでバージョン 2.1 が使われることになり、一方、 ogcc を実行すればデフォルトで 2.0 が使われることになります。しかし、どちらのコマンドを使った場合でも、 `-V' オプションによってどちらのバージョンでも指定することができます。

ハードウェアのモデルとコンフィギュレーション

既に、 Vax、 68000、 80386 のような完全に異なるターゲット・マシンに対応した複数の異なるインストール済みのコンパイラの中から選択するための標準オプション `-b' について議論しました。

これに加えて、これら個々のターゲット・マシン・タイプは、名前が `-m' で始まる特殊なオプションを持っています。これによって、例えば、 68010 と 68020、浮動小数点コプロセッサを持つものと持たないものなど、様々なハードウェアのモデルやコンフィギュレーションの中から選択することができます。インストールされたコンパイラがただ１つであっても、指定されたオプションにしたがって、任意のモデルやコンフィギュレーションをターゲットとするコンパイル処理を実行することができます。

コンパイラのコンフィギュレーションによっては、さらにこれ以上の特殊オプションもサポートされています。通常これは、同一プラットフォーム上の他のコンパイラとの互換性のためです。

これらのオプションは、マシン記述中のマクロ TARGET_SWITCHES により定義されます。これらのオプションのデフォルトも同じマクロにより定義されていますので、デフォルトを変更することが可能です。

M680x0 オプション

以下の `-m' オプションが 68000 シリーズに対して定義されています。これらのオプションのデフォルトの値は、コンパイラのコンフィギュレーションが行われた際に選択された 68000 の種類に依存します。最も一般的な選択肢に対するデフォルトが以下に示されています。

-m68000
-mc68000: 68000 用の出力を生成します。これは、 68000 ベースのシステム用のコンフィギュレーションがコンパイラに対して行われた場合のデフォルトです。
-m68020
-mc68020: 68020 用の出力を生成します。これは、 68020 ベースのシステム用のコンフィギュレーションがコンパイラに対して行われた場合のデフォルトです。
-m68881: 浮動小数点を処理するための 68881 の命令を含む出力を生成します。これは、コンパイラのコンフィギュレーションが行われた際に `-nfp' が指定されていなければ、ほとんどの 68020 システムに対するデフォルトとなります。
-m68030: 68030 用の出力を生成します。これは、 68030 ベースのシステム用のコンフィギュレーションがコンパイラに対して行われた場合のデフォルトです。
-m68040: 68040 用の出力を生成します。これは、 68040 ベースのシステム用のコンフィギュレーションがコンパイラに対して行われた場合のデフォルトです。このオプションは、 68040 上においてはソフトウェアによってエミュレートしなければならない 68881/68882 命令の使用を禁止します。使用している 68040 にこれらの命令をエミュレートするコードが存在しない場合、 `-m68040' を使ってください。
-m68060: 68060 用の出力を生成します。これは、 68060 ベースのシステム用のコンフィギュレーションがコンパイラに対して行われた場合のデフォルトです。このオプションは、 68060 上においてはソフトウェアによってエミュレートしなければならない 68020 命令と 68881/68882 命令の使用を禁止します。使用している 68060 にこれらの命令をエミュレートするコードが存在しない場合、 `-m68060' を使ってください。
-m5200: 520X "coldfire" ファミリの CPU 用の出力を生成します。これは、 520X ベースのシステム用のコンフィギュレーションがコンパイラに対して行われた場合のデフォルトです。
-m68020-40: 68040 において新規に導入された命令を一切使用することなく、 68040 用の出力を生成します。これにより、 68020/68881、 68030、もしくは 68040 において比較的効率よく実行可能なコードが生成されます。生成されたコードは、 68040 上においてはエミュレートされる 68881 の命令を使います。
-m68020-60: 68060 において新規に導入された命令を一切使用することなく、 68060 用の出力を生成します。これにより、 68020/68881、 68030、もしくは 68040 において比較的効率よく実行可能なコードが生成されます。生成されたコードは、 68060 上においてはエミュレートされる 68881 の命令を使います。
-mfpa: 浮動小数点を処理するための Sun FPA の命令を含む出力を生成します。
-msoft-float: 浮動小数点を処理するためのライブラリ呼び出しを含む出力を生成します。 注意: 必要となるライブラリは、すべての m68k ターゲットにおいて利用可能なわけではありません。通常、そのマシンにおいて通常使われる C コンパイラのライブラリが利用されますが、これはクロス・コンパイル環境では直接使うことができません。クロス・コンパイルを行う場合は、適切なライブラリ関数群を提供するための準備を自分で行わなければなりません。組み込みターゲットである `m68k-*-aout' や `m68k-*-coff' では、ソフトウェアによる浮動小数点のサポートが提供されています。
-mshort: 型 int は、 short int と同様 16 ビット幅であるとみなします。
-mnobitfield: ビット・フィールド命令を使いません。 `-m68000' オプションは暗黙のうちに `-mnobitfield' を意味します。
-mbitfield: ビット・フィールド命令を使います。 `-m68020' オプションは暗黙のうちに `-mbitfield' を意味します。 68020 用に設計されたコンフィギュレーションを使うと、これがデフォルトになります。
-mrtd: 異なる関数呼び出し規約を使います。この関数呼び出し規約では、引数の数が固定である関数は、復帰の際に引数をポップする rtd 命令を使って呼び出し元に復帰します。これにより呼び出し元では、引数をポップする必要がなくなるので、命令を１つ節約することができます。この呼び出し規約は、通常 Unix 上において使われる呼び出し規約とは互換性がありません。したがって、 Unix のコンパイラによりコンパイルされたライブラリを呼び出す必要がある場合には、これを使うことはできません。また、（printf も含めて）可変個数の引数を取るすべての関数について関数プロトタイプを提供しなければなりません。さもないと、これらの関数が呼び出されているところで、正しくないコードが生成されることになります。さらに、関数の呼び出しに際して引数の数が多すぎると、深刻な問題を持つコードが生成されてしまいます（通常であれば、余分な引数は実害なく無視されます）。 rtd 命令は、 68010、 68020、 68030、 68040、 68060 の各プロセッサによりサポートされていますが、 68000 や 5200 ではサポートされていません。
-malign-int
-mno-align-int: GNU CC による int、 long、 long long、 float、 double、 long double のそれぞれの型の変数の境界整列を、 32 ビット境界（`-malign-int'）にするか、 16 ビット境界（`-mno-align-int'）にするかを制御します。変数を 32 ビット境界に境界整列させると、生成されるコードはより多くのメモリを消費するようになりますが、 32 ビットのバスを持つプロセッサ上ではいくらか高速に実行されるようになります。 注意: `-malign-int' オプションを使うと、上記の型を含む構造体については、出版されている m68k のアプリケーション・バイナリ・インターフェイス仕様とは異なる境界整列が行われます。

VAX オプション

以下の `-m' オプションが Vax に対して定義されています。

-munix: ジャンプの距離が長い場合には、 Vax 用の Unix アセンブラが処理することのできない特定のジャンプ命令（aobleq 等）を出力しません。
-mgnu: GNU アセンブラを使ってアセンブルを行うと想定して、上記のジャンプ命令を出力します。
-mg: d フォーマットの浮動小数点数ではなく、 g フォーマットの浮動小数点数用のコードを出力します。

SPARC オプション

SPARC 上では以下の `-m' オプションがサポートされています。

-mno-app-regs

-mapp-regs

SPARC SVR4 ABI においてアプリケーション用として予約されている広域レジスタ 2 から広域レジスタ 4 までを使う出力を生成するには、 `-mapp-regs' を指定します。これがデフォルトです。いくらか性能を犠牲にしてでも、 SVR4 ABI に完全に準拠させるには、 `-mno-app-regs' を指定します。ライブラリやシステム・ソフトウェアは、こちらのオプションを指定してコンパイルするべきです。

-mfpu

-mhard-float

浮動小数点命令を含む出力を生成します。これがデフォルトです。

-mno-fpu

-msoft-float

浮動小数点を処理するためのライブラリ呼び出しを含む出力を生成します。 注意: 必要となるライブラリは、すべての SPARC ターゲットにおいて利用可能なわけではありません。通常、そのマシンにおいて通常使われる C コンパイラのライブラリが利用されますが、これはクロス・コンパイル環境では直接使うことができません。クロス・コンパイルを行う場合は、適切なライブラリ関数群を提供するための準備を自分で行わなければなりません。組み込みターゲットである `sparc-*-aout' や `sparclite-*-*' では、ソフトウェアによる浮動小数点のサポートが提供されています。 `-msoft-float' は、出力ファイルの中における呼び出し規約を変更します。したがって、プログラム全体をこのオプションを使ってコンパイルする場合にしか役に立ちません。このオプションが機能するようにするためには、特に、 GNU CC に付属しているライブラリである `libgcc.a' を `-msoft-float' を指定してコンパイルする必要があります。

-mhard-quad-float

４ワード（long double）の浮動小数点命令を含む出力を生成します。

-msoft-quad-float

４ワード（long double）の浮動小数点命令を実現するライブラリ呼び出しを含む出力を生成します。呼び出される関数群は、 SPARC ABI において指定されているものです。これがデフォルトです。これを書いている時点では、４ワードの浮動小数点命令に対するハードウェア・サポートを持つ sparc の実装はありません。どの sparc の実装においても、これらの命令に対してトラップ・ハンドラが起動され、そのトラップ・ハンドラがその命令の持つ効果をエミュレートします。トラップ・ハンドラのオーバヘッドのために、この方式は、 ABI ライブラリ・ルーチン群を呼び出すよりもはるかに遅くなります。したがって、 `-msoft-quad-float' オプションがデフォルトとなっています。

-mno-epilogue

-mepilogue

（デフォルトの） `-mepilogue' を指定すると、コンパイラは常に、関数を終了させるためのコードを個々の関数の末尾に出力します。関数の途中で関数を終了させるところ（例えば、 C の return 文）があると、関数の末尾に存在する関数終了コードのところへジャンプするコードが生成されます。 `-mno-epilogue' が指定されると、コンパイラは、関数を終了させるところすべてにおいて、関数終了コードをインライン出力しようと試みます。

-mno-flat

-mflat

`-mflat' が指定されると、コンパイラは、セーブ命令やリストア命令を生成せず、「フラットな」呼び出し規約、すなわち、単一レジスタ・ウィンドウ呼び出し規約（single register window calling convention）を使います。このモデルは %i7 をフレーム・ポインタとして使い、通常のレジスタ・ウィンドウ・モデルと互換性があります。両方のモデルのコードを混在させることは可能です。局所レジスタと入力レジスタ（0-5）は相変わらず「呼び出し時に待避される」レジスタとして扱われ、必要に応じてスタック上に待避されます。（デフォルトの） `-mno-flat' が指定されると、コンパイラは、（リーフ関数（leaf function）を除けば）セーブ命令やリストア命令を出力し、通常の動作モードとなります。

-mno-unaligned-doubles

-munaligned-doubles

double 型は 8 バイト単位に境界整列されると想定します。これがデフォルトです。 `-munaligned-doubles' が指定されると、 GNU CC は、別の型の中に含まれる場合や絶対アドレスが指定されている場合のみ、 double 型は 8 バイト単位に境界整列されると想定します。これら以外の場合には、 4 バイト単位の境界整列を持つものと想定します。このオプションを指定することにより、他のコンパイラにより生成されたコードとの組合わせで稀に発生するいくつかの互換性の問題を回避することができます。特に浮動小数点関連のコードで性能の劣化が引き起こされるために、このオプションはデフォルトにはなっていません。

-mv8

-msparclite

これら２つのオプションは、 SPARC アーキテクチャの種類を選択するものです。デフォルトでは（富士通 SPARClite 用に特別なコンフィギュレーションが行われていない限り） GCC は v7 という種類の SPARC アーキテクチャ用のコードを生成します。 `-mv8' を指定すると、 SPARC v8 のコードが生成されます。 v7 コードとの唯一の違いは、 SPARC v7 には存在しないが SPARC v8 には存在する、整数乗算命令と整数除算命令をコンパイラが出力するということです。 `-msparclite' を指定すると、 SPARClite 用のコードが生成されます。これにより、 SPARC v7 には存在しないが SPARClite には存在する、整数乗算命令、整数除算命令、および、ステップ・アンド・スキャン（ffs）命令が追加されます。これらのオプションは使わないようお願いします。 GNU CC 2.9 では、これらのオプションは削除される予定です。これらのオプションに取って代わるものとして、 `-mcpu=xxx' が提供されています。

-mcypress

-msupersparc

これら２つのオプションは、コードがどのプロセッサ用に最適化されるかを選択するものです。（デフォルトの） `-mcypress' が指定されると、コンパイラは、 SparcStation/SparcServer 3xx シリーズに使われている Cypress CY7C602 チップ用にコードを最適化します。このオプションは、より古い SparcStation 1、 2、 IPX 等に対しても適切です。 `-msupersparc' が指定されると、コンパイラは、 SparcStation 10、 1000、 2000 シリーズに使われている SuperSparc CPU 用にコードを最適化します。また、このフラグは SPARC v8 の命令セット全体を使えるようにします。これらのオプションは使わないようお願いします。 GNU CC 2.9 では、これらのオプションは削除される予定です。これらのオプションに取って代わるものとして、 `-mcpu=xxx' が提供されています。

-mcpu=cpu_type

マシン・タイプ cpu_type の命令セット、レジスタ・セット、命令スケジューリング・パラメータを設定します。 cpu_type としてサポートされる値は、 `v7'、 `cypress'、 `v8'、 `supersparc'、 `sparclite'、 `f930'、 `f934'、 `sparclet'、 `tsc701'、 `v9'、 `ultrasparc' です。アーキテクチャを選択するだけで具体的な実装まで選択しない値については、デフォルトの命令スケジューリング・パラメータが使われます。該当する値は、 `v7'、 `v8'、 `sparclite'、 `sparclet'、 `v9' です。以下に、サポートされる個々のアーキテクチャと、そのアーキテクチャにおいてサポートされる実装とのリストを示します。

    v7:             cypress
    v8:             supersparc
    sparclite:      f930, f934
    sparclet:       tsc701
    v9:             ultrasparc

-mtune=cpu_type

マシン・タイプ cpu_type の命令スケジューリング・パラメータを設定します。しかし、オプション `-mcpu='cpu_type のように、命令セットやレジスタ・セットの設定は行いません。 `-mtune='cpu_type についても、 `-mcpu='cpu_type と同じ値が使われます。しかし、実際に使って役に立つ値は、特定の CPU 実装を選択する値だけです。該当するのは、 `cypress'、 `supersparc'、 `f930'、 `f934'、 `tsc701'、 `ultrasparc' です。

-malign-loops=num

2 を num 乗したバイト数単位にループを境界整列します。 `-malign-loops' が指定されないと、デフォルトの num の値は 2 となります。

-malign-jumps=num

ジャンプ命令によってのみ到達される命令を、 2 を num 乗したバイト数単位に境界整列します。 `-malign-jumps' が指定されないと、デフォルトの num の値は 2 となります。

-malign-functions=num

関数の先頭を、 2 を num 乗したバイト数単位に境界整列します。 `-malign-functions' が指定されないと、デフォルトの num の値は、 32 ビット sparc 用にコンパイルしている場合は 2、 64 ビット sparc 用にコンパイルしている場合は 5 となります。

SPARCLET プロセッサ上においては、上記のオプションに加えて、以下の `-m' オプションがサポートされています。

-mlittle-endian: リトル・エンディアン・モードで動作しているプロセッサ用のコードを生成します。
-mlive-g0: レジスタ %g0 を通常のレジスタとして扱います。 GCC は相変わらずこのレジスタの内容を必要に応じて破壊しますが、このレジスタの値を読むと常に 0 が返ってくるという想定は行わなくなります。
-mbroken-saverestore: save 命令、 restore 命令のうち単純形式以外のものを使わないコードを生成します。 SPARCLET プロセッサの初期のバージョンでは、引数付きの save 命令、 restore 命令が正しく処理されません。引数付きでない save 命令、 restore 命令は正しく処理されます。引数付きでない save 命令は、カレントなウィンドウ・ポインタをインクリメントしますが、新しいスタック・フレームを割り当てません。割り込みハンドラと同様の方法で、ウィンドウ・オーバフローのトラップ・ハンドラがこのようなケースを適切に処理するものと想定されています。

SPARC V9 プロセッサ上の 64 ビット環境では、上記のオプションに加えて、以下の `-m' オプションがサポートされています。

-mlittle-endian: リトル・エンディアン・モードで動作しているプロセッサ用のコードを生成します。
-m32
-m64: 32 ビット環境用、もしくは、 64 ビット環境用のコードを生成します。 32 ビット環境では、 int 型、 long 型、および、ポインタ型は 32 ビットになります。 64 ビット環境では、 int 型は 32 ビットに、 long 型とポインタ型は 64 ビットになります。
-mcmodel=medlow: Medium/Low コード・モデル用のコードを生成します。プログラムは、アドレス空間の低位 32 ビットの範囲でリンクされなければなりません。ポインタは 64 ビットです。プログラムは、静的にリンクすることも動的にリンクすることもできます。
-mcmodel=medmid: Medium/Middle コード・モデル用のコードを生成します。プログラムは、アドレス空間の低位 44 ビットの範囲でリンクされなければなりません。テキスト・セグメントの大きさは 2G バイト未満でなければならず、データ・セグメントはテキスト・セグメントの 2G バイトの範囲になければなりません。ポインタは 64 ビットです。
-mcmodel=medany: Medium/Anywhere コード・モデル用のコードを生成します。プログラムは、アドレス空間の任意の位置にリンクすることができます。テキスト・セグメントの大きさは 2G バイト未満でなければならず、データ・セグメントはテキスト・セグメントの 2G バイトの範囲になければなりません。ポインタは 64 ビットです。
-mcmodel=embmedany: 組み込みシステムの Medium/Anywhere コード・モデル用のコードを生成します。（リンク時に決定される）任意の位置から始まる、 32 ビットのテキスト・セグメントと 32 ビットのデータ・セグメントの存在を想定します。レジスタ %g4 は、データ・セグメントのベース・アドレスを指します。ここでも、ポインタは 64 ビットです。プログラムは静的にリンクされ、 PIC(7)はサポートされません。
-mstack-bias
-mno-stack-bias: `-mstack-bias' が指定されると、 GNU CC は、スタック・ポインタ、および、フレーム・ポインタが存在する場合にはフレーム・ポインタも、 -2047 だけオフセットされていると想定します。スタック・フレームを参照する際には、この数が再加算されなければなりません。 `-mstack-bias' が指定されなければ、そのようなオフセットは存在しないと想定されます。

Convex オプション

以下の `-m' オプションが Convex に対して定義されています。

-mc1: C1 用の出力を生成します。生成されたコードは、任意の Convex マシン上に置いて動作します。プリプロセッサ・シンボル __convex__c1__ が定義されます。
-mc2: C2 用の出力を生成します。 C1 上では利用できない命令を使います。スケジューリングやその他の最適化は、 C2 上での性能を最大化するものが選択されます。プリプロセッサ・シンボル __convex_c2__ が定義されます。
-mc32: C32xx 用の出力を生成します。 C1 上では利用できない命令を使います。スケジューリングやその他の最適化は、 C32 上での性能を最大化するものが選択されます。プリプロセッサ・シンボル __convex_c32__ が定義されます。
-mc34: C34xx 用の出力を生成します。 C1 上では利用できない命令を使います。スケジューリングやその他の最適化は、 C34 上での性能を最大化するものが選択されます。プリプロセッサ・シンボル __convex_c34__ が定義されます。
-mc38: C38xx 用の出力を生成します。 C1 上では利用できない命令を使います。スケジューリングやその他の最適化は、 C38 上での性能を最大化するものが選択されます。プリプロセッサ・シンボル __convex_c38__ が定義されます。
-margcount: 個々の引数リストの１つ前のワード領域に引数の個数を入れるコードを生成します。これは普通の CC と互換性がありますし、引数の個数が入ったワードを必要とするプログラムも少しはあるかもしれません。 GDB やその他のソース・レベル・デバッガは、引数の個数が入ったワードを必要としません。この情報は、シンボル・テーブルの中にあります。
-mnoargcount: 引数の個数が入ったワードを省略します。これがデフォルトです。
-mvolatile-cache: volatile 指定された参照がキャッシュされることを許します。これがデフォルトです。
-mvolatile-nocache: volatile 指定された参照は、データ・キャッシュを無視して、メモリにアクセスします。これは、標準的な同期命令（synchronization instruction）を使わないマルチプロセッサ・コードにおいてのみ必要となります。 volatile 指定された箇所に対する volatile 指定されていない参照は、必ずしも機能するとは限りません。
-mlong32: long 型は int 型と同様 32 ビットになります。これがデフォルトです。
-mlong64: long 型は long long 型と同様 64 ビットになります。これに対するライブラリ・サポートが存在しないため、このオプションは役に立ちません。

AMD29K オプション

以下の `-m' オプションが AMD Am29000に対して定義されています。

-mdw: DW ビットがセットされている、すなわち、バイト演算と半ワード演算はハードウェアにより直接サポートされていると想定したコードを生成します。これがデフォルトです。
-mndw: DW ビットはセットされていないと想定したコードを生成します。
-mbw: バイトの書き込み演算と半ワードの書き込み演算をシステムがサポートしていると想定したコードを生成します。これがデフォルトです。
-mnbw: バイトの書き込み演算と半ワードの書き込み演算をシステムがサポートしていないと想定したコードを生成します。 `-mnbw' は暗黙のうちに `-mndw' を意味します。
-msmall: すべての関数アドレスは、単一の 256 KB セグメントの範囲にあるか、もしくは、 256k 未満の絶対アドレスにあると想定する、スモール・メモリ・モデルを使います。これにより、 const、 consth、 calli という命令シーケンスの代わりに、 call 命令を使うことができるようになります。
-mnormal: ノーマル・メモリ・モデルを使います。同一ファイル内に存在する関数を呼び出す場合のみ call 命令を生成し、それ以外の場合には calli 命令を生成します。これは、個々のファイルにより占有されるサイズが 256 KB 未満の場合に機能するものですが、実行ファイル全体の大きさは 256 KB を超えても構いません。これがデフォルトです。
-mlarge: 常に calli 命令を使います。１つのファイルをコンパイルすると 256 KB を超えるコードが生成されると考えられる場合に、このオプションを指定してください。
-m29050: Am29050 用のコードを生成します。
-m29000: Am29000 用のコードを生成します。これがデフォルトです。
-mkernel-registers: レジスタ群 gr96-gr127 への参照の代わりにレジスタ群 gr64-gr95 への参照を生成します。ユーザ・モードのコードにより使われるレジスタ群とは別の広域レジスタ群の集合を利用したいカーネル・コードをコンパイルする際に、このオプションを使うことができます。このオプションを使う場合には、 `-f' フラグにおけるレジスタ名には、通常のユーザ・モードの名前を使わなければならない点に注意してください。
-muser-registers: 通常の広域レジスタ集合 gr96-gr127 を使います。これがデフォルトです。
-mstack-check
-mno-stack-check: 個々のスタック調整処理の後ろに __msp_check を呼び出すコードを挿入します（あるいは、挿入しません）。これはしばしば、カーネル・コードに対して使用されます。
-mstorem-bug
-mno-storem-bug: `-mstorem-bug' は、 mtsrim insn と storem 命令との分離を処理できない 29k プロセッサに対処します（現在までのほとんどの 29000 チップが該当しますが、 29050 は該当しません）。
-mno-reuse-arg-regs
-mreuse-arg-regs: `-mno-reuse-arg-regs' は、出力引数をコピーするという用途にのみ入力引数のレジスタを使うよう、コンパイラに指示します。これは、関数宣言における引数の個数よりも少ない個数の引数を使った関数呼び出しを検出するのに役に立ちます。
-mno-impure-text
-mimpure-text: `-shared' に加えて `-mimpure-text' を使うと、共用オブジェクトをリンクする際にリンカに対して `-assert pure-text' を渡さないよう、コンパイラに指示します。
-msoft-float: 浮動小数点を処理するためのライブラリ呼び出しを含む出力を生成します。 注意: 必要となるライブラリは GNU CC には含まれていません。通常、そのマシンにおいて通常使われる C コンパイラのライブラリが利用されますが、これはクロス・コンパイル環境では直接使うことができません。クロス・コンパイルを行う場合は、適切なライブラリ関数群を提供するための準備を自分で行わなければなりません。

ARM オプション

以下の `-m' オプションが Advanced RISC Machines (ARM) アーキテクチャに対して定義されています。

-mapcs-frame: コードを正しく実行するために厳密には必要ではない場合でも、すべての関数に対して、 ARM Procedure Call Standard と互換性のあるスタック・フレームを生成します。
-mapcs-26: 26 ビットのプログラム・カウンタを使って動作し、かつ、 APCS 26 ビット・オプションの関数呼び出し標準に準拠するプロセッサ用のコードを生成します。このオプションは、このコンパイラの以前のリリースにおける `-m2' オプションと `-m3' オプションに取って代わるものです。
-mapcs-32: 32 ビットのプログラム・カウンタを使って動作し、かつ、 APCS 32 ビット・オプションの関数呼び出し標準に準拠するプロセッサ用のコードを生成します。このオプションは、このコンパイラの以前のリリースにおける `-m6' オプションに取って代わるものです。
-mhard-float: 浮動小数点命令を含む出力を生成します。これがデフォルトです。
-msoft-float: 浮動小数点を処理するためのライブラリ呼び出しを含む出力を生成します。 注意: 必要となるライブラリは、すべての ARM ターゲットにおいて利用可能なわけではありません。通常、そのマシンにおいて通常使われる C コンパイラのライブラリが利用されますが、これはクロス・コンパイル環境では直接使うことができません。クロス・コンパイルを行う場合は、適切なライブラリ関数群を提供するための準備を自分で行わなければなりません。 `-msoft-float' は、出力ファイルの中における呼び出し規約を変更します。したがって、プログラム全体をこのオプションを使ってコンパイルする場合にしか役に立ちません。このオプションが機能するようにするためには、特に、 GNU CC に付属しているライブラリである `libgcc.a' を `-msoft-float' を指定してコンパイルする必要があります。
-mlittle-endian: リトル・エンディアン・モードで動作しているプロセッサ用のコードを生成します。これは、すべての標準的なコンフィギュレーションのデフォルトです。
-mbig-endian: ビッグ・エンディアン・モードで動作しているプロセッサ用のコードを生成します。デフォルトでは、リトル・エンディアン用にコードをコンパイルします。
-mwords-little-endian: このオプションは、ビッグ・エンディアンのプロセッサ用にコードを生成している場合にのみ当てはまります。ワード・オーダはリトル・エンディアンで、しかし、バイト・オーダはビッグ・エンディアンでコードを生成します。これはすなわち、 `32107654' という形式のバイト・オーダとなります。注: このオプションは、バージョン 2.8 よりも前のコンパイラによって生成された、ビッグ・エンディアンの ARM プロセッサ用のコードとの互換性が必要である場合にのみ、使われるべきものです。
-mshort-load-bytes: 境界整列されていないアドレスから１ワードをロードすることによって半ワード（例えば `short'）をロードしようと試みません。ターゲットによっては、境界整列されていない箇所からのロードをトラップするよう MMU が設定されていることがあります。このような環境でも安全なコードを生成するには、このオプションを使ってください。
-mno-short-load-bytes: 半ワード（例えば `short'）をロードするのに、境界整列されていないワードのロードを使います。このオプションは、より効率的なコードを生成しますが、時には MMU がこのような命令をトラップするよう設定されていることがあります。
-mbsd: このオプションは、 RISC iX にのみ当てはまります。ネイティブな BSD モードのコンパイラをエミュレートします。 `-ansi' が指定されていないと、これがデフォルトになります。
-mxopen: このオプションは、 RISC iX にのみ当てはまります。ネイティブな X/Open モードのコンパイラをエミュレートします。
-mno-symrename: このオプションは、 RISC iX にのみ当てはまります。コードがアセンブルされた後に、アセンブラのポストプロセッサ `symrename' を実行しません。通常は、 RISC iX の C ライブラリとリンクするための準備として、標準シンボルのいくつかを修正する必要があります。このオプションによって、このパスは実行されなくなります。このポストプロセッサは、コンパイラがクロス・コンパイル用として構築されている場合には、まったく実行されません。

MN10300 オプション

以下の `-m' オプションが松下 MN10300 アーキテクチャに対して定義されています。

-mmult-bug: MN10300 プロセッサの乗算命令のバグを回避するコードを生成します。これがデフォルトです。
-mno-mult-bug: MN10300 プロセッサの乗算命令のバグを回避するコードを生成しません。

M32R/D Options

以下の `-m' オプションが三菱 M32R/D アーキテクチャに対して定義されています。

-mcode-model=small: すべてのオブジェクトは（そのアドレスを ld24 命令によってロードすることができるように）メモリの低位 16MB の範囲に存在するものと想定します。また、すべてのサブルーチンは bl 命令によって到達可能であると想定します。これがデフォルトです。特定のオブジェクトのアドレス範囲（addressability）は、 model 属性によって設定できます。
-mcode-model=medium: 32 ビットのアドレス空間の任意の位置にオブジェクトが存在できると想定します（コンパイラは、オブジェクトのアドレスをロードするために seth/add3 命令を生成します）。また、すべてのサブルーチンは bl 命令により到達可能であると想定します。
-mcode-model=large: 32 ビットのアドレス空間の任意の位置にオブジェクトが存在できると想定します（コンパイラは、オブジェクトのアドレスをロードするために seth/add3 命令を生成します）。また、サブルーチンは bl 命令により到達不可能である場合もあると想定します（コンパイラは、はるかに性能の悪い seth/add3/jl という命令シーケンスを生成します）。
-msdata=none: スモール・データ域を使用できないようにします。変数は、（section 属性が指定されない限り） `.data'、 `bss'、 `.rodata' のいずれか１つの中に置かれます。これがデフォルトです。スモール・データ域は、 `.sdata' セクションと `.sbss' セクションから構成されます。 section 属性にこれらのセクションの１つを指定することにより、オブジェクトを明示的にスモール・データ域に置くことができます。
-msdata=sdata: サイズの小さい広域データと静的データをスモール・データ域に置きますが、それらを参照するための特殊なコードは生成しません。
-msdata=use: サイズの小さい広域データと静的データをスモール・データ域に置き、それらを参照するための特殊な命令を生成します。
-G num: num バイト以下の広域オブジェクトと静的オブジェクトを、通常の data セクション、 bss セクションではなく、 small data セクション、 small bss セクションに置きます。 num のデフォルトの値は 8 です。このオプションが効力を持つためには、 `-msdata' オプションは `sdata' と `use' のいずれかに設定されていなければなりません。すべてのモジュールが、同じ `-G num' の値を指定してコンパイルされなければなりません。 num に異なる値を指定してコンパイルすると、うまく行くこともありますし、うまく行かないこともあります。うまく行かない場合は、リンカがエラー・メッセージを出力します。正しくないコードが生成されることはありません。

M88K オプション

以下の `-m' が Motorola 88k アーキテクチャに対して定義されています。

-m88000

m88100 と m88110 の両方で正しく動作するコードを生成します。

-m88100

m88100 上で最適に動作し、 m88110 上でも動作するコードを生成します。

-m88110

m88110 上で最適に動作し、 m88100 上では動作しないかもしれないコードを生成します。

-mbig-pic

次のリビジョンでは削除される予定の古いオプションです。 `-fPIC' を使ってください。

-midentify-revision

アセンブラ出力の中に、ソース・ファイルの名前、コンパイラの名前、コンパイラのバージョン、タイムスタンプ、使用したコンパイル・フラグを記録する ident 指示子を含めます。

-mno-underscores

アセンブラ出力の中に、個々のシンボル名の先頭にアンダースコア文字を追加することなく、シンボル名を出力します。デフォルトでは、個々の名前の接頭語としてアンダースコアを使います。

-mocs-debug-info

-mno-ocs-debug-info

88open Object Compatibility Standard（OCS）において指定されている（個々のスタック・フレームにおいて使われるレジスタに関する）追加的なデバッグ情報を含めます（あるいは、省きます）。この余分の情報により、フレーム・ポインタの除去されたコードをデバッグすることができるようになります。 DG/UX、 SVr4、 Delta 88 SVr3.2 のデフォルトではこの情報を含めます。他の 88k のコンフィギュレーションでは、デフォルトではこの情報を省きます。

-mocs-frame-position

スタック上に置かれる自動変数やパラメータに関する COFF デバッグ情報を出力する際に、正規フレーム・アドレス（canonical frame address）からのオフセットを使います。正規フレーム・アドレスは、その関数に入った時点におけるスタック・ポインタ（レジスタ 31）の値です。 DG/UX、 SVr4、 Delta88 SVr3.2、 BCS の各コンフィギュレーションでは、 `-mocs-frame-position' を使います。他の 88k コンフィギュレーションのデフォルトは、 `-mno-ocs-frame-position' です。

-mno-ocs-frame-position

スタック上に置かれる自動変数やパラメータに関する COFF デバッグ情報を出力する際に、フレーム・ポインタ・レジスタ（レジスタ 30）からのオフセットを使います。このオプションが使われている時には、 -g オプションによってデバッグ情報を出力するよう選択されている場合に、フレーム・ポインタは除去されません。

-moptimize-arg-area

-mno-optimize-arg-area

関数の引数がどのようにスタック・フレーム上に置かれるかを制御します。 `-moptimize-arg-area' は、これを最適化することによって領域を節約しますが、これは 88open の仕様に矛盾します。逆の選択肢である `-mno-optimize-arg-area' は、 88open の仕様に従います。デフォルトでは、 GNU CC は引数領域の最適化を行いません。

-mshort-data-num

データへの参照は r0 への相対とすることにより、データ参照に要するコードをより少なくします。（通常、値をロードするのには２命令が必要になりますが、）これにより、ただ１つの命令によって値をロードすることができるようになります。このオプションの num の指定によって、どのデータ参照が影響を受けるかを制御することができます。例えば、 `-mshort-data-512' を指定すると、 512 バイト未満のデータの移動にかかわるデータ参照が影響を受けることになります。 num の値が 64k を超えると、 `-mshort-data-num' は効力を持ちません。

-mserialize-volatile

-mno-serialize-volatile

volatile 指定されたメモリ参照の順序の一貫性を保証するコードを生成する、もしくは、生成しません。デフォルトでは、順序の一貫性は保証されます。 MC88110 プロセッサにより実行されるメモリ参照の順序は、それらのメモリ参照を要求した命令の順序とは必ずしも一致しません。特に、ロード命令は、それよりも前にあるストア命令よりも前に実行されるかもしれません。このような順序変更は、プロセッサが複数ある場合に、 volatile 指定されたメモリ参照の順序の一貫性を損なうことになります。一貫性が保証されなければならない場合には、正しい順序での実行を強制するために、 GNU C は必要に応じて特殊な命令を生成します。 MC88100 プロセッサはメモリ参照の順序を変更しないので、常に順序の一貫性が実現されます。しかし、 `-m88100' が使われた場合でも、生成されたコードが MC88110 プロセッサ上で実行できるように、デフォルトでは、一貫性を保証するための特殊な命令を GNU C は生成します。生成されたコードを MC88100 プロセッサ上でのみ実行するつもりであれば、 `-mno-serialize-volatile' を使うことができます。一貫性を保証するために生成された余分のコードがアプリケーションの性能に影響を与えることがあるかもしれません。このような保証なしで済ませても安全であると分かっているのであれば、 `-mno-serialize-volatile' を使うことができます。

-msvr4

-msvr3

System V リリース 4 （SVr4）に関連するコンパイラの拡張機能を有効（`-msvr4'）もしくは無効（`-msvr3'）にします。これにより、以下のことが制御されます。

出力されるアセンブラ言語の構文の種類が指定されます。
`-msvr4' が指定されると、 C プリプロセッサは、 System V リリース 4 上で使われる `#pragma weak' を認識するようになります。
`-msvr4' が指定されると、 GNU CC は、 SVr4 で使われる追加的な宣言指示子（declaration directive）を出力するようになります。

`-msvr4' は、 m88k コンフィギュレーションのうち m88k-motorola-sysv4 と m88k-dg-dgux のデフォルトです。 `-msvr3' は、その他すべての m88k コンフィギュレーションのデフォルトです。

-mversion-03.00

このオプションは古くなってしまい、無視されます。

-mno-check-zero-division

-mcheck-zero-division

０（ゼロ）による整数除算の検出を保証するコードを生成する、もしくは、生成しません。デフォルトでは、検出は保証されます。 MC88100 プロセッサのいくつかのモデルは、特定の条件下においては、０（ゼロ）による整数除算を正しくトラップすることができません。デフォルトでは、そのような種類のプロセッサ上で実行される可能性のあるコードをコンパイルする際に、 GNU C は、値が０（ゼロ）である除数を明示的にチェックして、それを検出すると例外番号 503 でトラップするコードを生成します。 mno-check-zero-division を使うと、 MC88100 プロセッサ上で実行するために生成されるコードに関しては、そのようなチェックは行われなくなります。 GNU C は、 MC88110 プロセッサは０（ゼロ）による除算をすべて正しく検出できるものと想定します。 `-m88110' が指定されると、 `-mcheck-zero-division' と `-mno-check-zero-division' は無視され、値が０（ゼロ）である除数に対して明示的なチェックを行うコードは生成されません。

-muse-div-instruction

MC88100 プロセッサ上における有符合整数の除算に div 命令を使います。デフォルトでは、 div 命令は使われません。 MC88100 プロセッサ上では、負のオペランドに対して有符合整数除算命令 div を使うと、オペレーティング・システムに対してトラップが発生します。オペレーティング・システムは透過的にこの操作を完了しますが、実行時間は大きく犠牲にされます。デフォルトでは、 MC88100 プロセッサ上で実行される可能性のあるコードをコンパイルする際に、 GNU C は、無符合整数除算命令 divu を使って有符合整数の除算をエミュレートすることによって、オペレーティング・システムに対してトラップを発生させることによる大きな損失を回避します。このようなエミュレーションもまた、より少なくはあるものの、時間と領域の両方の点で実行上のコストがかかります。ユーザのコードの中で重要な有符合整数除算演算が２つの非負のオペランドに対して実行されている範囲では、直接 div 命令を使った方が望ましいかもしれません。 MC88110 プロセッサ上では、（divs 命令としても知られている） div 命令は、オペレーティング・システムに対してトラップを発生させることなく負のオペランドを処理します。 `-m88110' が指定されると、 `-muse-div-instruction' は無視され、有符合整数の除算に対しては div 命令が使われます。 INT_MIN を -1 で除算した結果は不定である点に注意してください。特に、 `-muse-div-instruction' を指定した場合と指定しない場合とでは、この除算の振る舞いは変わる可能性があります。

-mtrap-large-shift

-mhandle-large-shift

31 ビットを超えるビット・シフトを検出するコードを挿入します。そのようなシフトの１つ１つをトラップするか、もしくは、それらを正しく処理するためのコードを出力します。デフォルトでは、 GNU CC は、シフト数の大きいビット・シフトに対して特別な準備を行いません。

-mwarn-passed-structs

引数や戻り値として構造体を渡す関数があると、警告します。 C 言語の進化の過程において構造体渡しの規約は変更されてきていて、これがしばしば移植性における問題を引き起こす原因になっています。デフォルトでは、 GNU CC はそのような警告を出力しません。

IBM RS/6000、PowerPC オプション

以下の `-m' オプションが IBM RS/6000 と PowerPC に対して定義されています。

-mpower
-mno-power
-mpower2
-mno-power2
-mpowerpc
-mno-powerpc
-mpowerpc-gpopt
-mno-powerpc-gpopt
-mpowerpc-gfxopt
-mno-powerpc-gfxopt: GNU CC は、 RS/6000 と PowerPC に対して２つの関連する命令セット・アーキテクチャをサポートしています。 POWER 命令セットは、初期の RS/6000 システムにおいて使われていた `rios' チップ・セットによりサポートされている命令群です。一方、 PowerPC 命令セットは、 Motorola MPC5xx、 MPC6xx、 MPC8xx マイクロプロセッサと IBM 4xx マイクロプロセッサのアーキテクチャです。どちらのアーキテクチャも他方のサブセットではありません。しかし、両方のアーキテクチャによってサポートされるかなりの数の共通命令サブセットが存在します。 POWER アーキテクチャをサポートするプロセッサには、 MQ レジスタが含まれています。これらのオプションを使って、使用しているプロセッサ上において利用可能な命令群を指定します。これらのオプションのデフォルト値は、 GNU CC のコンフィギュレーションを行う際に決定されます。 `-mcpu=cpu_type' を指定すると、これらオプションのデフォルトの指定は無効になります。上にリストされているオプションよりも、 `-mcpu=cpu_type' オプションを使うようお勧めします。 `-mpower' オプションが指定されると GNU CC は、 POWER アーキテクチャにのみ存在する命令の生成と MQ レジスタの使用ができるようになります。 `-mpower2' を指定すると、暗黙のうちに `-power' が指定されたことになり、この場合 GNU CC は、初期の POWER アーキテクチャには存在しないが POWER2 アーキテクチャには存在する命令を生成することができるようになります。 `-mpowerpc' オプションが指定されると GNU CC は、 PowerPC アーキテクチャの 32 ビット・サブセットにのみ存在する命令群を生成することができるようになります。 `-mpowerpc-gpopt' を指定すると、暗黙のうちに `-mpowerpc' が指定されたことになり、この場合 GNU CC は、浮動小数点平方根を含む、 General Purpose グループに属する任意選択の PowerPC アーキテクチャ命令群を使うことができるようになります。 `-mpowerpc-gfxopt' を指定すると、暗黙のうちに `-mpowerpc' が指定されたことになり、この場合 GNU CC は、浮動小数点セレクトを含む、 Graphics グループに属する任意選択の PowerPC アーキテクチャ命令群を使うことができるようになります。 `-mno-power' と `-mno-powerpc' を両方とも指定すると、 GNU CC は、両方のアーキテクチャの共通サブセットに属する命令群だけを使います。またこれに加えて、いくつかの特殊な AIX 共通モード呼び出し（common-mode call）を使い、 MQ レジスタは使いません。 `-mpower' と `-mpowerpc' が両方とも指定されると、 GNU CC は、いずれかのアーキテクチャに存在するものであれば任意の命令を使うことができるようになり、 MQ レジスタの使用もできるようになります。これは、 Motorola MPC601 に対して指定してください。
-mnew-mnemonics
-mold-mnemonics: 生成されるアセンブラ・コードの中で使われるニーモニックを選択します。 `-mnew-mnemonics' は、 PowerPC アーキテクチャに対して定義されたアセンブラ・ニーモニックを使った出力を要求するものです。一方、 `-mold-mnemonics' は、 POWER アーキテクチャに対して定義されたアセンブラ・ニーモニックを要求します。１つのアーキテクチャにおいてのみ定義されている命令に対しては、ただ１つのニーモニックしか存在しないので、どちらのオプションが指定されたかに関わりなく、そのニーモニックを GNU CC は使うことになります。 PowerPC アセンブラは、新旧両方のニーモニックをサポートしています。また、 POWER アセンブラも将来そうなる予定です。現在の POWER アセンブラは古いニーモニックのみをサポートしています。新しいニーモニックをサポートしているアセンブラがある場合には `-mnew-mnemonics' を指定してください。そうでない場合は、 `-mold-mnemonics' を指定してください。これらのオプションのデフォルト値は、 GNU CC のコンフィギュレーションがどのように行われたかに依存します。 `-mcpu=cpu_type' が指定されると、時にはこのオプションのデフォルトの値が無効になることがあります。クロス・コンパイラを作成しようとしているのでなければ、通常は `-mnew-mnemonics' も `-mold-mnemonics' も指定するべきではなく、デフォルトを受け入れるべきです。
-mcpu=cpu_type: マシン・タイプ cpu_type に対応したアーキテクチャ・タイプ、レジスタ使用、ニーモニック選択、命令スケジューリング・パラメータを設定します。 cpu_type としてサポートされている値は、 `rs6000'、 `rios1'、 `rios2'、 `rsc'、 `601'、 `602'、 `603'、 `603e'、 `604'、 `604e'、 `620'、 `power'、 `power2'、 `powerpc'、 `403'、 `505'、 `801'、 `821'、 `823'、 `860'、 `common' です。 `-mcpu=power'、 `-mcpu=power2'、 `-mcpu=powerpc' はそれぞれ、一般的な POWER、 POWER2、および、純粋な（すなわち、 MPC601 ではない） PowerPC アーキテクチャのマシン・タイプを指定し、スケジューリングについては一般的なプロセッサ・モデルを想定します。オプション `-mcpu=rios1'、 `-mcpu=rios2'、 `-mcpu=rsc'、 `-mcpu=power'、 `-mcpu=power2' のうちいずれかを指定すると、 `-mpower' オプションが有効になり、 `-mpowerpc' オプションが無効になります。 `-mcpu=601' は、 `-mpower' オプションと `-mpowerpc' オプションの両方を有効にします。 `-mcpu=602'、 `-mcpu=603'、 `-mcpu=603e'、 `-mcpu=604'、 `-mcpu=620' はいずれも `-mpowerpc' オプションを有効にし、 `-mpower' オプションを無効にします。まったく同様に、 `-mcpu=403'、 `-mcpu=505'、 `-mcpu=821'、 `-mcpu=860'、 `-mcpu=powerpc' はいずれも `-mpowerpc' オプションを有効にし、 `-mpower' オプションを無効にします。 `-mcpu=common' は、 `-mpower' オプションと `-mpowerpc' オプションの両方を無効にします。 AIX のバージョン 4 以降ではデフォルトで `-mcpu=common' が選択されるので、生成されるコードはすべての RS/6000 ファミリと PowerPC ファミリのメンバ上で動作するでしょう。この場合 GNU CC は、両方のアーキテクチャの共通サブセットに属する命令群といくつかの特殊な AIX 共通モード呼び出し（common-mode call）だけを使い、 MQ レジスタは使いません。 GNU CC は、スケジューリングについては、一般的なプロセッサ・モデルを想定します。オプション `-mcpu=rios1'、 `-mcpu=rios2'、 `-mcpu=rsc'、 `-mcpu=power'、 `-mcpu=power2' のいずれかを指定すると、 `new-mnemonics' オプションが無効になります。 `-mcpu=601'、 `-mcpu=602'、 `-mcpu=603'、 `-mcpu=603e'、 `-mcpu=604'、 `620'、 `403'、 `-mcpu=powerpc' を指定すると、 `new-mnemonics' オプションが有効になります。 `-mcpu=403'、 `-mcpu=821'、 `-mcpu=860' を指定すると、 `-msoft-float' オプションが有効になります。
-mtune=cpu_type: マシン・タイプ cpu_type に対応した命令スケジューリング・パラメータを設定しますが、 `-mcpu='cpu_type のようにアーキテクチャ・タイプ、レジスタ使用、ニーモニック選択を設定することはありません。 `-mcpu='cpu_type において cpu_type として使われるのと同じ値が、 `-mtune='cpu_type においても使われます。命令スケジューリング・パラメータに関してのみ、 `-mtune='cpu_type オプションは `-mcpu='cpu_type オプションによる指定を無効にします。
-mfull-toc
-mno-fp-in-toc
-mno-sum-in-toc
-mminimal-toc: 個々の実行ファイルに対して作成される TOC (Table Of Contents) の生成処理を変更します。デフォルトでは、 `-mfull-toc' オプションが選択されます。この場合 GNU CC は、プログラムの中の自動変数以外の一意な変数参照の１つ１つに対して、 TOC エントリを少なくとも１つ割り当てます。また GNU CC は、浮動小数点定数を TOC の中に置きます。しかし、 TOC の内部には 16,384 エントリしか存在しません。利用可能な TOC 領域を超えてしまったことを示すエラー・メッセージがリンカから出された場合は、 `-mno-fp-in-toc' オプションと `-mno-sum-in-toc' オプションによって、使用される TOC 領域の量を減らすことができます。 `-mno-fp-in-toc' は、 GNU CC が浮動小数点定数を TOC の中に入れることがないようにします。また、 `-mno-sum-in-toc' は、アドレス値と定数値の加算結果を TOC の中に入れるのではなく、そのような計算を実行時に行うコードを生成するよう GNU CC に強制します。この２つのオプションは、どちらか一方だけを指定することも可能ですし、両方とも指定することも可能です。どちらのオプションも、 TOC 領域を節約する代わりに非常に僅かながら実行速度が遅くサイズも大きいコードを GNU CC に生成させることになります。これらのオプションを両方とも指定した場合でも TOC 内の領域が不足するのであれば、これらのオプションの代わりに `-mminimal-toc' を指定してください。このオプションを指定すると GNU CC は、個々のファイルに対してただ１つの TOC エントリを作成するようになります。この場合に GNU CC が生成するコードは、実行速度が遅くサイズも大きいものになりますが、使用する TOC 領域は極めて小さいものになります。このオプションは、実行される頻度が比較的少ないコードを含むファイルに対して使うのが良いでしょう。
-mxl-call
-mno-xl-call: AIX 上において、プロトタイプを持つ関数への浮動小数点引数のうちレジスタ待避域（RSA）に収まらないものを、引数 FPR だけでなくスタック上に置いて渡します。引数群へのアドレスを受け取る関数を、宣言されているよりも少ない個数の引数を指定して呼び出した場合の結果は、 K&R C では不明確です。このようなケースを処理するために、 AIX の呼び出し規約は拡張されましたが、当初はドキュメント化されていませんでした。 AIX の XL コンパイラは、最適化を行わずにサブルーチンをコンパイルする際には、 RSA に収まらない浮動小数点引数はスタック上にあるものと想定します。常に浮動小数点引数をスタック上に置くのは非効率でもあり、かつ、稀にしか必要ではないため、このオプションはデフォルトでは有効になっていません。このオプションは、 AIX の XL コンパイラを使って最適化を行わずにコンパイルされたサブルーチンを呼び出す場合にのみ必要になります。
-mthreads: AIX Threads をサポートします。 pthreads を使うように書かれたアプリケーションは、そのアプリケーションを実行できるようにするための特殊なライブラリ、および、スタートアップ・コードとリンクされます。
-mpe: IBM RS/6000 SP Parallel Environment (PE) をサポートします。メッセージ・パッシングを使うよう書かれたアプリケーションは、そのアプリケーションを実行できるようにするための特殊なスタートアップ・コードとリンクされます。そのシステム上の標準的な場所（`/usr/lpp/ppe.poe/'）に PE がインストールされていなければなりません。標準的な場所にインストールされていない場合は、適切なディレクトリを指定するために、 `specs' ファイルの設定が `-specs=' オプションにより無効にされていなければなりません。 Parallel Environment はスレッドをサポートしていません。したがって、 `-mpe' オプションと `-mthreads' オプションは両立しません。
-msoft-float
-mhard-float: 浮動小数点レジスタ・セットを使わない（あるいは、使う）コードを生成します。 `-msoft-float' オプションを使うと、ソフトウェアによる浮動小数点エミュレーションが提供されます。このオプションは、リンクを行う際に GNU CC に渡します。
-mmultiple
-mno-multiple: 複数ワードのロード命令と複数ワードのストア命令を使う（あるいは、使わない）コードを生成します。これらの命令は、 POWER システム上ではデフォルトで生成され、 PowerPC システム上では生成されません。これらの命令は、プロセッサがリトル・エンディアン・モードにある時には機能しないので、リトル・エンディアンの PowerPC システム上では `-mmultiple' を使わないでください。
-mstring
-mno-string: 複数のレジスタの内容を待避したり小さいブロックの移動を行ったりするために文字列のロード命令と文字列のストア命令を使う（あるいは、使わない）コードを生成します。これらの命令は、 POWER システム上ではデフォルトで生成され、 PowerPC システム上では生成されません。これらの命令は、プロセッサがリトル・エンディアン・モードにある時には機能しないので、リトル・エンディアンの PowerPC システム上では `-mstring' を使わないでください。
-mupdate
-mno-update: 計算されたメモリ位置のアドレスへのベース・レジスタを更新するロード命令、ストア命令を使う（あるいは、使わない）コードを生成します。これらの命令はデフォルトで生成されます。 `-mno-update' を使うと、スタック・ポインタの更新と１つ前のフレームのアドレスの格納（ストア）の間に僅かな時間的なずれが発生します。このことは、割り込みやシグナルの発生の前後にまたがってスタック・フレームを移動するコードが、正しくないデータを獲得する可能性があるということを意味しています。
-mfused-madd
-mno-fused-madd: 浮動小数点の乗算命令と蓄積（accumulate）命令を使う（あるいは、使わない）コードを生成します。ハードウェアによる浮動小数点サポートが使用される場合には、これらの命令はデフォルトで生成されます。
-mno-bit-align
-mbit-align: System V.4 と組み込み PowerPC システムにおいて、ビット・フィールドを含む構造体と共用体が、そのビット・フィールドの基本型にあわせて境界整列されるよう強制しません（あるいは、強制します）。例えば、長さが 1 で unsigned 型のビット・フィールドを 8 個持ち、それ以外にはメンバを持たない構造体は、デフォルトでは、 4 バイト境界に境界整列され、サイズは 4 バイトになります。 `-mno-bit-align' を使うと、この構造体は 1 バイト境界に境界整列され、サイズは１バイトになります。
-mno-strict-align
-mstrict-align: System V.4 と組み込み PowerPC システムにおいて、境界整列されていないメモリ参照はシステムによって対処されると想定しません（あるいは、想定します）。
-mrelocatable
-mno-relocatable: 組み込み PowerPC システムにおいて、実行時に異なるアドレスにプログラムが再配置されることを許す（あるいは、許さない）コードを生成します。あるモジュールに対して `-mrelocatable' を使うのであれば、そのモジュールと一緒にリンクされるすべてのオブジェクトは、 `-mrelocatable' もしくは `-mrelocatable-lib' を指定してコンパイルされなければなりません。
-mrelocatable-lib
-mno-relocatable-lib: 組み込み PowerPC システムにおいて、実行時に異なるアドレスにプログラムが再配置されることを許す（あるいは、許さない）コードを生成します。 `-mrelocatable-lib' を指定してコンパイルされたモジュールは、 `-mrelocatable' や `-mrelocatable-lib' を指定せずにコンパイルされたモジュールか `-mrelocatable' オプションを指定してコンパイルされたモジュールのいずれかとリンクすることができます。
-mno-toc
-mtoc: System V.4 と組み込み PowerPC システムにおいて、レジスタ 2 が、プログラム中で使われるアドレス群を指すある広域領域へのポインタを保持していると想定しません（あるいは、想定します）。
-mno-traceback
-mtraceback: 組み込み PowerPC システムにおいて、関数の先頭の前にトレースバック用のタグを生成しません（あるいは、生成します）。デバッガは、関数の先頭がどこであるかを識別するためにこのタグを使うことができます。
-mlittle
-mlittle-endian: System V.4 と組み込み PowerPC システムにおいて、リトル・エンディアン・モードのプロセッサ用にコードをコンパイルします。 `-mlittle-endian' オプションは `-mlittle' と同一です。
-mbig
-mbig-endian: System V.4 と組み込み PowerPC システムにおいて、ビッグ・エンディアン・モードのプロセッサ用にコードをコンパイルします。 `-mbig-endian' オプションは `-mbig' と同一です。
-mcall-sysv: System V.4 と組み込み PowerPC システムにおいて、 1995 年３月付の「System V Application Binary Interface, PowerPC processor supplement」ドラフトに従う呼び出し規約を使ってコードをコンパイルします。 `powerpc-*-eabiaix' を指定して GCC のコンフィギュレーションを行ったのでない限り、これがデフォルトです。
-mcall-sysv-eabi: `-mcall-sysv' オプションと `-meabi' オプションを両方とも指定します。
-mcall-sysv-noeabi: `-mcall-sysv' オプションと `-mno-eabi' オプションを両方とも指定します。
-mcall-aix: System V.4 と組み込み PowerPC システムにおいて、 AIX において使われているものと類似の呼び出し規約を使ってコードをコンパイルします。 `powerpc-*-eabiaix' を指定して GCC のコンフィギュレーションを行った場合、これがデフォルトです。
-mcall-solaris: System V.4 と組み込み PowerPC システムにおいて、 Solaris オペレーティング・システム用にコードをコンパイルします。
-mcall-linux: System V.4 と組み込み PowerPC システムにおいて、 Linux ベースの GNU システム用にコードをコンパイルします。
-mprototype
-mno-prototype: System V.4 と組み込み PowerPC システムにおいて、可変引数を取る関数に対するすべての呼び出し箇所において、それらの関数に対して適切なプロトタイプが宣言されているものと想定します。このような想定を行わないと、コンパイラは、関数が可変引数を取る場合に備えて、プロトタイプ宣言されていないすべての関数呼び出しの前に、浮動小数点値が浮動小数点レジスタに入れて渡されたかどうかを示すために、条件コード・レジスタ（CR）のビット 6 をセット、もしくは、クリアする命令を挿入しなければなりません。 `-mprototype' を指定すると、可変引数を取る関数でプロトタイプ宣言されているものに対する呼び出しについてのみ、このビットがセット、もしくは、クリアされます。
-msim: 組み込み PowerPC システムにおいて、スタートアップ・モジュールの名前は `sim-crt0.o' であり、標準 C ライブラリは `libsim.a' と `libc.a' であると想定します。 `powerpc-*-eabisim' コンフィギュレーションにおいてはこれがデフォルトです。
-mmvme: 組み込み PowerPC システムにおいて、スタートアップ・モジュールの名前は `crt0.o' であり、標準 C ライブラリは `libmvme.a' と `libc.a' であると想定します。
-mads: 組み込み PowerPC システムにおいて、スタートアップ・モジュールの名前は `crt0.o' であり、標準 C ライブラリは `libads.a' と `libc.a' であると想定します。
-myellowknife: 組み込み PowerPC システムにおいて、スタートアップ・モジュールの名前は `crt0.o' であり、標準 C ライブラリは `libyk.a' と `libc.a' であると想定します。
-memb: 組み込み PowerPC システムにおいて、 `eabi' 拡張再配置機能が使われていることを示すために、 ELF フラグ・ヘッダの中の PPC_EMB ビットをセットします。
-meabi
-mno-eabi: System V.4 と組み込み PowerPC システムにおいて、 System V.4 仕様に対する修正事項を集めたものである「Embedded Applications Binary Interface (eabi)」に従います（あるいは、従いません）。 -meabi を選択することは、スタックが 8 バイト境界に境界整列されること、 eabi 環境をセットアップするために main から関数 __eabi が呼び出されること、および、 `-msdata' オプションを指定した場合に、２つの別個のスモール・データ域を指すために r2 と r13 の両方を使うことができるということを意味しています。 -mno-eabi を選択することは、スタックが 16 バイト境界に境界整列されること、 main から初期化関数が呼び出されないこと、および、 `-msdata' オプションを指定した場合に、単一のスモール・データ域を指すために r13 のみが使われるということを意味しています。 `powerpc*-*-eabi*' というパターンのオプションの１つを使って GCC のコンフィギュレーションを行った場合には、 `-meabi' オプションがデフォルトで有効となります。
-msdata=eabi: System V.4 と組み込み PowerPC システムにおいて、 const 指定された広域データと静的データのうちサイズが小さく初期化されているものを `.sdata2' セクションに置きます。このセクションは、レジスタ r2 によって指されます。また、 const 指定されていない広域データと静的データのうちサイズが小さく初期化されているものは `.sdata' セクションに置きます。このセクションは、レジスタ r13 によって指されます。広域データと静的データのうちサイズが小さく初期化されていないのものは `.sbss' セクションに置きます。このセクションは、 `.sdata' セクションに隣接しています。 `-msdata=eabi' オプションは `-mrelocatable' オプションとは両立しません。 `-msdata=eabi' オプションは `-memb' オプションもセットします。
-msdata=sysv: System V.4 と組み込み PowerPC システムにおいて、広域データと静的データのうちサイズの小さいものを `.sdata' セクションに置きます。このセクションは、レジスタ r13 によって指されます。広域データと静的データのうちサイズが小さく初期化されていないのものは `.sbss' セクションに置きます。このセクションは、 `.sdata' セクションに隣接しています。 `-msdata=sysv' オプションは `-mrelocatable' オプションとは両立しません。
-msdata=default
-msdata: System V.4 と組み込み PowerPC システムにおいて、 `-meabi' オプションが使われていれば `-msdata=eabi' と同様にコードをコンパイルします。 `-meabi' オプションが使われていなければ `-msdata=sysv' と同様にコードをコンパイルします。
-msdata-data: System V.4 と組み込み PowerPC システムにおいて、広域データと静的データのうちサイズの小さいものを `.sdata' セクションに置きます。広域データと静的データのうちサイズが小さく初期化されていないものは `.sbss' セクションに置きます。しかし、スモール・データのアドレスを示すのにレジスタ r13 を使いません。他の `-msdata' オプションが使われていない場合、これがデフォルトの振る舞いです。
-msdata=none
-mno-sdata: 組み込み PowerPC システムにおいて、広域データと静的データのうち初期化されているものはすべて `.data' セクションに置き、初期化されていないのものはすべて `.bss' セクションに置きます。
-G num: 組み込み PowerPC システムにおいて、広域データと静的データのうちサイズが num 以下のものを、通常の data セクションや bss セクションにではなく、 small data セクションや small bss セクションに置きます。デフォルトでは、 num は 8 です。 `-G num' オプションはリンカにも渡されます。 `-G num' に同一の値を指定してすべてのモジュールをコンパイルするべきです。
-mregnames
-mno-regnames: System V.4 と組み込み PowerPC システムにおいて、アセンブリ言語の出力の中でシンボリック形式を使ってレジスタ名を出力します（あるいは、出力しません）。

IBM RT オプション

以下の `-m' オプションが IBM RT PC に対して定義されています。

-min-line-mul: 整数の乗算に対して、インライン化されたコード・シーケンスを使います。これがデフォルトです。
-mcall-lib-mul: 整数の乗算に対して、 lmul$$ を呼び出します。
-mfull-fp-blocks: IBM により推奨される最小限度のスクラッチ領域を含むフル・サイズの浮動小数点データ・ブロックを生成します。これがデフォルトです。
-mminimum-fp-blocks: 浮動小数点データ・ブロックの中に余分のスクラッチ領域を含めません。この結果、スクラッチ領域は動的に割り当てられなければならなくなるため、コードのサイズは小さくなりますが、その実行速度は遅くなります。
-mfp-arg-in-fpregs: 浮動小数点引数は浮動小数点レジスタに入れて渡す IBM の呼び出し規約とは互換性のない呼び出し規約を使います。このオプションが指定されると、 varargs.h と stdargs.h の中に定義されている関数等は、浮動小数点オペランドとの組み合わせでは機能しなくなりますので注意してください。
-mfp-arg-in-gregs: 浮動小数点引数について通常の呼び出し規約を使います。これがデフォルトです。
-mhc-struct-return: サイズが１ワードを超える構造体は、レジスタにではなくメモリ上に置いて返します。これにより、 MetaWare HighC (hc) コンパイラとの互換性がもたらされます。 Portable C Compiler (pcc) との互換性のためには `-fpcc-struct-return' を使ってください。
-mnohc-struct-return: サイズが１ワードを超える構造体であっても、その方が都合が良い場合にはレジスタに入れて返します。これがデフォルトです。 IBM により提供されるコンパイラとの互換性のためには、オプション `-fpcc-struct-return' かオプション `-mhc-struct-return' を使ってください。

MIPS オプション

以下の `-m' オプションが MIPS ファミリのコンピュータに対して定義されています。

-mcpu=cpu type: 命令をスケジュールする際には、マシン・タイプ cpu type のデフォルトの設定を想定します。 cpu type に対する選択肢には、 `r2000'、 `r3000'、 `r4000'、 `r4400'、 `r4600'、 `r6000' があります。特定の cpu type を選択すると、その特定のチップにとって適切なスケジューリングを行うようになりますが、 `-mips2' オプションか `-mips3' オプションが使われていない限り、コンパイラが MIPS ISA (instruction set architecture の略)のレベル 1 に適合しないコードを生成することはありません。
-mips1: MIPS ISA のレベル 1 の命令を出力します。これがデフォルトです。この ISA レベルでは `r3000' がデフォルトの cpu type です。
-mips2: MIPS ISA のレベル 2 の命令（平方根命令とおそらくは分岐命令）を出力します。この ISA レベルでは `r6000' がデフォルトの cpu type です。
-mips3: MIPS ISA のレベル 3 の命令（64 ビット命令）を出力します。この ISA レベルでは `r4000' がデフォルトの cpu type です。このオプションを使用しても、 C のデータ型のサイズは一切変更されません。
-mfp32: 32 個ある 32 ビット浮動小数点レジスタが利用可能であると想定します。これがデフォルトです。
-mfp64: 32 個ある 64 ビット浮動小数点レジスタが利用可能であると想定します。 `-mips3' オプションが使われている場合は、これがデフォルトです。
-mgp32: 32 個ある 32 ビット汎用レジスタが利用可能であると想定します。これがデフォルトです。
-mgp64: 32 個ある 64 ビット汎用レジスタが利用可能であると想定します。 `-mips3' オプションが使われている場合は、これがデフォルトです。
-mint64: long 型、 int 型、および、ポインタ型は 64 ビットになります。これは `-mips3' があわせて指定されている場合のみ機能します。
-mlong64: long 型とポインタ型は 64 ビットになり、 int 型は 32 ビットになります。これは `-mips3' があわせて指定されている場合のみ機能します。
-mmips-as: MIPS アセンブラ用のコードを生成し、通常のデバッグ情報を付加するために `mips-tfile' を起動します。これは、 OSF/rose オブジェクト形式を使用する OSF/1 リファレンス・プラットフォームを除くすべてのプラットフォームに対するデフォルトです。 `-gstabs' オプションと `-gstabs+' オプションのいずれかが使われると、 `mips-tfile' プログラムは、 MIPS ECOFF の内部にスタブを包含させます。
-mgas: GNU アセンブラ用のコードを生成します。これは、 OSF/rose オブジェクト形式を使用する OSF/1 リファレンス・プラットフォーム上でのデフォルトです。これはまた、 configure のオプション `--with-gnu-as' が使われた場合のデフォルトでもあります。
-msplit-addresses
-mno-split-addresses: アドレス定数の上位部と下位部を別々にロードするコードを生成します。これにより gcc は、最適化の過程において、アドレスの上位ビット群のロード回数を減らすことができます。この最適化を行うためには、 GNU as と GNU ld が必要になります。 GNU as と GNU ld が標準となっているいくつかの組み込みターゲットでは、この最適化はデフォルトで有効になっています。
-mrnames
-mno-rnames: `-mrnames' オプションは、レジスタの名前としてハードウェア名の代わりに MIPS ソフトウェア名（すなわち、 $4 の代わりに a0）を使ったコードを出力するよう指示するものです既知のアセンブラでこのオプションをサポートする唯一のものは Algorithmics アセンブラです。
-mgpopt
-mno-gpopt: `-mgpopt' オプションは、 text セクションの中において命令群が置かれている箇所の前に、すべてのデータ宣言を出力するよう指示するものです。これにより MIPS assembler は、サイズの小さい広域データ要素、静的データ要素に対して、２ワードを使ったメモリ参照ではなく１ワードを使ったメモリ参照を生成することができるようになります。最適化を行うよう選択されている場合には、このオプションはデフォルトで設定されています。
-mstats
-mno-stats: `-mstats' オプションが指定されると、コンパイラは、処理される個々の非インライン関数について、そのプログラムの統計情報（待避されたレジスタの数、スタック・サイズ等）を１行にして標準エラー・ファイルに出力します。
-mmemcpy
-mno-memcpy: `-mmemcpy' オプションを指定すると、すべてのブロック移動について、適切な文字列関数（`memcpy' や `bcopy'）を呼び出すようになります。このオプションが指定されないと、おそらくインライン・コードが生成されます。
-mmips-tfile
-mno-mips-tfile: `-mno-mips-tfile' オプションを指定すると、コンパイラは、 MIPS アセンブラがオブジェクト・ファイルを生成した後に、デバッグ・サポートを追加するための `mips-tfile' プログラムを使ったオブジェクト・ファイルの後処理を行わなくなります。 `mips-tfile' が実行されないと、局所変数はデバッガからは一切認識できなくなります。さらに、 `stage2' と `stage3' で生成されるオブジェクト・ファイルには、アセンブラに渡された一時ファイル名が組み込まれます。このことは、これらのオブジェクトを比較すると一致しないということを意味しています。 `-mno-mips-tfile' オプションは、コンパイルができなくなるようなバグが `mips-tfile' プログラムにある場合に限って使うべきものです。
-msoft-float: 浮動小数点を処理するためのライブラリ呼び出しを含む出力を生成します。 注意: 必要となるライブラリは GNU CC には付属していません。通常、そのマシンにおいて通常使われる C コンパイラのライブラリが利用されますが、これはクロス・コンパイル環境では直接使うことができません。クロス・コンパイルを行う場合は、適切なライブラリ関数群を提供するための準備を自分で行わなければなりません。
-mhard-float: 浮動小数点命令を含む出力を生成します。これは、ソースを変更せずそのまま使う場合のデフォルトです。
-mabicalls
-mno-abicalls: System V.4 を移植した環境のいくつかにおいて位置非依存コード用に使われる仮想オペレーション `.abicalls'、 `.cpload'、 `.cprestore' を出力します（あるいは、出力しません）。
-mlong-calls
-mno-long-calls: すべての関数呼び出しを `JALR' 命令を使って実行します。この命令は、呼び出しの前に関数アドレスがレジスタに格納されていることを要求します。 512 メガバイトのカレント・セグメントの外部にある関数をポインタ経由以外の方法で呼び出す場合には、このオプションを使う必要があります。
-mhalf-pic
-mno-half-pic: 外部参照を text セクションに置くのではなく、外部参照へのポインタを data セクションに置いてロードします。
-membedded-pic
-mno-embedded-pic: いくつかの組み込みシステムにおいて適切な PIC コードを生成します。すべての関数呼び出しは PC 相対アドレスを使って実行され、すべてのデータは＄gp レジスタを使ってアドレス付けされます。このオプションは、実際の仕事のほとんどを行う GNU as と GNU ld を必要とします。
-membedded-data
-mno-embedded-data: もし可能であれば、変数を最初に読み込みのみ可能な data セクションに割り当てます。それが不可であり、 small data セクションへの割り当てが可能であれば、変数を small data セクションへ割り当てます。それも不可であれば、 data セクションへ割り当てます。これによりデフォルトよりも若干速度の遅いコードが生成されますが、実行時に必要となる RAM の量が少なくなるため、いくつかの組み込みシステムではこちらの方が好ましいとみなされるかもしれません。
-msingle-float
-mdouble-float: `-msingle-float' オプションは、 `r4650' チップ上の浮動小数点コプロセッサのように、浮動小数点コプロセッサが単精度演算しかサポートしていないと想定するよう gcc に指示します `-mdouble-float' オプションは、 gcc が倍精度演算を使うことを許します。こちらがデフォルトです。
-mmad
-mno-mad: `r4650' チップのように、 `mad'、 `madu'、 `mul' 命令の使用を許します。
-m4650: `-msingle-float' と `-mmad' を有効にします。また、少なくとも現在のところは、 `-mcpu=r4650' も有効にします。
-EL: リトル・エンディアン・モードのプロセッサ用にコードをコンパイルします。必要となるライブラリは存在するものと想定されます。
-EB: ビッグ・エンディアン・モードのプロセッサ用にコードをコンパイルします。必要となるライブラリは存在するものと想定されます。
-G num: num バイト以下の広域データ項目と静的データ項目を、通常の data セクション、 bss セクションではなく、 small data セクション、 small bss セクションに置きます。これによりアセンブラは、通常の２ワードを使ったメモリ参照命令ではなく、広域ポインタ（gp あるいは $28）をベースにした１ワードのメモリ参照命令を生成することができるようになります。デフォルトの num の値は、 MIPS アセンブラが使われている場合には 8 であり、 GNU アセンブラが使われている場合には 0 です。 `-G num' オプションは、アセンブラとリンカにも渡されます。同一の `-G num' の値を指定してすべてのモジュールをコンパイルするべきです。
-nocpp: （`.s' という接尾語を持つ）ユーザ・アセンブラ・ファイルをアセンブルする際には、アセンブラ・ファイルに対してプリプロセッサを実行しないよう MIPS アセンブラに指示します。

これらのオプションは、マシン記述の中のマクロ TARGET_SWITCHES によって定義されています。これらのオプションのデフォルトもまたこのマクロにより定義されているため、デフォルトを変更することも可能です。

Intel 386 オプション

以下の `-m' オプションが i386 ファミリのコンピュータに対して定義されています。

-mcpu=cpu type: 命令をスケジュールする際に、マシン・タイプ cpu type のデフォルト設定を想定します。 cpu type に対する選択肢には、 `i386'、 `i486'、 `i586' (`pentium')、 `pentium'、 `i686' (`pentiumpro')、 `pentiumpro' があります。特定の cpu type を選択すると、その特定のチップに対して適切な方法でスケジューリングが行われるようになります。その一方で、 `-march=cpu type' オプションが使われていなければ、コンパイラは、 i386 上では動作しないコードを生成することはありません。
-march=cpu type: マシン・タイプ cpu type 用の命令を生成します。 cpu type に対する選択肢には、 `i386'、 `i486'、 `pentium'、 `pentiumpro' があります。 `-march=cpu type' を指定すると、暗黙のうちに `-mcpu=cpu type' も指定されます。
-m386
-m486
-mpentium
-mpentiumpro: それぞれ -mcpu=i386、 -mcpu=i486、 -mcpu=pentium、 -mcpu=pentiumpro と同義です。
-mieee-fp
-mno-ieee-fp: IEEE により規定された浮動小数点比較演算をコンパイラが使うか否かを制御します。これらの比較演算は、比較の結果が順序付けされていないようなケースを正しく処理します。
-msoft-float: 浮動小数点を処理するためのライブラリ呼び出しを含む出力を生成します。 注意: 必要となるライブラリは GNU CC には付属していません。通常、そのマシンにおいて通常使われる C コンパイラのライブラリが利用されますが、これはクロス・コンパイル環境では直接使うことができません。クロス・コンパイルを行う場合は、適切なライブラリ関数群を提供するための準備を自分で行わなければなりません。関数が浮動小数点の戻り値を 80387 レジスタ・スタックに入れて返すようなマシン上では、 `-msoft-float' が使われていても、いくつかの浮動小数点 opcode が出力されるかもしれません。
-mno-fp-ret-in-387: 関数の戻り値を格納するのに FPU レジスタを使いません。通常の呼び出し規約では、たとえ FPU が存在しなくても、関数の戻り値のうち float 型と double 型のものは FPU レジスタに入れられます。オペレーティング・システムが FPU をエミュレートしているはずであると考えてそうしてあります。オプション `-mno-fp-ret-in-387' を指定すると、このような値は通常の CPU レジスタに入れて返されます。
-mno-fancy-math-387: 387 エミュレータの中には、 387 の sin、 cos、 sqrt 命令をサポートしていないものがあります。これらの命令の生成を回避するには、このオプションを指定します。 FreeBSD ではこのオプションがデフォルトです。バージョン 2.6.1 では、 `-ffast-math' オプションを指定しないと、これらの命令は生成されません。
-malign-double
-mno-align-double: GNU CC が double、 long double、 long long 型の変数を２ワード境界に境界整列するか１ワード境界に境界整列するかを制御します。 double 型の変数を２ワード境界に境界整列すると、消費されるメモリは多くなりますが、 `Pentium' 上においていくらかより高速に実行されるコードが生成されます。 注意: `-malign-double' オプションを使うと、上記の型を含む構造体については、出版されている 386 のアプリケーション・バイナリ・インターフェイス仕様とは異なる境界整列が行われます。
-msvr3-shlib
-mno-svr3-shlib: 初期化されない局所変数を GNU CC が bss セクションと data セクションのどちらに置くかを制御します。 `-msvr3-shlib' は、初期化されない局所変数を bss セクションに置きます。これらのオプションは、 System V Release 3 においてのみ意味があります。
-mno-wide-multiply
-mwide-multiply: long long 型の乗算や定数による 32 ビット除算を実行するのに、 32 ビットのオペランドから 64 ビットの結果を生成して eax:edx に格納する mul や imul を GNU CC が使うかどうかを制御します。
-mrtd: 異なる関数呼び出し規約を使います。この関数呼び出し規約では、引数の数が固定である関数は、復帰の際に引数をポップする ret num 命令を使って呼び出し元に復帰します。これにより呼び出し元では、引数をポップする必要がなくなるので、命令を１つ節約することができます。関数属性 `stdcall' を使うことによって、個々の関数ごとに、この呼び出しシーケンスを使って呼び出すことを指定することができます。また、関数属性 `cdecl' を使うことによって、 `-mrtd' オプションを無効にすることもできます。 See section 関数属性の宣言。 注意: この呼び出し規約は、通常 Unix 上において使われる呼び出し規約とは互換性がありません。したがって、 Unix のコンパイラによりコンパイルされたライブラリを呼び出す必要がある場合には、これを使うことはできません。また、（printf も含めて）可変個数の引数を取るすべての関数について関数プロトタイプを提供しなければなりません。さもないと、これらの関数が呼び出されているところで、正しくないコードが生成されることになります。さらに、関数の呼び出しに際して引数の数が多すぎると、深刻な問題を持つコードが生成されてしまいます（通常は、余分な引数は実害なく無視されます）。
-mreg-alloc=regs: 整数レジスタのデフォルトの割り当て順序を制御します。文字列 regs は、レジスタを指定する一連の文字です。サポートされている文字を列挙すると以下のようになります。 a は EAX を割り当てます。 b は EBX を割り当てます。 c は ECX を割り当てます。 d は EDX を割り当てます。 S は ESI を割り当てます。 D は EDI を割り当てます。 B は EBP を割り当てます。
-mregparm=num: 整数引数を渡すのにレジスタを何個使うかを制御します。デフォルトでは引数を渡すのにレジスタは使われません。最大では３個のレジスタまでを使うことができます。関数属性 `regparm' を使うことによって、特定の関数におけるこの振る舞いを制御することができます。 See section 関数属性の宣言。 注意: このオプションを num にゼロ以外の値を指定して使う場合には、ライブラリも含めたすべてのモジュールを同一の値を指定して構築しなければなりません。これには、システム・ライブラリやスタートアップ・モジュールも含まれます。
-malign-loops=num: 2 を num 乗したバイト数単位にループを境界整列します。 `-malign-loops' が指定されないと、デフォルトの num の値は 2 となります。
-malign-jumps=num: ジャンプ命令によってのみ到達される命令を、 2 を num 乗したバイト数単位に境界整列します。 `-malign-jumps' が指定されない場合のデフォルトの num の値は、 386 用に最適化している場合には 2、 486 用に最適化している場合には 4 となります。
-malign-functions=num: 関数の先頭を、 2 を num 乗したバイト数単位に境界整列します。 `-malign-functions' が指定されない場合のデフォルトの num の値は、 386 用に最適化している場合には 2、 486 用に最適化している場合には 4 となります。

HPPA オプション

以下の `-m' オプションが HPPA ファミリのコンピュータに対して定義されています。

-mpa-risc-1-0: PA 1.0 プロセッサ用のコードを生成します。
-mpa-risc-1-1: PA 1.1 プロセッサ用のコードを生成します。
-mbig-switch: サイズの大きいスイッチ・テーブル（switch table）に適するコードを生成します。アセンブラやリンカが、スイッチ・テーブルの中にある分岐可能範囲外への分岐命令に関して文句を言ってくるばあいにのみ、このオプションを使ってください。
-mjump-in-delay: 関数呼び出しの復帰ポインタを条件付きジャンプのジャンプ先に変更することによって、関数呼び出しの遅延スロット（delay slot）には無条件ジャンプ命令を埋め込みます。
-mdisable-fpregs: 浮動小数点レジスタがいかなる方法でも使われないようにします。これは、浮動小数点レジスタのレイジー・コンテキスト切り替え（lazy context switching）を行うカーネルをコンパイルする際に必要になります。このオプションを使い、かつ、浮動小数点演算を実行しようとすると、コンパイラがアボートします。
-mdisable-indexing: コンパイラがインデクシング・アドレス・モード（indexing address mode）を使うことがないようにします。これにより、 MACH 配下において MIG を使って生成されたコードをコンパイルする際に発生する、どちらかと言えばあいまいな問題を回避することができます。
-mno-space-regs: ターゲット・マシンにはスペース・レジスタ（space register）がないものと想定したコードを生成します。これにより GCC は、より高速な間接呼び出しを生成することができ、また、アンスケールド・インデックス・アドレス・モード（unscaled index address mode）を使うことができます。このようなコードは、レベル 0 の PA システムおよびカーネルに適しています。
-mfast-indirect-calls: 領域境界（space boundary）をまたがる呼び出しはないものと想定したコードを生成します。これにより GCC は、より高速な間接呼び出しを行うコードを生成することができます。このオプションは、共用ライブラリや入れ子関数がある場合には機能しません。
-mspace: 実行速度よりもむしろ領域の最適化を行います。現在のところ、これは関数の外部に存在する（out of line）関数プロローグと関数エピローグを利用できるようにするだけです。このオプションは、 PIC コードの生成処理やプロファイル処理とは両立しません。
-mlong-load-store: HP-UX 10 のリンカにより時々必要とされる、 3 命令によるロード・シーケンスやストア・シーケンスを生成します。これは、 HP コンパイラの `+k' オプションと同等です。
-mportable-runtime: HP 社により ELF システムを対象として提案されている、移植性のある呼び出し規約を使います。
-mgas: GAS だけが理解するアセンブラ指示子を使えるようにします。
-mschedule=cpu type: マシン・タイプ cpu type の制約に従ってコードをスケジュールします。 cpu type の選択肢としては、 7n0 マシンを示す `700'、 7n5 マシンを示す `7100'、 7n2 マシンを示す `7100' があります。 `7100' が cpu type のデフォルトです。 `7100LC' のスケジュール処理情報は不完全であり、 `7100LC' を使うとしばしば不正なスケジュールが行われることに注意してください。現在のところ、 7n2 マシンについては、 `7100LC' の代わりに `7100' を使うのがおそらく一番良いでしょう。
-mlinker-opt: HPUX リンカの最適化処理のパスを使用できるようにします。これによりシンボリック・デバッグは不可能になることに注意してください。 HPUX 8 や HPUX 9 のリンカには、ある種のプログラムをリンクする際に偽のエラー・メッセージを出力するというバグがありますが、このオプションを使うとこうしたバグを表面化させるきっかけにもなります。
-msoft-float: 浮動小数点を処理するためのライブラリ呼び出しを含む出力を生成します。 注意: 必要となるライブラリは、すべての HPPA ターゲットにおいて利用可能なわけではありません。通常、そのマシンにおいて通常使われる C コンパイラのライブラリが利用されますが、これはクロス・コンパイル環境では直接使うことができません。クロス・コンパイルを行う場合は、適切なライブラリ関数群を提供するための準備を自分で行わなければなりません。組み込みターゲットである `hppa1.1-*-pro' では、ソフトウェアによる浮動小数点サポートが提供されます。 `-msoft-float' は、出力ファイルの中における呼び出し規約を変更するので、このオプションを使ってプログラム全体をコンパイルする場合にしか役に立ちません。このオプションが機能するようにするためには、特に、 GNU CC に付属しているライブラリである `libgcc.a' を `-msoft-float' を指定してコンパイルする必要があります。

Intel 960 オプション

以下の `-m' オプションが、 Intel 960 の実装に対して定義されています。

-mcpu type: 命令スケジュール処理、浮動小数点サポート、アドレッシング・モードを含む他のいくつかのオプションに関して、マシン・タイプ cpu type のデフォルトの設定を想定します。 cpu type の選択肢には、 `ka'、 `kb'、 `mc'、 `ca'、 `cf'、 `sa'、 `sb' があります。デフォルトは `kb' です。
-mnumerics
-msoft-float: `-mnumerics' オプションは、プロセッサが浮動小数点命令をサポートすることを示します。 `-msoft-float' オプションは、浮動小数点サポートの存在が想定されてはならないことを示します。
-mleaf-procedures
-mno-leaf-procedures: call 命令だけでなく bal 命令によっても呼び出しができるようにリーフ・プロシージャ（leaf procedure）を変更することを試みます（あるいは、試みません）。これにより、アセンブラやリンカが bal 命令に置き換えることができるような場合には、明示的な呼び出しに対してより効率の良いコードが生成されることになります。その一方で、関数ポインタを使った呼び出しやこのような最適化をサポートしていないリンカを使っている場合には、より効率の悪いコードが生成されることになります。
-mtail-call
-mno-tail-call: （コンパイラのマシン非依存部による試みに加えて）末尾再帰的（tail-recursive）な呼び出しを最適化して、分岐命令に変更するための試みを行います（あるいは、行いません）。このような最適化が妥当でないような場合を完全に検出することはできないので、この最適化は行わないほうが良いかもしれません。デフォルトは `-mno-tail-call' です。
-mcomplex-addr
-mno-complex-addr: コンプレックス・アドレッシング・モード（complex addressing mode）を使うことは、この特定の i960 の実装の上では利点があるものと想定します（あるいは、想定しません）。コンプレックス・アドレッシング・モードは K シリーズ上では使う値打ちがないかもしれませんが、 C シリーズ上では明らかに使う値打ちがあります。現在のところデフォルトは、 CB と CC を除くすべてのプロセッサにおいて `-mcomplex-addr' です。
-mcode-align
-mno-code-align: 命令をより高速にフェッチ（獲得）できるように、コードを 8 バイト境界に境界整列します（あるいは、境界整列しません）。現在のところ、 C シリーズの実装においてのみデフォルトで境界整列するようになっています。
-mic-compat
-mic2.0-compat
-mic3.0-compat: iC960 v2.0 もしくは v3.0 との互換性をもたらします。
-masm-compat
-mintel-asm: iC960 アセンブラとの互換性をもたらします。
-mstrict-align
-mno-strict-align: 境界整列されていないアクセスを許しません（あるいは、許します）。
-mold-align: 構造体の境界整列について、（gcc 1.37 をベースとする） Intel 社の gcc リリースのバージョン 1.3 との互換性をもたらします。このオプションは、暗黙のうちに `-mstrict-align' を意味します。

DEC Alpha オプション

以下の `-m' オプションが DEC Alpha の実装に対して定義されています。

-mno-soft-float

-msoft-float

浮動小数点演算については、ハードウェアによる浮動小数点命令を使います（あるいは、使いません）。 -msoft-float が指定されると、 `libgcc1.c' の中の関数群が浮動小数点演算を実行するために使われることになります。これらの関数群が浮動小数点演算をエミュレートする別のルーチン群によって置き換えられるか、あるいは、そのようなエミュレーション・ルーチンを呼び出すような形でコンパイルされるのでない限り、これらの関数群によって浮動小数点演算は実行されます。浮動小数点演算を持たない Alpha 用にコンパイルを行っているのであれば、これらの関数群が呼び出されないようにライブラリが構築されていることを確実にしなければなりません。浮動小数点演算を持たない Alpha の実装においても、浮動小数点レジスタを持つことが要求されていることに注意してください。

-mfp-reg

-mno-fp-regs

浮動小数点レジスタ・セットを使う（あるいは、使わない）コードを生成します。 -mno-fp-regs は、暗黙のうちに -msoft-float を意味します。浮動小数点レジスタ・セットが使われないのであれば、浮動小数点オペランドは、それがあたかも整数であるかのように整数レジスタに入れて渡され、浮動小数点の結果は、 $f0 ではなく $0 に入れて渡されます。これは標準的ではない呼び出しシーケンスですので、 -mno-fp-regs を指定してコンパイルされたコードから呼び出される関数のうち、浮動小数点の引数や戻り値を持つものはすべて、同じ -mno-fp-regs を指定してコンパイルされなければなりません。このオプションの典型的な用途としては、浮動小数点レジスタを使わないため、浮動小数点レジスタの待避や復元を必要としないカーネルの構築があります。

-mieee

Alpha アーキテクチャは、最高の性能を引き出すよう最適化された浮動小数点ハードウェアを実装しています。それは IEEE の浮動小数点標準にほぼ準拠しています。しかし、完全に準拠するためには、ソフトウェアによる支援が必要です。このオプションは、 inexact flag が保存されない（後述）という点を除外すれば完全に IEEE 準拠のコードを生成します。このオプションが指定されると、コンパイル時に CPP のマクロ _IEEE_FP が定義されます。このオプションは、 `-D_IEEE_FP -mfp-trap-mode=su -mtrap-precision=i -mieee-conformant' の短縮形です。結果として生成されるコードは、若干非効率なものになりますが、正規化されていない数（denormalized number）、および、非数（not-a-number）、正の無限大、負の無限大などの例外的な IEEE 値を正しくサポートすることができます。他の Alpha 用コンパイラでは、このオプションは -ieee_with_no_inexact と呼ばれています。

-mieee-with-inexact

これは `-mieee' と似ていますが、生成されたコードが IEEE inexact flag も保存するという点が異なります。このオプションを使うと、生成されるコードは完全に IEEE の数学仕様（math）に準拠した実装になります。このオプションは、 `-D_IEEE_FP -D_IEEE_FP_INEXACT' に `-mieee-conformant'、 `-mfp-trap-mode=sui'、 `-mtrap-precision=i' の３つのオプションを加えたものの短縮系です。いくつかの Alpha の実装では、このオプションを指定した結果生成されるコードは、デフォルトの設定において生成されるコードと比較して、かなり実行速度が遅くなることがあるかもしれません。 inexact flag に依存するコードはほとんどありませんから、通常はこのオプションを指定するべきではありません。他の Alpha 用コンパイラでは、このオプションは `-ieee_with_inexact' と呼ばれています。

-mfp-trap-mode=trap mode

このオプションは、浮動小数点に関連するトラップのうちどれが有効であるかを制御します。他の Alpha コンパイラでは、このオプションは `-fptm 'trap mode と呼ばれています。トラップ・モードは、以下の４つの値のいずれかに設定することができます。

`n': これがデフォルト（通常）の設定です。有効なトラップは、ソフトウェアでは無効化できないものだけです（例えば、ゼロによる除算によるトラップ）。
`u': `n' において有効であるトラップに加えて、アンダフローによるトラップもまた有効化されます。
`su': `u' (8)と似ていますが、ソフトウェア完結（software completion）が行われても安全であるよう命令がマーク付けされます（詳細については、 Alpha アーキテクチャ・マニュアルを参照）。
`sui': `su' と似ていますが、精密でないトラップも有効化されます。

-mfp-rounding-mode=rounding mode

IEEE の丸めモード（rounding mode）を選択します。他の Alpha 用コンパイラでは、このオプションは `-fprm 'rounding mode と呼ばれています。 rounding mode には、以下のいずれかの値を指定できます。

`n': 通常の IEEE 丸めモードです。浮動小数点数は、マシン上で表現できる数のうち最も近い数に丸められます。最も近い数が２つある場合には、偶数のものに丸められます。
`m': 負の無限大の方向に丸めます。
`c': 切り捨ての丸めモードです。浮動小数点数はゼロの方向に丸められます。
`d': 動的な丸めモードです。浮動小数点制御レジスタの中の１つのフィールド（fpcr。詳細については、 Alpha アーキテクチャ・リファレンス・マニュアルを参照）が、実際に使われる丸めモードを制御します。 C ライブラリは、正の無限大の方向に丸めるようこのレジスタを初期化します。したがって、プログラムの中で fpcr を変更しない限り、 `d' は正の無限大の方向への丸めに対応します。

-mtrap-precision=trap precision

Alpha アーキテクチャでは、浮動小数点トラップは精密ではありません。このことは、ソフトウェアによる支援がない場合には、浮動小数点トラップが発生した後にトラップ発生前の状態を復元することは不可能であり、プログラムの実行は通常は停止される必要があるということを意味しています。浮動小数点トラップを発生させた箇所をオペレーティング・システムのトラップ・ハンドラが正確に突き止めるのを支援することのできるコードを、 GNU CC は生成することができます。アプリケーションの要件に応じて、異なるレベルの精度を選択することができます。

`p': プログラム・レベルの精度。このオプションがデフォルトです。これは、トラップ・ハンドラには浮動小数点例外を発生させたプログラムがどれであるかしか識別できないということを意味しています。
`f': 関数レベルの精度。トラップ・ハンドラは、浮動小数点例外を発生させた関数を識別できます。
`i': 命令レベルの精度。トラップ・ハンドラは、浮動小数点例外を発生させた命令を正確に識別できます。

他の Alpha 用コンパイラは、 `-scope_safe' と `-resumption_safe' と呼ばれる同等のオプションを提供しています。

-mieee-conformant

このオプションは、生成されたコードを IEEE 準拠としてマーク付けします。同時に `-mtrap-precision=i' と、 `-mfp-trap-mode=su' か `-mfp-trap-mode=sui' のいずれか一方をあわせて指定するのでなければ、このオプションを使ってはなりません。このオプションの持つ唯一の効果は、生成されるアセンブリ・ファイルの関数プロローグの中に `.eflag 48' という１行を出力することです。 DEC Unix では、これにより IEEE 準拠の数学ライブラリ・ルーチンがリンクされるという効果があります。

-mbuild-constants

通常 GNU CC は、 32 ビットや 64 ビットの整数定数があると、その定数を、より小さい定数から２、３個の命令を使って作成できないか調べます。作成できない場合 GNU CC は、その定数をリテラルとして出力し、実行時にデータ・セグメントからその定数をロードするコードを生成します。このオプションは、より多くの命令（最高で６命令まで）を必要とする場合であっても、 すべての整数定数をコードを使って作成するよう GNU CC に要求する場合に使います。このオプションが典型的に使われるのは、共用ライブラリの動的ローダの構築においてでしょう。それ自身が共用ライブラリであるために、動的ローダは、それ自身のデータ・セグメントの中に変数や定数を見つけられるようになる前に、それ自身をメモリ中において再配置しなければなりません。

-malpha-as

-mgas

ベンダ供給のアセンブラによりアセンブルするコードを生成する（`-malpha-as'）か、 GNU アセンブラによりアセンブルするコードを生成する（`-mgas'）かを選択します。

-mbwx

-mno-bwx

-mcix

-mno-cix

-mmax

-mno-max

GNU CC が、任意選択の BWX、 CIX、 MAX 命令セットを使ったコードを生成するべきか否かを示します。デフォルトでは、 `-mcpu=' オプションにより指定された CPU タイプによってサポートされる命令セットが使われます。 `-mcpu=' オプションが指定されていない場合には、 GNU CC がその上で構築されたマシンの CPU によりサポートされる命令セットが使われます。

-mcpu=cpu_type

マシン・タイプ cpu_type に対応した命令セット・パラメータ、レジスタ・セット・パラメータ、命令スケジューリング・パラメータを設定します。 `EV' スタイルの名前かそれに対応するチップ番号のいずれかを指定することができます。 GNU CC は、 EV4 と EV5 のプロセッサ・ファミリに対応するスケジューリング・パラメータをサポートし、指定されたプロセッサから命令セットのデフォルト値を選択します。プロセッサ・タイプを指定しないと、 GNU CC は、コンパイラがその上で構築されたマシンのプロセッサをデフォルトとします。 cpu_type としてサポートされる値は、以下のとおりです。

`ev4'
`21064': EV4 としてスケジュールを行い、拡張命令セットを持ちません。
`ev5'
`21164': EV5 としてスケジュールを行い、拡張命令セットを持ちません。
`ev56'
`21164a': EV5 としてスケジュールを行い、 BWX 拡張をサポートします。
`pca56'
`21164PC': EV5 としてスケジュールを行い、 BWX 拡張と MAX 拡張をサポートします。
`ev6'
`21264': （Digital 社が EV6 のスケジューリング・パラメータをリリースするまでの間は） EV5 としてスケジュールを行い、 BWX 拡張、 CIX 拡張、 MAX 拡張をサポートします。

Clipper オプション

以下の `-m' オプションが Clipper の実装に対して定義されています。

-mc300: C300 Clipper プロセッサ用のコードを生成します。これがデフォルトです。
-mc400: C400 Clipper プロセッサ用のコードを生成します。すなわち、浮動小数点レジスタ f8..f15 を使います。

H8/300 オプション

以下の `-m' オプションが H8/300 の実装に対して定義されています。

-mrelax: 可能であれば、リンク時にいくつかのアドレス参照を短くします。リンカ・オプション `-relax' を使います。より詳しい説明については、 See section `ld and the H8/300' in Using ld
-mh: H8/300H 用のコードを生成します。
-ms: H8/S 用のコードを生成します。
-mint32: int 型のデータをデフォルトで 32 ビットにします。
-malign-300: h8/300h 上で、 h8/300 と同一の境界整列規則を使います。 h8/300h のデフォルトでは、 long 型と float 型は 4 バイト境界に境界整列されます。 `-malign-300' を指定すると、これらは 2 バイト境界に境界整列されます。このオプションは、 h8/300 上では何の効果もありません。

SH オプション

以下の `-m' オプションが SH の実装に対して定義されています。

-m1: SH1 用のコードを生成します。
-m2: SH2 用のコードを生成します。
-m3: SH3 用のコードを生成します。
-m3e: SH3e 用のコードを生成します。
-mb: ビッグ・エンディアン・モードのプロセッサ用にコードをコンパイルします。
-ml: リトル・エンディアン・モードのプロセッサ用にコードをコンパイルします。
-mrelax: 可能であれば、リンク時にいくつかのアドレス参照を短くします。リンカ・オプション `-relax' を使います。

System V 用のオプション

System V Release 4 上では、他のコンパイラとの互換性のために、以下の追加的なオプションが利用可能です。

-G: 共用オブジェクトを作成します。このオプションではなく、 `-symbolic' か `-shared' を使うことをお勧めします。
-Qy: 出力中のアセンブラ指示子 .ident において、コンパイラにより使われる各ツールのバージョンを明らかにします。
-Qn: 出力ファイルの中に .ident 指示子を追加するのを差し控えます（これがデフォルトです）。
-YP,dirs: `-l' で指定されたライブラリを探す際には、ディレクトリ dirs だけを探索し、それ以外のディレクトリを探索しません。
-Ym,dir: M4 プリプロセッサを見つけるためにディレクトリ dir を探索します。アセンブラがこのオプションを使います。

V850 オプション

以下の `-m' オプションが V850 の実装に対して定義されています。

-mlong-calls
-mno-long-calls: すべての関数呼び出しを遠距離（近距離）であるものとして扱います。呼び出しが遠距離であると想定された場合、コンパイラは常に関数アドレスをレジスタにロードし、ポインタ経由で間接呼び出しを行います。
-mno-ep
-mep: ポインタを ep レジスタにコピーするのに同一のインデックス・ポインタを 4 回以上使う基本ブロックを最適化しません（あるいは、最適化します）。よりサイズの小さい sld 命令や sst 命令を使います。最適化を行うと、 `-mep' オプションはデフォルトで有効になります。
-mno-prolog-function
-mprolog-function: 関数のプロローグやエピローグにおいて、レジスタの待避や復元を行うのに外部関数を使いません（あるいは、使います）。外部関数を使うと速度は遅くなりますが、複数の関数が同一個数のレジスタを待避する場合には、使われるコード領域は少なくなります。最適化を行うと、 `-mprolog-function' オプションはデフォルトで有効になります。
-mspace: 可能な限りコードのサイズを小さくするよう努力します。現在のところこのオプションは、 `-mep' オプションと `-mprolog-function' オプションを有効にするだけです。
-mtda=n: サイズが n バイト以下の静的変数と広域変数を、レジスタ ep が指すタイニ・データ域に置きます。タイニ・データ域には合計で 256 バイト（バイト参照の場合は 128 バイト）まで置くことができます。
-msda=n: サイズが n バイト以下の静的変数と広域変数を、レジスタ gp が指すスモール・データ域に置きます。スモール・データ域には合計で 64 キロバイトまで置くことができます。
-mzda=n: サイズが n バイト以下の静的変数と広域変数を、メモリの先頭 32 キロバイトの範囲に置きます。
-mv850: ターゲット・プロセッサが V850 であることを指定します。
-mbig-switch: サイズの大きいスイッチ・テーブル（switch table）に適するコードを生成します。アセンブラやリンカが、スイッチ・テーブルの中にある分岐可能範囲外への分岐命令に関して文句を言ってくるばあいにのみ、このオプションを使ってください。

コード生成規約に対するオプション

以下のマシン非依存オプションは、コード生成処理において使われるインターフェイス規約を制御するものです。

ほとんどのオプションには、肯定形式と否定形式の両方があります。 `-ffoo' の否定形式は `-fno-foo' となります。以下の表においては、肯定形式、否定形式のうち、デフォルトではない方だけを載せてあります。もう一方の形式は、 `no-' を削除もしくは追加することによって、導き出すことができます。

-fexceptions

例外処理を有効にし、例外を伝播するために必要となる追加のコードを生成します。このオプションが指定されないと、 GNU CC は、 C++ のように通常例外処理を必要とする言語についてはデフォルトでこのオプションを有効にし、 C のように通常例外処理を必要としない言語についてはデフォルトでこのオプションを無効にします。しかし、 C++ で書かれた例外ハンドラと適切にやりとりする必要のある C のコードをコンパイルする際には、このオプションを有効にする必要があるかもしれません。また、例外処理を使わない古い C++ のプログラムをコンパイルする場合には、このオプションを無効にするのが良いかもしれません。

-fpcc-struct-return

「サイズの小さい」 struct 型や union 型の値を、サイズのより大きいものと同様、レジスタに入れるのではなくメモリ上に置いて返します。この規約は、効率の面では劣りますが、 GNU CC によってコンパイルされたファイルと他のコンパイラでコンパイルされたファイルの間で相互に呼び出しが可能になるという利点があります。構造体をメモリ上に置いて返すための正確な規約は、ターゲットのコンフィギュレーション・マクロに依存します。サイズの小さい構造体、共用体とは、そのサイズと境界整列がいずれかの整数型と一致するもののことです。

-freg-struct-return

可能な場合には、 struct 型と union 型の値をレジスタに入れて返す規約を使います。サイズの小さい構造体に関しては、こちらの方が `-fpcc-struct-return' よりも効率的です。 `-fpcc-struct-return' とその逆である `-freg-struct-return' をいずれも指定しないと、 GNU CC は、これら２つの規約のうちターゲットにとって標準であるものをデフォルトとして使います。標準的な規約が存在しない場合、 GNU CC が主要なコンパイラであるターゲットを除いて、 GNU CC は `-fpcc-struct-return' をデフォルトとします。 GNU CC が主要なコンパイラであるターゲットでは、標準を選択することが可能です。私たちは、より効率的な、レジスタを使って返すという方法を選択しました。

-fshort-enums

enum 型に対して、その宣言において示された可能な値の範囲にとってちょうど必要となるだけのバイト数を割り当てます。より明確に言えば、 enum 型は、十分な領域を持つ整数型のうちもっともサイズの小さいものと等しくなります。

-fshort-double

double 型のサイズとして、 float 型と同一のサイズを使います。

-fshared-data

このオプションを指定してコンパイルした範囲では、 const 指定されていないデータ変数は、プライベート・データではなく共用データとするよう要求します。特定のオペレーティング・システムにおいては、共用データの場合は同一のプログラム・ファイルを実行する複数のプロセス間で共用されるのに対して、プライベート・データの場合はプロセスごとに１つのコピーが存在します。このようなオペレーティング・システムにおいてのみ、両者の区別には意味があります。

-fno-common

初期化済みでない広域変数も、共通ブロックとして生成するのではなく、オブジェクト・ファイル中の bss セクションに割り当てます。これには、２つの異なるコンパイル処理の中で（extern を使わずに）同一の変数が宣言されていると、それらをリンクする際にエラーが発生するようになるという効果があります。これが役に立つかもしれない唯一のケースは、常にこのような振る舞いをする他のシステム上でもプログラムが機能するかどうかを検証したいという場合です。

-fno-ident

`#ident' 指示子を無視します。

-fno-gnu-linker

（C++ の生成関数や消去関数のような）広域における初期化処理を、（GNU リンカがこのような初期化を処理するための標準の方法であるシステム上において） GNU リンカによって使われる形式では出力しません。このオプションは、 GNU リンカ以外のリンカを使いたい場合に使います。 GNU リンカ以外のリンカを使う場合には、システム・リンカが確実に生成関数と消去関数を含めてリンクするようにするために、 collect2 プログラムを使うことも必要になります（collect2 は GNU CC ディストリビューションに含まれています）。 collect2 を使わなければならないシステムでは、コンパイラ・ドライバ gcc は自動的にこれを行うようにコンフィギュレーションで設定されます。

-finhibit-size-directive

アセンブラの .size 指示子を出力しません。また、関数が途中で分割され、分割された２つの部分がメモリ上の離れた箇所に置かれると問題を引き起こすことになるものはすべて出力しません。このオプションは、 `crtstuff.c' をコンパイルする際に使われます。これ以外では、このオプションを使う必要はない筈です。

-fverbose-asm

生成されるアセンブラ・コードをより読みやすくするために、そのアセンブラ・コードの中に余分のコメント情報を追加します。このオプションは一般的には、（おそらくはコンパイラ自身をデバッグする際に）生成されたアセンブリ・コードを実際に読む必要のある人にとってしか役に立ちません。デフォルトは `-fno-verbose-asm' ですが、この場合は追加の情報は省略され、２つのアセンブラ・ファイルを比較する場合に役に立ちます。

-fvolatile

ポインタを経由したメモリ参照はすべて volatile 指定されたものとみなします。

-fvolatile-global

外部データ項目と広域データ項目に対するメモリ参照はすべて volatile 指定されたものとみなします。

-fpic

ターゲット・マシンにおいてサポートされていれば、共用ライブラリにおいて使用するのに適した位置非依存コード（position-independent code、PIC）を生成します。位置非依存コードは、すべての固定アドレスに広域オフセット・テーブル（global offset table、GOT）を通じてアクセスします。プログラムが起動する時に、動的ローダが GOT のエントリを解決します（動的ローダは GNU CC には含まれていません。これはオペレーティング・システムの一部です）。リンクされた実行ファイルの GOT サイズがマシン固有の上限サイズを超過する場合には、 `-fpic' が機能しないことを示すリンカのエラー・メッセージが出力されます。この場合には、代わりに `-fPIC' を指定して再コンパイルしてください（この上限は、 m88k では 16k、 Sparc では 8k、 m68k と RS/6000 では 32k です。 386 にはこのような上限はありません）。位置非依存コードには特殊なサポートが必要となるため、特定のマシン上でしか機能しません。 386 上では、 GNU CC は、 System V では PIC をサポートしますが、 Sun 386i ではサポートしません。 IBM RS/6000 用に生成されたコードは常に位置非依存です。

-fPIC

ターゲット・マシンにおいてサポートされていれば、動的リンクに適する位置非依存コードを、広域オフセット・テーブルのサイズの上限をすべて回避して出力します。このオプションは、 m68k、 m88k、 Sparc において特に意味があります。位置非依存コードには特殊なサポートが必要となるため、特定のマシン上でしか機能しません。

-ffixed-reg

reg で指定される名前のレジスタを、固定的な役割を持つレジスタとして取り扱います。生成されたコードは（おそらくスタック・ポインタ、フレーム・ポインタ、あるいは、それ以外の固定的な役割を持つレジスタとして以外には）そのレジスタを決して参照するべきではありません。 reg はレジスタの名前でなければなりません。受け付けられるレジスタ名はマシン固有であり、マシン記述のマクロ・ファイルの中の REGISTER_NAMES マクロに定義されています。このフラグには否定形式はありません。というのは、このフラグは３つの選択肢の中から選んで指定するものだからです。

-fcall-used-reg

reg で指定される名前のレジスタを、関数呼び出しにより内容の破壊される割り当て可能なレジスタとして取り扱います。このレジスタは、関数呼び出しにまたがって存続することのないテンポラリ・オブジェクトや通常変数用として割り当てることができます。このオプションを指定してコンパイルされた関数は、レジスタ reg の待避、復元を行いません。スタック・ポインタやフレーム・ポインタのように、マシンの実行モデルにおいて広く知られている固定的な役割を持つレジスタに対してこのフラグを使うと、悲惨な結果がもたらされることになります。このフラグには否定形式はありません。というのは、このフラグは３つの選択肢の中から選んで指定するものだからです。

-fcall-saved-reg

reg で指定される名前のレジスタを、関数により待避される割り当て可能なレジスタとして取り扱います。このレジスタは、関数呼び出しにまたがって存続するテンポラリ・オブジェクトや通常変数に対しても割り当てることができます。このオプションを指定してコンパイルされた関数は、レジスタ reg を使う場合には、それを待避、復元します。スタック・ポインタやフレーム・ポインタのように、マシンの実行モデルにおいて広く知られている固定的な役割を持つレジスタに対してこのフラグを使うと、悲惨な結果がもたらされることになります。関数の戻り値を入れる可能性のあるレジスタに対してこのフラグを使うと、また異なる種類の悲惨な結果がもたらされることになります。このフラグには否定形式はありません。というのは、このフラグは３つの選択肢の中から選んで指定するものだからです。

-fpack-struct

すべての構造体メンバの間を開けることなく詰めます。このオプションを使うと、生成されるコードは最適なものではなくなり、構造体メンバのオフセットはシステム・ライブラリと一致しなくなるので、通常はこれを使いたくなることはないでしょう。

-fcheck-memory-usage

個々のメモリ・アクセスをチェックするための追加のコードを生成します。 GNU CC は、例えば `Checker' のような、不正なメモリ・アクセスを検出するツールに適したコードを生成するようになります。このオプションを指定すると、 asm キーワードや __asm__ キーワードは使えなくなります。また、呼び出される関数のうち副作用を持つものをコンパイルする際にも、このオプションを指定しなければなりません。そうしないと、検出ツールからエラー・メッセージが出力されるかもしれません。通常は、すべてのソース・コードをこのオプションを指定してコンパイルするべきです。ライブラリの中に含まれる関数で（例えば read のように）副作用を持つものを使うのであれば、そのライブラリをこのオプションを指定して再コンパイルすることはできないかもしれません。その場合には、 `-fprefix-function-name' オプションを使うことができます。このオプションは、ユーザのソース・コードをカプセル化して、別の関数が `-fcheck-memory-usage' を指定してコンパイルされたかのように見えるようにすることを、 GNU CC に対して要求するものです。これは、検出ツールにより提供される「スタブ」を呼び出すことで実現されます。呼び出されるすべての関数に対するスタブを見つけることも構築することもできない場合は、 `-fprefix-function-name' を指定せずに `-fcheck-memory-usage' を指定しなければならないかもしれません。

-fprefix-function-name

関数名に対して生成されるシンボルに接頭語を付加するよう GNU CC に対して要求します。 GNU CC は、呼び出される関数だけでなく、定義された関数の名前にも接頭語を付加します。このオプションを指定してコンパイルされたコードとこのオプションを指定せずにコンパイルされたコードを一緒にリンクすることは、スタブを使わないとできません。以下のコードを `-fprefix-function-name' を指定してコンパイルしたとしましょう。

extern void bar (int);
void
foo (int a)
{
  return bar (a + 5);

}

すると、 GNU CC はソース・コードがあたかも以下のように書かれているかのように、これをコンパイルします。

extern void prefix_bar (int);
void
prefix_foo (int a)
{
  return prefix_bar (a + 5);
}

このオプションは、 `-fcheck-memory-usage' とともに使うために設計されています。

-fstack-check

スタックの境界を超えないことを検証するコードを生成します。マルチ・スレッド環境ではこのフラグを指定するべきです。しかし、スタックが１つしか存在しない場合であれば、ほとんどすべてのシステムにおいてスタック・オーバフローは自動的に検出されるので、シングル・スレッド環境でこのオプションを指定する必要があることは稀です。

+e0

+e1

クラス内における仮想関数の定義が、コードを生成するのに使われるか、単に呼び出し側に対するインターフェイスを定義するだけであるかを制御します（C++ のみ）。これらのオプションは、 cfront 1.x における使用法との互換性のために提供されています。これの代替手段として推奨される GNU C++ の使用法は変わりつつあります。 See section １つのヘッダ・ファイルにおける宣言と定義。 `+e0' が指定されると、クラス内における仮想関数の定義は extern 宣言されます。（そのコンパイルの範囲では）その宣言は、インターフェイス仕様としてのみ使われ、仮想関数のコード生成には使われません。 `+e1' が指定されると G++ は、ソース・コード内において定義された仮想関数を実装するコードを生成し、それらをどこからでも見えるようにします。

GNU CC に影響を与える環境変数

このセクションでは、 GNU CC の動作に影響を与えるいくつかの環境変数について説明します。これらのオプションは、様々な種類のファイルを探す際に利用されるディレクトリや接頭語を指定することによって影響を与えます。

探索される場所については、 `-B'、 `-I'、 `-L' のようなオプションを使うことによっても指定可能であることに注意してください（see section ディレクトリ探索のためのオプション）。これらのオプションによる指定は、環境変数による指定よりも優先されます。一方、環境変数による指定は、 GNU CC のコンフィギュレーションにおける指定よりも優先されます。 @xref{Driver}.

TMPDIR: TMPDIR がセットされていると、それは一時ファイルを作成するのに使われるディレクトリを指定します。 GNU CC は、コンパイル処理のある１つの段階の出力を保存するのに一時ファイルを使い、それが次の段階の入力として使われることになります。例えば、プリプロセッサの出力は狭義のコンパイラの入力となります。
GCC_EXEC_PREFIX: GCC_EXEC_PREFIX がセットされていると、それはコンパイラにより実行される下位プログラムの名前の接頭語を指定します。この接頭語が下位プログラムの名前に結合される際にはスラッシュは追加されません。しかし、もしそうしたいのであれば、末尾がスラッシュである接頭語を指定することもできます。指定された接頭語を使った名前で下位プログラムを見つけることができない場合、 GNU CC は下位プログラムが通常置かれている場所を探そうとします。 GCC_EXEC_PREFIX のデフォルトの値は `prefix/lib/gcc-lib/' です。ここで、 prefix は `configure' スクリプトを実行した時の prefix の値です。 `-B' オプションで指定された別の接頭語があれば、そちらが優先されます。この接頭語は、リンクに使われる `crt0.o' のようなファイルを見つける際にも使われます。さらに、ヘッダ・ファイルを探すディレクトリを見つける際にも、この接頭語は変わった方法で使われます。通常は名前が `/usr/local/lib/gcc-lib' （より正確には、 GCC_INCLUDE_DIR の値）で始まる標準ディレクトリの１つ１つを、指定された接頭語で始まる名前に置き換えることによって、 GNU CC は別のディレクトリ名を作成しようとします。したがって、 `-Bfoo/' が指定されると、通常であれば `/usr/local/lib/bar' を探すところを、 GNU CC は `foo/bar' を探します。これらの代替ディレクトリが最初に探索されます。標準ディレクトリはその次に探索されます。
COMPILER_PATH: COMPILER_PATH の値は、 PATH と同様、コロンで区切られたディレクトリのリストです。 GNU CC は、 GCC_EXEC_PREFIX を使って下位プログラムを見つけることができないと、下位プログラムを探すのにこの環境変数で指定されたディレクトリを探索します。
LIBRARY_PATH: LIBRARY_PATH の値は、 PATH と同様、コロンで区切られたディレクトリのリストです。ネイティブ・コンパイラとしてコンフィギュレーションが行われた場合、 GNU CC は、 GCC_EXEC_PREFIX を使って特殊なリンカ・ファイルを見つけることができないと、特殊なリンカ・ファイルを探すのにこの環境変数で指定されたディレクトリを探索します。 GNU CC を使ったリンク処理では、 `-l' オプションで指定された通常のライブラリを探す際にもこれらのディレクトリが使われます（しかし、 `-L' で指定されたディレクトリが最初に使われます）。
C_INCLUDE_PATH
CPLUS_INCLUDE_PATH
OBJC_INCLUDE_PATH: これらの環境変数は特定の言語に関係するものです。個々の変数の値は、 PATH と同様、コロンで区切られたディレクトリのリストです。 GNU CC がヘッダ・ファイルを探す際には、まず `-I' で指定されたディレクトリが探索され、続いて、使用している言語に対応する変数においてリストされているディレクトリが探索されます。標準のヘッダ・ファイル・ディレクトリは、このあとに探索されます。
DEPENDENCIES_OUTPUT: この変数がセットされていると、その値は、コンパイラにより処理されるヘッダ・ファイルに基づいて make 用の依存関係をどのように出力するかを指定します。この出力は、 `-M' オプション（see section プリプロセッサを制御するオプション）による出力とよく似ていますが、この出力は別ファイルに書き込まれ、かつ、通常のコンパイル処理も行われます。 DEPENDENCIES_OUTPUT の値は単にファイル名であることもあります。この場合、 make ルールは DEPENDENCIES_OUTPUT により指定されるファイル名のファイルに書き込まれ、ターゲットの名前はソース・ファイルの名前から推測されます。また、 DEPENDENCIES_OUTPUT の値は `file target' という形式を取ることもあります。この場合、 target をターゲット名として、ファイル file にルールが書き込まれます。

Protoize の実行

プログラム protoize は、 GNU C の必須ではない構成要素です。プログラムにプロトタイプを追加するためにこれを使うことができます。これにより、プログラムはある点において ANSI C 方式に変換されます。一緒に提供されている unprotoize がこの逆のことを行います。こちらは、プロトタイプを見つけると、そこから引数の型情報を取り除きます。

これらのプログラムを実行する際には、ソース・ファイルをコマンドライン引数として指定しなければなりません。変換プログラムは、ソース・ファイルの中でどのような関数が定義されているかを調べるために、まずそれらをコンパイルすることから始めます。ファイル foo に関して収集された情報は、 `foo.X' という名前のファイルに保存されます

スキャン処理が終わると、次に実際の変換が始まります。指定されたファイルはすべて変換される資格があります。指定されたファイルが取り込むファイルも（ソース・ファイルであれヘッダ・ファイルであれ）また変換される資格があります。

しかし、資格のあるファイルがすべて変換されるわけではありません。デフォルトでは、 protoize も unprotoize もカレント・ディレクトリにあるソース・ファイルやヘッダ・ファイルだけを変換します。あるディレクトリの下のファイルを変換したい場合には、 `-d directory' オプションでその追加のディレクトリを指定することができます。変換の対象外としたい特定のファイルを `-x file' オプションで指定することもできます。あるファイルが変換されるのは、そのファイルには変換される資格があり、そのファイルの存在するディレクトリの名前が指定されたディレクトリ名と一致し、かつ、そのディレクトリ内におけるそのファイル名が除外されていない、という条件が満足されている場合です。

protoize による基本的な変換は、引数の型を指定するためにほとんどの関数定義や関数宣言を書き直すことです。書き直されることのない唯一のものは、可変個数の引数を取る関数定義や関数宣言です。

protoize は、関数定義よりも前にある関数呼び出しから利用できるように、ソース・ファイルの先頭にプロトタイプ宣言を挿入するようにすることもできます。また、宣言されていない関数が呼び出されているブロックの中に、ブロック・スコープを持つプロトタイプ宣言を挿入することもできます。

unprotoize による基本的な変換は、引数の型を取り除くためにほとんどの関数宣言を書き直すことと、 ANSI 以前の旧方式の形に関数定義を書き直すことです。

どちらの変換プログラムも、変換できない関数宣言や関数定義については警告を表示します。これらの警告は `-q' で表示しないようにすることができます。

protoize や unprotoize からの出力は、元のソース・ファイルを置き換えます。元のファイルは、末尾が `.save' で終わる名前に変えられます。末尾が `.save' で終わる名前のファイルが既に存在する場合は、ソース・ファイルは破棄されてしまいます。

protoize と unprotoize はいずれも、プログラムをスキャンしてその中で使われている関数に関する情報を収集する部分は GNU CC に依存しています。したがって、どちらのプログラムも、 GNU CC がインストールされるまでは機能しません。

以下に、 protoize と unprotoize において使うことのできるオプションの表を示します。これらのオプションは、明示的にそうではないと記されていない限り、どちらのプログラムでも機能します。

-B directory: 通常のディレクトリ（通常は `/usr/local/lib'）ではなく、 directory により指定されるディレクトリにおいてファイル `SYSCALLS.c.X' を探します。このファイルは、標準のシステム関数に関するプロトタイプ情報を保持しています。このオプションは、 protoize にしか適用できません。
-c compilation-options: `.X' ファイルを作成するために gcc を実行する際に、 compilation-options をオプションとして使います。 `.X' ファイルを出力するよう gcc に指示するために、特別なオプション `-aux-info' が常に追加で渡されます。コンパイル処理のためのオプションは、 protoize や unprotoize に対して単一の引数として渡されなければならない点に注意してください。 gcc のオプションをいくつか指定したい場合には、コンパイル処理用のオプションの集合全体を引用符で囲んで、それらがシェルにおいて単一語となるようにしなければなりません。正しくない種類の出力を作成するという理由により、使うことのできない gcc 引数もあります。 `-g'、 `-O'、 `-c'、 `-S'、 `-o' がこれに相当します。 compilation-options の中にこれらを含めても、無視されます。
-C: `.c' の代わりに `.C' で終わるようにファイル名を変更します。これは、 C のプログラムを C++ に変換している場合に便利です。このオプションは、 protoize にしか適用できません。
-g: 明示的な広域宣言を追加します。これは、ファイルの中で呼び出されているが宣言されていない関数１つ１つについて、そのソース・ファイルの先頭において明示的な宣言が挿入されることを意味しています。これらの宣言は、宣言されていない関数への呼び出しを含む最初の関数定義よりも前に置かれます。このオプションは、 protoize にしか適用できません。
-i string: 旧方式のパラメータ宣言を、文字列 string を使ってインデントします。このオプションは、 unprotoize(9) にしか適用できません。 unprotoize は、プロトタイプ化された関数定義を旧方式の関数定義に変換します。この旧方式の関数定義では、引数は、引数リストと最初の `{' の間で宣言されます。デフォルトでは、 unprotoize は５個の空白をインデントに使います。５個の空白ではなくただ１個の空白でインデントを行いたい場合は、 `-i " "' を使ってください。
-k: `.X' ファイルを保持します。通常このファイルは、変換処理の終了後に削除されます。
-l: 明示的な局所宣言を追加します。 `-l' を指定すると protoize は、宣言されていない関数を呼び出す個々のブロックの中に、その関数のプロトタイプ宣言を挿入します。このオプションは、 protoize にしか適用できません。
-n: 実際の変更処理を行いません。このモードでは、 `-n' が指定されなかった場合に実行されたであろう変換処理に関する情報が表示されるだけです。
-N: `.save' ファイルを作成しません。元のファイルは削除されてしまいます。このオプションは注意して使ってください。
-p program: program という名前のプログラムをコンパイラとして使います。通常は `gcc' という名前が使われます。
-q: 静かに処理を実行します。ほとんどの警告は表示されません。
-v: gcc の `-v' と同様、バージョン番号を表示します。

プログラムのソース・ファイルをコンパイルするのに特殊なコンパイラ・オプションが必要な場合は、その特定のオプションと `-aux-info' オプションを指定して gcc をそのソース・ファイルに対して実行することによって、そのファイルの `.X' ファイルを特別に生成します。その後に、ファイルの集合全体に対して protoize を実行します。この場合、そこに存在する `.X' ファイルはソース・ファイルよりも新しいので、 protoize はその `.X' ファイルを使うことになります。以下に例を示します。

gcc -Dfoo=bar file1.c -aux-info
protoize *.c

こうした特別なファイルの `.X' ファイルが既に存在するにもかかわらず、他のファイルとあわせてこれら特別なファイルも protoize コマンドに渡す必要があります。こうしないと、これらのファイルは変換されないからです。

protoize を上手に使うための方法に関する詳細については、 See section protoize の使用に関する警告。

[Contents] [Back] [Prev] [Up] [Next] [Forward]