GCCコマンド・オプション

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

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

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

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

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

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

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

オプションの要約

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

全体的（overall）オプション

出力の種類を制御するオプションを参照してください.

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

C言語オプション

Cの方言を制御するオプションを参照してください.

-ansi -flang-isoc9x -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++言語オプション

C++の方言を制御するオプションを参照してください.

-fno-access-control  -fcheck-new  -fconserve-space  -fdollars-in-identifiers
-fno-elide-constructors  -fexternal-templates  -ffor-scope  
-fno-for-scope  -fno-gnu-keywords  -fguiding-decls  -fhandle-signatures
-fhonor-std -fhuge-objects  -fno-implicit-templates  -finit-priority
-fno-implement-inlines -fname-mangling-version-n  -fno-default-inline  
-foperator-names  -fno-optional-diags  -fpermissive -frepo  -fstrict-prototype
-fsquangle  -ftemplate-depth-n  -fthis-is-variable  -fvtable-thunks
-nostdinc++  -Wctor-dtor-privacy -Wno-deprecated -Weffc++  
-Wno-non-template-friend 
-Wnon-virtual-dtor  -Wold-style-cast  -Woverloaded-virtual  
-Wno-pmf-conversions  -Wreorder  -Wsign-promo  -Wsynth

警告オプション

警告を要求もしくは抑制するオプションを参照してください.

-fsyntax-only  -pedantic  -pedantic-errors
-w  -W  -Wall  -Waggregate-return  -Wbad-function-cast
-Wcast-align  -Wcast-qual  -Wchar-subscripts  -Wcomment
-Wconversion  -Werror  -Wformat
-Wid-clash-len  -Wimplicit -Wimplicit-int 
-Wimplicit-function-declaration  -Wimport
-Werror-implicit-function-declaration  -Winline
-Wlarger-than-len  -Wlong-long
-Wmain  -Wmissing-declarations  -Wmissing-noreturn
-Wmissing-prototypes  -Wmultichar  -Wnested-externs  -Wno-import  
-Wparentheses -Wpointer-arith  -Wredundant-decls
-Wreturn-type -Wshadow  -Wsign-compare  -Wstrict-prototypes  
-Wswitch  -Wtraditional  
-Wtrigraphs -Wundef  -Wuninitialized  -Wunused  -Wwrite-strings
-Wunknown-pragmas

デバッグ・オプション

ユーザ・プログラムまたはGCCをデバッグするためのオプションを参照してください.

-a  -ax  -dletters  -fdump-unnumbered -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

最適化オプション

最適化を制御するオプションを参照してください.

-fbranch-probabilities  -foptimize-register-moves
-fcaller-saves  -fcse-follow-jumps  -fcse-skip-blocks
-fdelayed-branch   -fexpensive-optimizations
-ffast-math  -ffloat-store  -fforce-addr  -fforce-mem
-fdata-sections -ffunction-sections  -fgcse 
-finline-functions -finline-limit-n -fkeep-inline-functions
-fno-default-inline -fno-defer-pop  -fno-function-cse
-fno-inline  -fno-peephole  -fomit-frame-pointer -fregmove
-frerun-cse-after-loop  -frerun-loop-opt -fschedule-insns
-fschedule-insns2  -fstrength-reduce  -fthread-jumps
-funroll-all-loops  -funroll-loops
-fmove-all-movables  -freduce-all-givs -fstrict-aliasing
-O  -O0  -O1  -O2  -O3 -Os

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

プリプロセッサを制御するオプションを参照してください.

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

アセンブラ・オプション

アセンブラへのオプション渡しを参照してください.

-Wa,option

リンカ・オプション

リンク処理用のオプションを参照してください.

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

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

ディレクトリ探索のためのオプションを参照してください.

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

ターゲット・オプション

ターゲット・マシンとコンパイラ・バージョンの指定を参照してください.

-b machine  -V version

マシン依存オプション

ハードウェアのモデルとコンフィギュレーションを参照してください.

M680x0オプション
-m68000  -m68020  -m68020-40  -m68020-60  -m68030  -m68040
-m68060  -mcpu32 -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 -mno-apcs-frame
-mapcs-26 -mapcs-32
-mapcs-stack-check -mno-apcs-stack-check
-mapcs-float -mno-apcs-float
-mapcs-reentrant -mno-apcs-reentrant
-msched-prolog -mno-sched-prolog
-mlittle-endian -mbig-endian -mwords-little-endian
-mshort-load-bytes -mno-short-load-bytes -mshort-load-words -mno-short-load-words
-msoft-float -mhard-float -mfpe
-mthumb-interwork -mno-thumb-interwork
-mcpu= -march= -mfpe= 
-mstructure-size-boundary=
-mbsd -mxopen -mno-symrename
-mabort-on-noreturn
-mno-sched-prolog

Thumbオプション
-mtpcs-frame -mno-tpcs-frame
-mtpcs-leaf-frame -mno-tpcs-leaf-frame
-mlittle-endian  -mbig-endian
-mthumb-interwork -mno-thumb-interwork
-mstructure-size-boundary=

MN10200オプション
-mrelax

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

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
-maix64  -maix32  -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 -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 -mips4 -mlong64  -mlong32 -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
-mabi=32 -mabi=n32 -mabi=64 -mabi=eabi

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 -mpreferred-stack-boundary=num

HPPAオプション
-march=architecture type
-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  -mpa-risc-2-0 -mportable-runtime
-mschedule=cpu type  -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
-mmemory-latency=time

Clipperオプション
-mc300  -mc400

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

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

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

ARCオプション
-EB  -EL
-mmangle-cpu  -mcpu=cpu  -mtext=text section
-mdata=data section  -mrodata=readonly data section

TMS320C3x/C4xオプション
-mcpu=cpu -mbig -msmall -mregparm -mmemparm
-mfast-fix -mmpyi -mbk -mti -mdp-isr-reload
-mrpts=count  -mrptb -mdb -mloop-unsigned
-mparallel-insns -mparallel-mpy -mpreserve-float

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

NS32Kオプション
-m32032 -m32332 -m32532 -m32081 -m32381 -mmult-add -mnomult-add
-msoft-float -mrtd -mnortd -mregparam -mnoregparam -msb -mnosb
-mbitfield -mnobitfield -mhimem -mnohimem

コード生成オプション

コード生成規約に対するオプションを参照してください.

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

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

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

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

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'のうち1つのオプションを使って、 どの段階で停止すべきかをgccに対して指示することができます。 組み合わせによっては （例えば、 `-x cpp-output -E'） gccに対して何も実行しないよう指示したことになるということに注意してください。

-c

ソース・ファイルのコンパイル、 または、 アセンブルを行いますが、 リンクは行いません。 リンク処理段階は実行されません。 最終的な出力形態は、 個々のソース・ファイルに対応するオブジェクト・ファイルとなります。 デフォルトでは、 ソース・ファイルに対応するオブジェクト・ファイルの名前は、 ソース・ファイル名の接尾語`.c'、 `.i'、 `.s'等を`.o'に置き換えることによって作られます。 接尾語が認識されない入力ファイルは、 コンパイルもアセンブルも必要とされないので、 無視されます。

-S

狭義のコンパイル処理段階の後に停止し、 アセンブル処理を実行しません。 出力形態は、 指定された入力ファイルのうちアセンブラ・コードで記述されていないものに対するアセンブラ・コードのファイルとなります。 デフォルトでは、 ソース・ファイルに対応するアセンブラ・ファイルの名前は、 ソース・ファイル名の接尾語`.c'、 `.i'等を`.s'に置き換えることによって作られます。 コンパイルの必要がない入力ファイルは無視されます。

-E

前処理段階の後に停止し、 狭義のコンパイル処理を実行しません。 出力形態は、 前処理済みのソース・コードとなり、 これは標準出力に出力されます。 前処理の必要がない入力ファイルは無視されます。

-o file

fileによって指定されるファイルを出力先とします。 これは、 生成される出力の種類に関係なく適用されます。 出力が、 実行可能ファイル、 オブジェクト・ファイル、 アセンブラ・ファイル、 前処理済みのCコードのいずれであっても、 無関係に適用されます。 出力ファイルは1つしか指定できないので、 複数の入力ファイルをコンパイルする際に`-o'を使うのは、 出力として実行可能ファイルを生成しようとしている場合を除けば、 意味のないことです。 `-o'が指定されないと、 デフォルトでは、 実行可能ファイルは`a.out'に、 `source.suffix'に対応するオブジェクト・ファイルは`source.o'に、 `source.suffix'に対応するアセンブラ・ファイルは`source.s'に、 また、 すべての前処理済みのCのソースは標準出力に、 それぞれ出力されます。

-v

（広義の）コンパイル処理の各段階において実行されたコマンドを （標準エラー出力に） 表示します。 また、 コンパイラ・ドライバ・プログラム、 プリプロセッサ、 狭義のコンパイラの各バージョン番号も表示します。

-pipe

（広義の）コンパイル処理の各段階の間で通信を行うのに、 一時ファイルではなくパイプを使用します。 これは、 パイプからの読み込みができないアセンブラを持つシステムでは正しく機能しません。 GNUアセンブラを使えば、 まったく問題がありません。

--help

gccが理解したコマンドライン・オプションに関する説明を （標準出力に） 表示します。 -vオプションが同時に指定されていると、 gccによって起動されるさまざまなプロセスに対しても--helpオプションが渡されます。 これは、 それらのプロセスが受け付けたコマンドライン・オプションを表示することができるようにするためです。 また、 -Wオプションが同時に指定されていると、 関連するドキュメントを持たないコマンドライン・オプションもあわせて表示されます。

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

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

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

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

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

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

-ansi

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

-flang-isoc9x

C9X標準にある機能のサポートを有効にします。 特に、 C9Xのrestrictキーワードのサポートを有効にします。 このオプションが指定されていない場合でも、 以前のC標準と矛盾しないものであればC9Xの機能を使うことができます。 例えば、 -flang-isoc9xが指定されていない場合でも、 __restrict__を使うことはできます。

-fno-asm

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

-fno-builtin

名前の先頭が`__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では不正な1個の前処理数（preprocessing number）とみなされる構成が、 式として扱われます。
• 文字列「定数」は必ずしも定数ではありません。 それは書き込み可能な領域に置かれ、 見掛け上は同一の複数の定数が別個に割り当てられます （これは`-fwritable-strings'が持つ効果と同じです）。
• register宣言されていないすべての自動変数の内容は、 longjmpにより保存されます。 通常の場合、 GNU CはANSI Cに従うので、 volatile宣言されていない自動変数の内容は破壊される可能性があります。
• 文字のエスケープ・シーケンスである`\x'や`\a'等は、 それぞれ字義どおりの文字`x'や`a'として評価されます。 `-traditional'を指定しないと、 `\x'は文字の16進数表記の接頭語となり、 `\a'はベルを表わすことになります。

通常は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'の指定の有無によって異なる機能を持つようなヘッダ・ファイルを書く必要がある場合には、 両方の事前定義マクロをテストすることによって4つの状況を区別することができます。 ここで4つの状況とは、 GNU C、 伝統的なGNU C、 他のANSI Cコンパイラ、 他の旧式のCコンパイラがそれぞれ使われている状況のことです。 `-traditional'を使うと、 事前定義マクロ__STDC_VERSION__も定義されません。 これらの事前定義マクロ、 および、 その他の事前定義マクロに関する詳細については、 The C Preprocessorの`Standard Predefined Macros'を参照してください。
• プリプロセッサは、 （改行が`\'によってエスケープされていなければ） 文字列定数は改行をもって終了するものとみなします （`-traditional'を指定しなければ、 文字列定数は、 入力されたとおりに改行文字を含むことができます）。

-fcond-mismatch

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

-funsigned-char

型charを、 unsigned charのように無符号（unsigned）にします。 個々の種類のマシンごとに、 charのデフォルトがあります。 デフォルトがunsigned charのようになる場合とsigned charのようになる場合の2つに1つです。 理想的には、 移植性のあるプログラムでは、 オブジェクトの符号の有無に依存するような場合には常に、 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'と同等です。 (1)

-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 -frepo -O -c firstClass.C

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

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

-fno-access-control

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

-fcheck-new

割り当てられた記憶域の内容の変更を試みる前に、 演算子newにより返されたポインタがヌル・ポインタでないことをチェックします。 現在のWorking Paperの要件では、 演算子newは決してヌル・ポインタを返してはならないとされているので、 このチェックは普通は必要ありません。 このオプションを使う代わりに、 演算子newがどのような例外も発生させないと指定することもできます。 `throw()'を宣言すれば、 g++は戻り値をチェックするようになります。 `new(nothrow)'もあわせて参照してください。

-fconserve-space

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

-fdollars-in-identifiers

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

-fno-elide-constructors

C++標準では、 同一型の別のオブジェクトを初期化するためだけに使われるテンポラリの生成を省略することが許されます。 このオプションを指定するとそのような最適化が無効になり、 すべての場合にコピー・コンストラクタを呼び出すようg++に強制します。

-fexternal-templates

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

-falt-external-templates

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

-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年の9月に案内宣言（guiding declaration）が削除されるよりも前のC++言語の仕様を反映しています。 このオプションは、 暗黙のうちに`-fname-mangling-version-0'を指定することを意味しており、 他の名前マングル処理（name mangling）のバージョンではうまく機能しません。 ABIを変更するすべてのオプションと同様に、 libgcc.aを含むすべてのC++コードが、 このオプションを同一の設定にしてビルドされなければなりません。

-fhandle-signatures

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

-fhonor-std

namespace stdを、 無視するのではなく、 名前空間として扱います。 以前のバージョンのg++との互換性のために、 デフォルトでは、 stdが関係する場合、 namespace-declarations（namespace宣言）、 using-declarations（using宣言）、 using-directives（using指示子）、 namespace-names（namespace名） は無視されます。

-fhuge-objects

1つの`short int'で表わすことのできる数を超えるサイズを持つオブジェクトに対する仮想関数の呼び出しをサポートします。 デフォルトでは、 ユーザはこのフラグを使うべきではありません。 このフラグを使う必要がある場合には、 コンパイラがその旨知らせてくれます。 このフラグは、 -fvtable-thunksを指定してコンパイルをする場合には役に立ちません。 ABIを変更するすべてのオプションと同様に、 libgccを含むすべてのC++コードが、 このオプションを同一の設定にしてビルドされなければなりません。

-fno-implicit-templates

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

-fno-implicit-inline-templates

暗黙のうちにインスタンス化されるインライン・テンプレートのコードも出力しません。 デフォルトでは、 最適化を伴うコンパイルと伴わないコンパイルの両方が同一の明示的なインスタンス化を必要とするように、 インライン・テンプレートに対しては異なる取り扱いを行ないます。

-finit-priority

ファイル・スコープを持つオブジェクトの初期化の順序を制御するために、 `__attribute__ ((init_priority (n)))'をサポートします。 ELFターゲット上では、 このオプションはバージョン2.10以降のGNU ldを必要とします。

-fno-implement-inlines

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

-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);

ABIを変更するすべてのオプションと同様に、 libgccを含むすべてのC++コードが、 このオプションを同一の設定にしてビルドされなければなりません。

-foperator-names

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

-fno-optional-diags

C++標準によればコンパイラが実行する必要はない診断処理を無効にします。 現在のところ、 このような診断処理でg++によって実行されるものは、 ある1つのクラスの中で複数の意味を持つ名前に対するものだけです。

-fpermissive

非適合なコードに関するメッセージの位置付けを、 エラーから警告に格下げします。 g++は、 デフォルトでは、 `-pedantic'ではなく`-pedantic-errors'をセットします。 このオプションは、 これを逆転させるものです。 この振る舞いとこのオプションは、 GNU Cの場合と同様に機能する`-pedantic'によって取って代わられました。

-frepo

自動的なテンプレートのインスタンス生成を有効にします。 このオプションは、 暗黙のうちに`-fno-implicit-templates'を指定します。 詳細については、 テンプレート・インスタンスの存在箇所を参照してください。

-fno-rtti

C++の実行時型識別機能 （`dynamic_cast'や`typeid'） によって使われる情報の生成を無効にします。 C++言語のこれらの機能 （あるいは、 `dynamic_cast'を内部的に使用する例外処理機構） を使わない場合、 このフラグによってある程度領域を節約することができます。

-fstrict-prototype

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

-fsquangle

-fno-squangle

`-fsquangle'は、 識別子に対する簡易化された名前マングル処理（name mangling）を有効にします。 特に、 複数回出現する型名やクラス名を認識して、 それらを特殊な短いIDで置き換えることによって、 非常に長い名前を短くするのに役立ちます。 このオプションは、 使用されるすべてのC++ライブラリがこのオプションを指定してコンパイルされていることを必要とします。 このオプションは、 デフォルトでは無効 （すなわち、 `-fno-squangle'） になっています。 ABIを変更するすべてのオプションと同様に、 libgcc.aを含むすべてのC++コードが、 このオプションを同一の設定にしてビルドされなければなりません。

-ftemplate-depth-n

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

-fthis-is-variable

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

-fvtable-thunks

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

-nostdinc++

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

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

-fno-default-inline

クラス・スコープの中で定義された関数に対して`inline'が指定されているものと想定しません。 最適化を制御するオプションを参照してください。 これらの関数はインライン関数と同様の結合種類となることに注意してください。 単に、 デフォルトではインライン展開されないというだけです。

-Wctor-dtor-privacy (C++ only)

すべてのコンストラクタ、 デストラクタがprivateであり、 フレンド関数やpublicな静的なメンバ関数を1つも持たないために、 あるクラスが使用不可のように見える場合に、 警告を出力します。

-Wnon-virtual-dtor (C++ only)

あるクラスがポリモルフィックな使い方をされるように見えるために、 そのクラスの宣言するvirtual指定されていないデストラクタがおそらくはvirtual指定されるべきである場合に、 警告を出力します。

-Wreorder (C++のみ)

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

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

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

以下の`-W...'オプションは、 `-Wall'による影響を受けることのないオプションです。

-Weffc++ (C++のみ)

Scott Meyers著「Effective C++」に記されているいくつかのスタイル・ガイドラインに対する違反に対して警告を出力します。 このオプションを使う場合、 標準ライブラリのヘッダ・ファイルがこれらのガイドラインのすべてに従っているわけではないということを認識しておく必要があります。 このために出力される警告は、 `grep -v'を使って除去することができます。

-Wno-deprecated (C++のみ)

推奨されない（deprecated）機能を使用していることに関しては警告を出力しません。 使用することに賛成できない機能を参照してください。

-Wno-non-template-friend (C++のみ)

テンプレートの内部においてテンプレートを使用しないフレンド関数が宣言されている場合に出力される警告を抑止します。 明示的なテンプレートのサポートがg++に加えられましたが、 フレンドの名前が修飾されないID（ 例えば、 `friend foo(int)'） である場合、 C++言語仕様（セクション14.5.3）によれば、 そのフレンドは通常の非テンプレート関数を宣言ないしは定義するのでなければなりません。 g++では、 明示的にこの仕様が実装される以前は、 修飾されないIDをテンプレート関数のある特殊化として解釈することがありえました。 標準に準拠しないこのような振る舞いは、 もはやg++のデフォルトの振る舞いではないため、 既存のコードの中から潜在的に問題になりそうな箇所をコンパイラに探させることができるよう `-Wnon-template-friend' というオプションが提供されていて、 デフォルトで有効になっています。 コンパイラのこの新しい振る舞いは `-fguiding-decls'フラグによって無効にすることもできます。 このフラグは、 古くから実装されている、 標準に準拠しないコンパイラ・コードを動作させます。 同様のこと（新しい振る舞いの無効化）は、 `-Wno-non-template-friend'でも実現することができます。 このフラグの場合は、 標準に準拠するコンパイラ・コードが使われますが、 役に立つ警告出力は抑止されます。

-Wold-style-cast (C++のみ)

旧式の （C方式の） キャストがC++プログラムの内部で使われていると、 警告メッセージを出力します。 新しいスタイルのキャスト （`static_cast'、 `reinterpret_cast'、 `const_cast'） は、 意図されない結果に対しては、 旧式のキャストほど無防備ではありません。

-Woverloaded-virtual (C++のみ)

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

-Wno-pmf-conversions (C++のみ)

メンバ関数に結合されたポインタを通常のポインタに変換することに対する診断を無効にします。

-Wsign-promo (C++のみ)

オーバーロード解決に際して、 無符合型もしくは列挙型から有符合型への整数拡張が、 （その有符合型と）同サイズの無符合型への整数拡張よりも優先されて選択される場合に警告を出力します。 以前のバージョンのg++は無符合性を維持するよう試みますが、 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 ='を使います。

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

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

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

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

-fsyntax-only

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

-pedantic

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

-pedantic-errors

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

-w

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

-Wno-import

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

-Wchar-subscripts

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

-Wcomment

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

-Wformat

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

-Wimplicit-int

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

-Wimplicit-function-declaration

-Werror-implicit-function-declaration

宣言される前に関数が使われている場合に、 常に警告 （またはエラー） を出力します。

-Wimplicit

`-Wimplicit-int'と`-Wimplicit-function-declaration'を合わせたものと同一です。

-Wmain

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

-Wmultichar

（`'FOOF''のような） 複数文字から構成される定数が使われていると警告を出力します。 通常の場合、 これはユーザのコードの中にタイプ・ミスがあることを示唆しています。 このような定数は実装依存の値を取るため、 移植性のあるコードの中では使われるべきではありません。

-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文が1つでもあれば、 警告を出力します。

-Wswitch

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

-Wtrigraphs

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

-Wunused

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

-Wuninitialized

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

{
  int x;
  switch (y)
    {
    case 1: x = 1;
      break;
    case 2: x = 4;
      break;
    case 3: x = 5;
    }
  foo (x);
}

yの値が常に1、 2、 3のいずれかであれば、 xは常に初期化されますが、 GCCにはこのことが分かりません。 以下に、 もう1つよくあるケースを示します。

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

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

-Wunknown-pragmas

GCCの知らない#pragma指示子が検出されたときに警告を出力します。 このコマンドライン・オプションが使われると、 システム・ヘッダ・ファイルの中にある未知のプラグマについても警告が出力されることになります。 この種の警告が`-Wall'コマンドライン・オプションによってのみ有効化された場合は、 このようなことは起こりません。

-Wall

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

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

-W

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

• volatile宣言されていない自動変数が、 longjmpの呼び出しによって値が変更される可能性がある。 この警告もまた、 最適化コンパイルにおいてしか出力されません。 コンパイラは、 setjmpの呼び出しだけを認識します。 コンパイラには、 どこでlongjmpが呼び出されるのか分かりません。 実際、 シグナル・ハンドラは、 ソース・コードの中の任意の箇所でそれを呼ぶことができます。 この結果、 問題を引き起こすような箇所でlongjmpが呼び出されることがあり得ないため、 実際にはまったく問題がないような場合であっても、 警告が出力されることになるかもしれません。
• 関数が、 戻り値を持って復帰することも、 戻り値を持たずに復帰することもできるようになっている （関数本体の終端に達することは、 戻り値を持たずに復帰することとみなされます）。 例えば、 以下の関数はそのような警告を出力させることになります。

  foo (a)
  {
    if (a > 0)
      return a;
  }
  

• 式文（expression-statement）、 もしくは、 カンマ式（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 };
  

• 集合体の持つ初期化子がすべてのメンバを初期化しない。 例えば、 以下のソース・コードは、 x.hが暗黙的にゼロに初期化されるために、 このような警告を出力させることになります。

  struct s { int f, g, h; };
  struct s x = { 3, 4 };
  

-Wtraditional

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

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

-Wundef

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

-Wshadow

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

-Wid-clash-len

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

-Wlarger-than-len

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

-Wpointer-arith

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

-Wbad-function-cast

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

-Wcast-qual

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

-Wcast-align

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

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

-Wstrict-prototypes

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

-Wmissing-prototypes

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

-Wmissing-declarations

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

-Wmissing-noreturn

noreturn属性指定の候補となる可能性のある関数に対して警告を出力します。 これらの関数は、 そのような候補となる可能性を持つというだけであって、 絶対的にそうであるというわけではないので注意してください。 noreturn属性を追加する前に、 十分に注意を払って、 関数が実際に復帰することがないということを手作業で検証するべきです。 さもないと、 コード生成上の微妙なバグが入り込む可能性があります。

-Wredundant-decls

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

-Wnested-externs

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

-Winline

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

-Wlong-long

`long long'型が使われていると警告を出力します。 これがデフォルトです。 この警告メッセージが出力されないようにするには、 `-Wno-long-long'を使ってください。 `-Wlong-long'、 `-Wno-long-long'のどちらのフラグも、 `-pedantic'フラグが使われている場合にのみ考慮に入れられます。

-Werror

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

ユーザ・プログラムまたはGCCをデバッグするためのオプション

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

-g

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

-ggdb

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

-gstabs

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

-gstabs+

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

-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を拡張しなければならないでしょう。

-Q

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

-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'という名前が付けられ、 圧縮は行われません。 このようなシステム上においては、 ほんの2、3秒のプロファイルであっても、 非常に大きなファイルが作成されることになります。 注意: __bb_hidecall__と__bb_showret__を使っても、 `bbtrace.gz'に出力される順序情報に変化はありません。

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

-ftest-coverage

gcovユーティリティ （gcov: テスト・カバレッジ・プログラムを参照） 用のデータ・ファイルを作成します。 データ・ファイルの名前は、 ソース・ファイルの名前で始まります。

sourcename.bb

基本ブロックから行番号へのマッピング情報です。 gcovは、 基本ブロックの実行回数を行番号に関連付けるために、 この情報を使います。

sourcename.bbg

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

-Q

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

-dletters

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

`b'

分岐の確率を計算した後に、 ファイル`file.bp'にダンプします。

`c'

命令の結合（instruction combination）の後に、 ファイル`file.combine'にダンプします。

`d'

遅延分岐スケジューリング（delayed branch scheduling）の後に、 ファイル`file.dbr'にダンプします。

`D'

前処理の終了時点で、 通常の出力に加えて、 すべてのマクロ定義をダンプします。

`r'

RTLを生成後、 ファイル`file.rtl'にダンプします。

`j'

最初のジャンプ最適化の後に、 ファイル`file.jump'にダンプします。

`F'

ADDRESSOFを除去した後に、 ファイル`file.addressof'にダンプします。

`f'

フロー解析の後に、 ファイル`file.flow'にダンプします。

`g'

広域的なレジスタの割り当ての後に、 ファイル`file.greg'にダンプします。

`G'

GCSEの後に、 ファイル`file.gcse'にダンプします。

`j'

最初のジャンプ最適化の後に、 ファイル`file.jump'にダンプします。

`J'

最後のジャンプ最適化の後に、 ファイル`file.jump2'にダンプします。

`k'

レジスタからスタックへの変換の後に、 ファイル`file.stack'にダンプします。

`l'

局所的なレジスタの割り当ての後に、 ファイル`file.lreg'にダンプします。

`L'

ループの最適化の後に、 ファイル`file.loop'にダンプします。

`M'

マシン依存の再構成パスを実行後に、 ファイル`file.mach'にダンプします。

`N'

レジスタ移動パスの後に、 ファイル`file.regmove'にダンプします。

`r'

RTLを生成後、 ファイル`file.rtl'にダンプします。

`R'

2回目の命令スケジューリングのパスの後に、 ファイル`file.sched2'にダンプします。

`s'

CSE(2)の後に、 （CSEに続いてときどき実行されるジャンプの最適化も含めて） ファイル`file.cse'にダンプします。

`S'

最初の命令スケジューリングのパスの後に、 ファイル`file.sched'にダンプします。

`t'

2回目のCSEパスの後に、 （CSEに続いてときどき実行されるジャンプの最適化も含めて） ファイル`file.cse2'にダンプします。

`a'

上記のすべてのダンプを生成します。

`m'

メモリ使用に関する統計情報を、 コンパイラ実行の最後に標準エラー出力に表示します。

`p'

どのようなパターンおよび代替パターン（alternative）が使われたかを示すコメントによって、 アセンブラの出力に注釈を加えます。 個々の命令長も表示されます。

`x'

関数をコンパイルするのではなく、 その関数のRTLだけを生成します。 通常は、 `r'とともに使われます。

`y'

パース（parse）処理の実行中に、 標準エラー出力にデバッグ情報をダンプします。

`A'

種々雑多なデバッグ情報によって、 アセンブラの出力に注釈を加えます。

-fdump-unnumbered

デバッグ情報のダンプ （上記-dオプションを参照） を行う際に、 命令番号と行番号に関する注の出力を抑止します。 これによって、 特に-gオプションを指定する場合と指定しない場合のように、 異なるオプションを指定してコンパイラを起動した場合のデバッグ情報のダンプに対するdiffの使用が、 さらにやりやすくなります。

-fpretend-float

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

-save-temps

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

-print-file-name=library

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

-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に設定することもできます。 この場合、 末尾に`/'を付けることを忘れないでください。 GCCに影響を与える環境変数を参照してください。

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

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

-O

-O1

最適化を行います。 最適化にはいくらか多くの時間がかかります。 また、 関数のサイズが大きい場合には、 かなり多くのメモリが追加的に必要になります。 `-O'が指定されないと、 コンパイル処理にかかるコストを削減することと、 デバッグ処理を行ったときに期待される結果がもたらされるようにすることが、 コンパイラの目標になります。 個々の文は独立したものとなります。 文の間にブレイクポイントを設定してプログラムを停止させると、 任意の変数に新しい値を代入したり、 プログラム・カウンタの値をその関数の中の任意の他の文に変更したりすることができ、 その際、 ソース・コードから期待されるのとまったく同じ結果を得ることができます。 `-O'が指定されないと、 コンパイラは、 register宣言された変数だけをレジスタに割り当てます。 その結果としてコンパイルされたコードは、 `-O'が指定されない場合にPCCによって生成されるコードと比べて、 少し劣るものになります。 `-O'が指定されると、 コンパイラは、 コードのサイズと実行時間を削減するよう試みます。 `-O'を指定すると、 すべてのマシン上においてコンパイラは、 `-fthread-jumps'と`-fdefer-pop'を有効にします。 また、 コンパイラは、 遅延スロット（delay slot）のあるマシン上では`-fdelayed-branch'を有効にし、 フレーム・ポインタがなくてもデバッグ処理をサポートできるマシン上では`-fomit-frame-pointer'を有効にします。 マシンによっては、 コンパイラはさらに他のフラグも有効にします。

-O2

さらに最適化を行います。 GCCは、 サポートされている最適化のうち、 サイズとスピードとのトレードオフを伴わないほとんどすべてのものを実行します。 `-O2'を指定した場合には、 コンパイラは、 ループ展開（loop unrolling）や関数のインライン展開を実行しません。 `-O'と比較すると、 このオプションにより、 コンパイル時間はさらに長くなり、 生成されるコードの性能は向上します。 `-O2'により、 ループ展開、 関数インライン展開、 厳密な別名最適化を除いて、 すべての任意選択の最適化が有効になります。 また、 すべてのマシン上において`-fforce-mem'オプションを有効にします。 さらに、 フレーム・ポインタの除去がデバッグ処理に対する妨げにならないマシン上においては、 フレーム・ポインタの除去も有効にします。

-O3

さらに一層、 最適化を行います。 `-O3'は、 `-O2'により指定されるすべての最適化を有効にした上に、 さらに`inline-functions'オプションも有効にします。

-O0

最適化を行いません。

-Os

サイズの最適化を行います。 `-Os'は、 `-O2'による最適化のうち、 コード・サイズを通常は大きくしないものすべてを有効にします。 これ以外にも、 コード・サイズを小さくするよう設計された最適化を実行します。 レベル番号の指定の有無にかかわらず、 複数の`-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宣言されているのであれば、 その関数は通常、 関数として独立したアセンブラ・コードとしては出力されません。

-finline-limit-n

デフォルトでは、 gccはインライン化可能な関数のサイズに制限を設けています。 このフラグにより、 明示的にインライン関数として指定されている関数 （inlineキーワードを持つ関数、 および、 C++においてクラス定義の内部において定義されている関数） について、 このような制限を制御することができます。 nは、 インライン化することのできる関数のサイズを、 仮想命令数を単位として示したものです （パラメータ処理の部分はカウントされません）。 nのデフォルト値は10000です。 この値を大きくすると、 コンパイルに要する時間とメモリの消費量は増大しますが、 より多くのコードをインライン化することができます。 逆にこの値を小さくすると、 通常はコンパイル処理がより高速になり、 インライン化されるコードは少なくなります （このことは、 おそらくはより遅いプログラムとなっていることを意味しているでしょう）。このオプションは、 C++における再帰的なテンプレートをベースとするプログラムのように、 インライン化を大量に使用するプログラムにおいて、 特に役に立ちます。 注:この文脈における仮想命令とは、 関数サイズの抽象的な測定値を表わしています。 これが、 アセンブラ命令の命令数を表わすことは決してなく、 したがって、 その正確な意味もリリース毎に変わってくる可能性があります。

-fkeep-inline-functions

ある与えられた関数が、 呼び出されているすべての箇所において統合（インライン展開）され、 かつ、 static宣言されている場合でも、 実行時に呼び出すことが可能な独立した関数として出力します。 このフラグは、 extern inlineとして宣言されている関数には影響を与えません。

-fkeep-static-consts

最適化が行われていない場合には、 static const宣言された変数を、 たとえその変数が参照されていなくても、 出力します。 GCCは、 このオプションをデフォルトで有効にします。 最適化が行われているか否かにかかわらず、 その変数が参照されていることをコンパイラに強制的にチェックさせたいのであれば、 `-fno-keep-static-consts'オプションを使ってください。

-fno-function-cse

レジスタに関数アドレスを入れません。 ある決まった関数を呼び出す個々の命令に、 その関数のアドレスを明示的に持たせます。 このオプションを使うと、 効率の劣るコードが生成されますが、 アセンブラ出力を変更するような奇妙な技巧の中には、 このオプションを使わずに実行された最適化によって混乱を引き起こされるものもあるかもしれません。

-ffast-math

このオプションは、 スピードの向上を目的とするコードの最適化を行うために、 GCCがANSIやIEEEの規則や仕様のいくつかに違反することを許します。 例えば、 コンパイラが、 sqrt関数への引数は非負の数であると想定したり、 すべての浮動小数点値は非数（NaNs）(3)ではないと想定したりすることを許します。 どの`-O'オプションも、 決してこのオプションを有効にするべきではありません。 というのは、 このオプションは、 数学関数に対するIEEEやANSIの規則や仕様の厳密な実装に依存するプログラムにとっては、 正しくない出力を生成する結果になる可能性があるからです。

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

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

-fstrength-reduce

ループ強度（loop strength）の削減と反復変数の除去による最適化を実行します。

-fthread-jumps

比較によるジャンプの分岐先において、 最初の比較に包含されるような別の比較があるかどうかをチェックすることにより、 最適化を実行します。 最初の比較が2番目の比較を包含するのであれば、 2番目の比較の条件式が真偽いずれであるかが分かっているような場合には、 真であれば、 最初の分岐命令の分岐先を2番目の分岐命令の分岐先に、 偽であれば、 最初の分岐命令の分岐先を2番目の分岐命令の直後に、 変更します。

-fcse-follow-jumps

共通部分式の除去において、 ジャンプ命令のジャンプ先がそのジャンプ命令以外のパスからは到達されない場合、 そのジャンプ命令のジャンプ先を調べます。 例えば、 CSE(4)がelse節を持つif文を見つけると、 CSEは、 テストされる条件式が偽である場合のジャンプを追跡します。

-fcse-skip-blocks

これは`-fcse-follow-jumps'と似ていますが、 条件に応じてブロックをスキップするジャンプをCSEに追跡させます。 `-fcse-skip-blocks'は、 else節を持たない単純なif文をCSEが見つけた場合に、 CSEにifの本体（body）を飛び越すジャンプを追跡させます。

-frerun-cse-after-loop

ループ最適化の実行後に再度、 共通部分式の除去を実行します。

-frerun-loop-opt

ループ最適化を2回実行します。

-fgcse

広域的な共通部分式除去のパスを実行します。 このパスは、 広域的な定数伝播とコピー伝播（global constant and copy propagation）も実行します。

-fexpensive-optimizations

相対的にコストのかかる、 重要ではない最適化をいくつか実行します。

-foptimize-register-moves

-fregmove

move命令、 および、 その他の単純な命令におけるオペランドにおいて、 レジスタとの結合を最大化するために、 レジスタ番号の再割り当てを試みます。 これは、 オペランドを2つとる命令を持つマシンにおいて特に役に立ちます。 GCCは、 `-O2'以上の最適化においてデフォルトでこの最適化を有効にします。 -fregmoveと-foptimize-register-movesは同じ最適化であることに注意してください。

-fdelayed-branch

命令の実行順序を変更することがターゲット・マシンでサポートされていれば、 遅延分岐命令の後に利用可能な命令スロットを活用するために、 命令の実行順序の変更を試みます。

-fschedule-insns

命令の実行順序を変更することがターゲット・マシンでサポートされていれば、 必要なデータが利用できるようになっていないために発生する実行の一時的停止を除去するために、 命令の実行順序の変更を試みます。 速度の遅い浮動小数点命令やメモリ・ロード命令を持つマシンでは、 ロード命令や浮動小数点命令の結果が必要になるまでの間、 他の命令を実行することができるようにすることによって、 これが役に立ちます。

-fschedule-insns2

`-fschedule-insns'と似ていますが、 レジスタの割り当てが行われた後に、 追加的に命令スケジューリングのパスの実行を要求します。 レジスタの数が比較的少なく、 メモリ・ロード命令が複数サイクルを要するマシン上において、 これは特に役に立ちます。

-ffunction-sections

-fdata-sections

任意のセクションを自由に選択することがターゲット・マシンによりサポートされていれば、 出力ファイルの中において個々の関数やデータ項目を別個のセクションに置きます。 関数の名前やデータ項目の名前が、 出力ファイルの中におけるセクションの名前を決定します。 これらのオプションは、 命令空間（instruction space）において参照の範囲を改善するための最適化をリンカが実行することができるようなシステム上において使ってください。 HPPAプロセッサ上のHP-UXとSparcプロセッサ上のSolaris 2には、 このような最適化を行うリンカがあります。 AIX、 および、 ELFオブジェクト形式を使う他のシステムも、 将来このような最適化を行うようになるかもしれません。 このオプションは、 それを使うことによって重大な利益が得られる場合にのみ使うようにしてください。 このオプションを指定すると、 アセンブラとリンカが生成するオブジェクト・ファイルと実行ファイルのサイズが大きくなります。 また、 アセンブラとリンカの実行速度も遅くなります。 このオプションを指定すると、 すべてのシステム上において、 gprofを使うことができなくなります。 また、 このオプションと`-g'をともに指定すると、 デバッグ処理に問題の出る可能性があります。

-fcaller-saves

関数呼び出しによって内容の破壊されるレジスタの中に値を割り当てることができるようにします。 これは、 そのような関数呼び出しの前後に、 レジスタの待避と復元を行う余分の命令を出力することにより実現されます。 このような割り当てが行われるのは、 それを行わない場合に生成されるコードよりも、 それを行った場合に生成されるコードの方が、 結果的により良いものになるように見える場合だけです。 このオプションは、 特定のマシンにおいては常にデフォルトで有効になっています。 ここでいう特定のマシンとは、 代替手段として使うことのできる、 関数呼び出し時に内容が保存されるレジスタ（call-preserved register）を持たないマシンのことです。 すべてのマシンにおいて、 レベル2以上の最適化が指定されている場合には、 このフラグはデフォルトで有効になります。

-funroll-loops

ループ展開（loop unrolling）による最適化を実行します。 コンパイル時、 もしくは、 実行時に反復回数が決定できるループに対してのみ、 この最適化は実行されます。 `-funroll-loops'は暗黙のうちに、 `-fstrength-reduce'と`-frerun-cse-after-loop'の両方を指定します。

-funroll-all-loops

ループ展開（loop unrolling）による最適化を実行します。 これは、 すべてのループに対して実行され、 通常、 プログラムの実行速度はより遅くなります。 `-funroll-all-loops'は暗黙のうちに、 `-frerun-cse-after-loop'のほかに`-fstrength-reduce'も指定します。

-fmove-all-movables

ループ内部における計算のうち結果が不変のものすべてを、 ループの外に強制的に移動します。

-freduce-all-givs

ループ内部にあるすべての汎用帰納変数（general-induction variable）の強度を削減します（strength-reduced）。 注: Fortranで記述されたプログラムをコンパイルする際には、 最適化を行うと`-fmove-all-movables'と`-freduce-all-givs'がデフォルトで有効になります。 これらのオプションを使用することで、 コードの質が良くなることもありますが、 悪くなることもあります。 結果は、 ソース・コードの中にあるループの構造に大きく依存します。 これら2つのオプションは、 将来、 ループの最適化を改善するためのいくつかの方法の効率性を決定するのに役立つ情報が収集できれば、 削除することを考えています。 これらのオプションを使うことによって、 実際に運用されるコードの性能がどのように影響を受けたかを、 私たち （gcc@gcc.gnu.orgとfortran@gnu.org） に教えてください。 これらのオプションが有効なときに実行速度が遅くなるコードに非常に興味があります。

-fno-peephole

マシン固有のピープホール（peephole）の最適化をすべて無効にします。

-fbranch-probabilities

`-fprofile-arcs' （ユーザ・プログラムまたはGCCをデバッグするためのオプションを参照） を指定してコンパイルしたプログラムを実行後、 分岐命令が取るであろうパスの推測に基づいて最適化を改善するために、 そのプログラムを`-fbranch-probabilities'を指定して再度コンパイルすることができます。 `-fbranch-probabilities'が指定されると、 GCCは、 個々の基本ブロックの最初の命令に`REG_EXEC_COUNT'ノート（note）を記し、 個々の`JUMP_INSN'と`CALL_INSN'に`REG_BR_PROB'ノートを記します。 これらは、 最適化を改善するために使うことができます。 現在のところ、 これらはただ1個所でのみ使われています。 それは、 ファイル`reorg.c'の中です。 ある分岐命令が主にどのパスを取るかを推測する代わりに、 どのパスが最も多く取られるかを正確に決定するために、 `REG_BR_PROB'の値が使われます。

-fstrict-aliasing

コンパイルされている言語に適用可能な別名規則（aliasing rule）のうち最も厳密なものをコンパイラが前提することを許します。 これによって、 C（およびC++）では式の型に基く最適化を動作させることになります。 例えば、 ある型のオブジェクトが別の型のオブジェクトと同一アドレスに位置することは、 それら2つの型がほとんど同一でない限り、 ないものと仮定されます。 例えば、 unsigned intがintの別名となることはあっても、 void*やdoubleの別名となることはありえません。 また、 文字型は他の任意の型の別名になりえます。 以下のようなコードに特に注意してください。

union a_union { 
  int i;
  double d;
};

int f() {
  a_union t;
  t.d = 3.0;
  return t.i;
}

最後に書き込みが行われた共用体メンバとは異なるメンバから読み込みを行う習慣 （「type-punning」と呼ばれる） は一般的に見られます。 `-fstrict-aliasing'を指定した場合でも、 メモリが共用体型を通してアクセスされる場合には、 type-punningは許されます。 したがって、 上記のようなコードは期待通りに動作します。 しかし、 以下のコードは期待通りに動作しないかもしれません。

int f() { 
  a_union t;
  int* ip;
  t.d = 3.0;
  ip = &t.i;
  return *ip;
}

言語固有の別名解析が実行されることを期待する言語は、 treeノードを渡されるとそのノードに対する別名集合を計算する関数を定義しなければなりません。 異なる別名集合に属するノードは別名となることが許されません。 1つの例として、 Cのフロント・エンド関数であるc_get_alias_setを参照してみてください。

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

以下のオプションは、 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を第2のインクルード・パスに追加します。 第2のインクルード・パスに含まれるディレクトリは、 あるヘッダ・ファイルがメイン・インクルード・パス （`-I'オプションはここにディレクトリを追加します） に含まれるどのディレクトリの中にも見つからない場合に探索されます。

-iprefix prefix

後続の`-iwithprefix'オプションのための接頭語としてprefixを指定します。

-iwithprefix dir

ディレクトリを第2のインクルード・パスに追加します。 ディレクトリの名前は、 事前に`-iprefix'により指定された接頭語prefixとdirを連結することによって作られます。 接頭語が事前に指定されていない場合には、 コンパイラがインストールされたディレクトリがデフォルトの接頭語として使われます。

-iwithprefixbefore dir

メイン・インクルード・パスにディレクトリを追加します。 `-iwithprefix'の場合と同様、 ディレクトリの名前は、 prefixとdirを連結することによって作られます。

-isystem dir

ディレクトリを第2のインクルード・パスの先頭に追加し、 標準のシステム・ディレクトリに適用されるのと同等の特殊な取り扱いを受けられるようにするために、 システム・ディレクトリとしてマークします。

-nostdinc

ヘッダ・ファイルを探す際に、 標準のシステム・ディレクトリを探索しません。 `-I'オプションにより指定されたディレクトリ （および、 カレント・ディレクトリを探索することが適切である場合には、 カレント・ディレクトリ） だけが探索されます。 `-I'に関する情報については、 ディレクトリ探索のためのオプションを参照してください。 `-nostdinc'と`-I-'を両方使用することにより、 インクルード・ファイルの探索パスを、 明示的に指定したディレクトリだけに限定することができます。

-undef

（アーキテクチャ・フラグも含めて） 非標準のマクロを事前定義しません。

-E

Cプリプロセッサだけを実行します。 指定されたすべてのCソース・ファイルを前処理して、 その結果を標準出力、 もしくは、 指定された出力ファイルに出力します。

-C

プリプロセッサに対して、 コメントを破棄しないよう指示します。 `-E'オプションとともに使います。

-P

プリプロセッサに対して、 `#line'指示子を生成しないよう指示します。 `-E'オプションとともに使います。

-M

プリプロセッサに対して、 makeコマンドで使うのに適した、 個々のオブジェクト・ファイルの依存関係を記述したルール情報を出力するよう指示します。 プリプロセッサは、 個々のソース・ファイルに対して、 そのソース・ファイルに対応するオブジェクト・ファイル名が依存関係のターゲットであり、 そのソース・ファイルが#includeにより取り込むすべてのヘッダ・ファイルが依存関係のソースであるようなmakeルールを出力します。(5) このルールは単一行の場合もありますが、 長い場合には、 改行の直前に`\'を置くことにより複数行に継続することもあります。 ルールの一覧は、 前処理されたCプログラムの中にではなく、 標準出力に表示されます。 `-M'は暗黙のうちに`-E'を指定します。 makeルールを出力するよう指定する別の方法に、 環境変数DEPENDENCIES_OUTPUT （GCCに影響を与える環境変数を参照） を設定する方法があります。

-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を診断します。 `-A-'は、 通常であればターゲット・マシンを記述する標準の診断を、 使用不可とします。

-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の3文字表記をサポートします。 `-ansi'オプションも同一の効果を持ちます。

-Wp,option

optionをプリプロセッサへのオプションとして渡します。 optionにカンマが含まれる場合は、 カンマの位置で分割されて複数のオプションとして渡されます。

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

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

-Wa,option

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

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

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

object-file-name

特別に認識される接尾語で終わらないファイル名は、 オブジェクト・ファイルの名前、 もしくは、 ライブラリの名前とみなされます （オブジェクト・ファイルとライブラリとの区別は、 ファイルの内容によってリンカが行います）。 リンク処理が行われる場合、 これらのオブジェクト・ファイルはリンカへの入力として使われます。

-c

-S

-E

これらのオプションのうちのどれかが使われると、 リンカは実行されません。 これらを使う場合は、 オブジェクト・ファイル名を引数として使ってはなりません。 出力の種類を制御するオプションを参照してください。

-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 が使われない限り、 通常は使用されます。 コンパイラが、 System V （およびANSI C） 環境においてmemcmp、 memset、 memcpyに対する呼び出しを生成すること、 また、 BSD環境においてbcopyやbzeroに対する呼び出しを生成することがあるかもしれません。 これらのエントリは、 通常はlibcのエントリによって解決されます。 このオプションが指定された場合には、 これらのエントリ・ポイントは、 何らかの別の機構によって提供されなければなりません。

-nostdlib

リンク時に標準システム・スタートアップ・ファイルや標準システム・ライブラリを使用しません。 スタートアップ・ファイルは一切リンカに渡されません。 指定されたライブラリだけがリンカに渡されます。 コンパイラが、 System V （およびANSI C） 環境においてmemcmp、 memset、 memcpyに対する呼び出しを生成すること、 また、 BSD環境においてbcopyやbzeroに対する呼び出しを生成することがあるかもしれません。 これらのエントリは、 通常はlibcのエントリによって解決されます。 このオプションが指定された場合には、 これらのエントリ・ポイントは、 何らかの別の機構によって提供されなければなりません。 `-nostdlib'と`-nodefaultlibs'によって使用されなくなる標準ライブラリの1つに`libgcc.a'があります。 これは、 特定のマシンの欠点を克服したり、 いくつかの言語の特殊な必要を満足したりするために、 GCC が使用する内部的なサブルーチンのライブラリです （`libgcc.a'の詳細については、 GCCの出力とのインターフェイスを参照してください）。 ほとんどの場合、 他の標準ライブラリの使用は避けたいような場合であっても、 `libgcc.a'は必要です。 言い換えると、 `-nostdlib'や`-nodefaultlibs'を指定する場合には、 通常は`-lgcc'もあわせて指定するべきです。 これにより、 内部的なGCCライブラリ・サブルーチンに対する未解決の参照が存在しないことが確実になります （例えば、 C++の生成関数が呼び出されることを確実にするために使われる`__main'への参照など。 collect2を参照）。

-s

実行可能ファイルからすべてのシンボル・テーブルと再配置情報を削除します。

-static

このオプションは、 ダイナミック・リンクをサポートするシステム上において、 共用ライブラリとのリンクを行わないようにします。 その他のシステム上では、 このオプションには何の効果もありません。

-shared

後に他のオブジェクトとリンクして実行可能ファイルを作成することのできる共用オブジェクトを作成します。 すべてのシステム上においてこのオプションがサポートされているわけではありません。 いくつかのシステムにおいては、 このオプションを指定するときに、 `-fpic'か`-fPIC'をあわせて指定しなければなりません。

-symbolic

共用オブジェクトをビルドする際に、 広域シンボルへの参照を結合（bind）します。 （リンク・エディタ・オプション`-Xlinker -z -Xlinker defs'によって無効にされない限り） 未解決の参照について警告を出力します。 このオプションをサポートしているシステムは極めてわずかです。

-Xlinker option

optionをリンカへのオプションとして渡します。 このオプションを使って、 GCCが認識する術を持たないシステム固有のリンカ・オプションを与えることができます。 引数を取るオプションを渡したいのであれば、 `-Xlinker'を2回使わなければなりません。 1回目はオプションを指定するため、 2回目は引数を指定するためです。 例えば、 `-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'を1つ以上実行します。 コンパイラ・ドライバ・プログラムは、 実行しようとする個々のプログラムの名前の接頭語として、 `machine/version/'を付加したprefixと`machine/version/'を付加しないprefixの両方を試しに使ってみます （ターゲット・マシンとコンパイラ・バージョンの指定を参照）。 `-B'が指定されている場合には、 コンパイラ・ドライバは、 実行される個々のサブプログラムについて、 まず`-B'により指定されている接頭語を試します。 そのファイル名のファイルが見つからない場合、 あるいは、 `-B'が指定されていない場合、 ドライバは2つの標準接頭語を試します。 それらは、 `/usr/lib/gcc/'と`/usr/local/lib/gcc-lib/'です。 これらを使ったファイル名のファイルがいずれも見つからない場合には、 `PATH'環境変数に指定されているディレクトリを使って、 何の変更も加えないプログラム名でファイルを探します。 ディレクトリ名を指定する`-B'の接頭語は、 リンカにおけるライブラリ名にも適用されます。 コンパイラがこのオプションを使ってリンカ用の`-L'オプションを作成するからです。 また、 コンパイラがこのオプションを使ってプリプロセッサ用の`-isystem'オプションを作成するので、 同じ接頭語が、 プリプロセッサにおけるインクルード・ファイル名にも適用されます。 この場合、 コンパイラは、 接頭語の後ろに`include'を付加します。 必要であれば、 実行時サポート・ファイル`libgcc.a'もまた、 `-B'の接頭語を使って探すことができます。 そのファイル名ではファイルが見つからない場合には、 上記の2つの標準接頭語が試され、 それ以外の試みは行われません。 これら2つの名前によってもファイルが見つからない場合には、 このファイルはリンクの対象外となります。 `-B'による接頭語とほぼ同様の接頭語を指定する別の方法に、 環境変数GCC_EXEC_PREFIXを使うという方法があります。 GCCに影響を与える環境変数を参照してください。

-specs=file

コンパイラが標準の`specs'ファイルを読み込んだあとで、 fileを処理します。 その目的は、 `gcc'ドライバ・プログラムが`cc1'、 `cc1plus'、 `as'、 `ld'等に渡すオプションを決定する際に使うデフォルトの設定を無効にすることです。 コマンドライン上において複数の`-specs='fileを指定することができ、 その場合、 左から右の順序で処理されます。

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

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

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

-b machine

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

-V version

引数versionは実行すべきGCCのバージョンを指定します。 これは、 異なるバージョンのGCCが複数インストールされている場合に役に立ちます。 例えば、 versionに`2.0'を指定すると、 バージョン 2.0のGCCを実行することになります。 `-V'が指定されない場合のデフォルトのバージョンは、 最後にインストールされたGCCのバージョンになります。

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

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

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

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

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

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

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

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

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

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

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

M680x0オプション

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

-m68000

-mc68000

68000用の出力を生成します。 これは、 68000ベースのシステム用のコンフィギュレーションがコンパイラに対して行われた場合のデフォルトです。 このオプションは、 68008、 68302、 68306、 68307、 68322、 68328、 68356などの、 68000またはEC000コアを持つマイクロコントローラに対して使ってください。

-m68020

-mc68020

68020用の出力を生成します。 これは、 68020ベースのシステム用のコンフィギュレーションがコンパイラに対して行われた場合のデフォルトです。

-m68881

浮動小数点を処理するための68881の命令を含む出力を生成します。 これは、 コンパイラのコンフィギュレーションが行われた際に`-nfp'が指定されていなければ、 ほとんどの68020システムに対するデフォルトとなります。

-m68030

68030用の出力を生成します。 これは、 68030ベースのシステム用のコンフィギュレーションがコンパイラに対して行われた場合のデフォルトです。

-m68040

68040用の出力を生成します。 これは、 68040ベースのシステム用のコンフィギュレーションがコンパイラに対して行われた場合のデフォルトです。 このオプションは、 68040上においてはソフトウェアによってエミュレートしなければならない68881/68882命令の使用を禁止します。 使用している68040にこれらの命令をエミュレートするコードが存在しない場合は、 このオプションを使ってください。

-m68060

68060用の出力を生成します。 これは、 68060ベースのシステム用のコンフィギュレーションがコンパイラに対して行われた場合のデフォルトです。 このオプションは、 68060上においてはソフトウェアによってエミュレートしなければならない68020命令と68881/68882命令の使用を禁止します。 使用している68060にこれらの命令をエミュレートするコードが存在しない場合は、 このオプションを使ってください。

-mcpu32

CPU32用の出力を生成します。 これは、 CPU32ベースのシステム用のコンフィギュレーションがコンパイラに対して行われた場合のデフォルトです。 このオプションは、 68330、 68331、 68332、 68333、 68334、 68336、 68340、 68341、 68349、 68360などの、 CPU32またはCPU32+コアを持つマイクロコントローラに対して使ってください。

-m5200

520X "coldfire"ファミリのCPU用の出力を生成します。 これは、 520Xベースのシステム用のコンフィギュレーションがコンパイラに対して行われた場合のデフォルトです。 このオプションは、 MCF5202、 MCF5203、 MCF5204、 MCF5202などの、 5200コアを持つマイクロコントローラに対して使ってください。

-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'、 `-mcpu32'、 `-m5200'の各オプションは暗黙のうちに`-mnobitfield'を指定します。

-mbitfield

ビット・フィールド命令を使います。 `-m68020'オプションは暗黙のうちに`-mbitfield'を指定します。 68020用に設計されたコンフィギュレーションを使うと、 これがデフォルトになります。

-mrtd

異なる関数呼び出し規約を使います。 この関数呼び出し規約では、 引数の数が固定である関数は、 復帰の際に引数をポップするrtd命令を使って呼び出し元に復帰します。 これにより呼び出し元では、 引数をポップする必要がなくなるので、 命令を1つ節約することができます。 この呼び出し規約は、 通常UNIX上において使われる呼び出し規約とは互換性がありません。 したがって、 UNIXのコンパイラによりコンパイルされたライブラリを呼び出す必要がある場合には、 これを使うことはできません。 また、 （printfも含めて） 可変個数の引数を取るすべての関数について関数プロトタイプを提供しなければなりません。 さもないと、 これらの関数が呼び出されているところで、 正しくないコードが生成されることになります。 さらに、 関数の呼び出しに際して引数の数が多すぎると、 深刻な問題を持つコードが生成されてしまいます （通常であれば、 余分な引数は実害なく無視されます）。 rtd 命令は、 68010、 68020、 68030、 68040、 68060、 CPU32の各プロセッサによりサポートされていますが、 68000や5200ではサポートされていません。

-malign-int

-mno-align-int

GCCによる int、 long、 long long、 float、 double、 long double のそれぞれの型の変数の境界整列を、 32ビット境界 （`-malign-int'） にするか、 16ビット境界 （`-mno-align-int'） にするかを制御します。 変数を32ビット境界に境界整列させると、 生成されるコードはより多くのメモリを消費するようになりますが、 32ビットのバスを持つプロセッサ上ではいくらか高速に実行されるようになります。 注意: `-malign-int'オプションを使うと、 GCCは、 上記の型を含む構造体については、 出版されている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'は、 出力ファイルの中における呼び出し規約を変更します。 したがって、 プログラム全体をこのオプションを使ってコンパイルする場合にしか役に立ちません。 このオプションが機能するようにするためには、 特に、 GCCに付属しているライブラリである`libgcc.a'を`-msoft-float'を指定してコンパイルする必要があります。

-mhard-quad-float

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

-msoft-quad-float

4ワード （long double） の浮動小数点命令を実現するライブラリ呼び出しを含む出力を生成します。 呼び出される関数群は、 SPARC ABIにおいて指定されているものです。 これがデフォルトです。 これを書いている時点では、 4ワードの浮動小数点命令に対するハードウェア・サポートを持つ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'が指定されると、 GCCは、 別の型の中に含まれる場合や絶対アドレスが指定されている場合のみ、 double型は8バイト単位に境界整列されると想定します。 これら以外の場合には、 4バイト単位の境界整列を持つものと想定します。 このオプションを指定することにより、 他のコンパイラにより生成されたコードとの組み合わせで稀に発生するいくつかの互換性の問題を回避することができます。 特に浮動小数点関連のコードで性能の劣化が引き起こされるために、 このオプションはデフォルトにはなっていません。

-mv8

-msparclite

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

-mcypress

-msupersparc

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

-mcpu=cpu_type

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

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

-mtune=cpu_type

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

-mstack-bias

-mno-stack-bias

`-mstack-bias'が指定されると、 GCCは、 スタック・ポインタが-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

個々の引数リストの1つ前のワード領域に引数の個数を入れるコードを生成します。 これは普通の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命令を使います。 1つのファイルをコンパイルすると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

浮動小数点を処理するためのライブラリ呼び出しを含む出力を生成します。 注意: 必要となるライブラリはGCCには含まれていません。 通常、 そのマシンにおいて通常使われるCコンパイラのライブラリが利用されますが、 これはクロス・コンパイル環境では直接使うことができません。 クロス・コンパイルを行う場合は、 適切なライブラリ関数群を提供するための準備を自分で行わなければなりません。

-mno-multm

multm命令やmultmu命令を生成しません。 これは、 これらの命令に対するトラップ・ハンドラを持たない組み込みシステムにおいて役に立ちます。

ARMオプション

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

-mapcs-frame

コードを正しく実行するために厳密には必要ではない場合でも、 すべての関数に対して、 ARM Procedure Call Standardと互換性のあるスタック・フレームを生成します。 このオプションとともに`-fomit-frame-pointer'を指定すると、 リーフ関数（leaf function）に対してスタック・フレームは生成されなくなります。 デフォルトは`-mno-apcs-frame'です。

-mapcs

これは`-mapcs-frame'と同義です。

-mapcs-26

26ビットのプログラム・カウンタを使って動作し、 かつ、 APCS 26ビット・オプションの関数呼び出し標準に準拠するプロセッサ用のコードを生成します。 このオプションは、 このコンパイラの以前のリリースにおける`-m2'オプションと`-m3'オプションに代わるものです。

-mapcs-32

32ビットのプログラム・カウンタを使って動作し、 かつ、 APCS 32ビット・オプションの関数呼び出し標準に準拠するプロセッサ用のコードを生成します。 このオプションは、 このコンパイラの以前のリリースにおける`-m6'オプションに代わるものです。

-mapcs-stack-check

個々の （スタック空間を実際に使用する） 関数の中に入った時点において利用可能なスタック空間のサイズをチェックするコードを生成します。 利用可能なサイズが十分でない場合は、 必要とされるスタック空間の大きさに応じて、 関数`__rt_stkovf_split_small'または関数`__rt_stkovf_split_big'が呼び出されます。 これらの関数を提供するランタイム・システムが必要となります。 生成されるコードのサイズが小さくなるため、 デフォルトは`-mno-apcs-stack-check'です。

-mapcs-float

浮動小数点引数は浮動小数点レジスタを使って渡します。 これはAPCSの変種の1つです。 ターゲット・ハードウェアが浮動小数点ユニットを持っている場合、 または、 コードによって大量の浮動小数点演算が実行される場合には、 このオプションを指定することをお勧めします。 `-mapcs-float'を使うと、 整数のみを使うコードのサイズが若干大きくなるため、 デフォルトは`-mno-apcs-float'になっています。

-mapcs-reentrant

再入可能で、 かつ、 位置非依存（position independent）なコードを生成します。 これは、 `-fpic'オプションを指定するのと同じことです。 デフォルトは`-mno-apcs-reentrant'です。

-mthumb-interwork

ARM命令セットを使うコードとTHUMB命令セットを使うコードの間での呼び出しをサポートするコードを生成します。 このオプションを指定しないと、 これら2つの命令セットを1つのプログラムの中で安定して使うことはできません。 `-mthumb-interwork'が指定されると若干サイズの大きいコードが生成されるため、 デフォルトは`-mno-thumb-interwork'となっています。

-mno-sched-prolog

関数プロローグの内部における命令の順序変更が行われないようにします。 あるいは、 これらの命令が関数本体の命令と統合されることがないようにします。 このことはすべての関数が、 ある識別可能な命令集合 （実際には、 少数の異なる関数プロローグの選択肢の中から選択されたもの） から開始されることを意味しています。 この情報は、 ある実行可能なコード部分の中に関数がある場合に、 その先頭を発見するのに使うことができます。 デフォルトは`-msched-prolog'です。

-mhard-float

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

-msoft-float

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

-mlittle-endian

リトル・エンディアン・モードで動作しているプロセッサ用のコードを生成します。 これは、 すべての標準的なコンフィギュレーションのデフォルトです。

-mbig-endian

ビッグ・エンディアン・モードで動作しているプロセッサ用のコードを生成します。 デフォルトでは、 リトル・エンディアン・モードのプロセッサ用にコードをコンパイルします。

-mwords-little-endian

このオプションは、 ビッグ・エンディアンのプロセッサ用にコードを生成している場合にのみ当てはまります。 ワード・オーダはリトル・エンディアンで、 しかし、 バイト・オーダはビッグ・エンディアンでコードを生成します。 これはすなわち、 `32107654'という形式のバイト・オーダとなります。 注: このオプションは、 バージョン2.8よりも前のコンパイラによって生成された、 ビッグ・エンディアンのARMプロセッサ用のコードとの互換性が必要である場合にのみ、 使われるべきものです。

-mshort-load-bytes

半ワード （例えば`short'） をロードするために、 境界整列されていないアドレスから1ワードをロードしようと試みません。 ターゲットによっては、 境界整列されていない箇所からのロードをトラップするようMMUが設定されていることがあります。 このような環境でも安全なコードを生成するには、 このオプションを使ってください。

-mno-short-load-bytes

半ワード （例えば`short'） をロードするのに、 境界整列されていないワードのロードを使います。 このオプションは、 より効率的なコードを生成しますが、 ときにはMMUがこのような命令をトラップするよう設定されていることがあります。

-mshort-load-words

これは`-mno-short-load-bytes'と同義です。

-mno-short-load-words

これは`-mshort-load-bytes'と同義です。

-mbsd

このオプションは、 RISC iXにのみ当てはまります。 ネイティブなBSDモードのコンパイラをエミュレートします。 `-ansi'が指定されていないと、 これがデフォルトになります。

-mxopen

このオプションは、 RISC iXにのみ当てはまります。 ネイティブなX/Openモードのコンパイラをエミュレートします。

-mno-symrename

このオプションは、 RISC iXにのみ当てはまります。 コードがアセンブルされた後に、 アセンブラのポストプロセッサ`symrename'を実行しません。 通常は、 RISC iXのCライブラリとリンクするための準備として、 標準シンボルのいくつかを修正する必要があります。 このオプションによって、 このパスは実行されなくなります。 このポストプロセッサは、 コンパイラがクロス・コンパイル用としてビルドされている場合には、 決して実行されません。

-mcpu=<name>

-mtune=<name>

ターゲットとなるARMプロセッサの名前を指定します。 GCCは、 アセンブラ・コードを生成する際に使うことのできる命令の種類を決定するために、 この名前を使います。 許される名前は、 arm2、 arm250、 arm3、 arm6、 arm60、 arm600、 arm610、 arm620、 arm7、 arm7m、 arm7d、 arm7dm、 arm7di、 arm7dmi、 arm70、 arm700、 arm700i、 arm710、 arm710c、 arm7100、 arm7500、 arm7500fe、 arm7tdmi、 arm8、 strongarm、 strongarm110、 strongarm1100、 arm8、 arm810、 arm9、 arm9tdmiです。 `-mtune='は、 旧バージョンのGCCをサポートするためにある、 `-mcpue='の同義オプションです。

-march=<name>

ターゲットとなるARMアーキテクチャの名前を指定します。 GCCは、 アセンブラ・コードを生成する際に使うことのできる命令の種類を決定するために、 この名前を使います。 このオプションは、 `-mcpu='オプションとともに使うこともできますし、 `-mcpu='オプションの代わりに使うこともできます。 許される名前は、 armv2、 armv2a、 armv3、 armv3m、 armv4、 armv4tです。

-mfpe=<number>

-mfp=<number>

ターゲット上で利用可能な浮動小数点エミュレーションのバージョンを指定します。 許される値は2と3です。 `-mfp='は、 旧バージョンのGCCをサポートするためにある、 `-mfpe='の同義オプションです。

-mstructure-size-boundary=<n>

すべての構造体および共用体のサイズは、 このオプションによってセットされるビット数の倍数に丸められます。 許される値は8と32です。 デフォルトの値は、 ツールチェイン（toolchain）によって異なります。 COFFをターゲットとするツールチェインではデフォルト値は8です。 大きい値を指定するほど、 高速で効率の良いコードが生成されますが、 プログラムのサイズは大きくなってしまう可能性があります。 上記の2つの値は潜在的には互換性がありません。 一方の値を指定してコンパイルされたコードと他方の値を指定してコンパイルされたコードやライブラリとの組み合わせは、 両者が構造体や共用体を使って情報の交換を行うのであれば、 うまく動作すると期待することは必ずしもできません。 将来のバージョンのツールチェインのデフォルト値は32となる可能性がありますので、 プログラマは32という値を使うことが推奨されます。

-mabort-on-noreturn

noreturn指定された関数の末尾にabort関数への呼び出しコードを生成します。 関数がreturnを試みると、 このコードが実行されます。

Thumbオプション

-mthumb-interwork

THUMB命令セットとARM命令セットの間での呼び出しをサポートするコードを生成します。 このオプションを指定しないと、 これら2つの命令セットを1つのプログラムの中で安定して使うことはできません。 `-mno-thumb-interwork'を指定すると若干サイズの小さいコードが生成されるため、 デフォルトは`-mno-thumb-interwork'となっています。

-mtpcs-frame

リーフ関数以外のすべての関数について、 Thumb Procedure Call標準に準拠したスタック・フレームを生成します （リーフ関数とは、 他の関数を一切呼び出さない関数を指します）。 デフォルトは`-mno-tpcs-frame'(7)です。

-mtpcs-leaf-frame

すべてのリーフ関数について、 Thumb Procedure Call標準に準拠したスタック・フレームを生成します （リーフ関数とは、 他の関数を一切呼び出さない関数を指します）。 デフォルトは`-mno-tpcs-leaf-frame'(8)です。

-mlittle-endian

リトル・エンディアン・モードで動作しているプロセッサ用のコードを生成します。 これは、 すべての標準的なコンフィギュレーションのデフォルトです。

-mbig-endian

ビッグ・エンディアン・モードで動作しているプロセッサ用のコードを生成します。

-mstructure-size-boundary=<n>

すべての構造体および共用体のサイズは、 このオプションによってセットされるビット数の倍数に丸められます。 許される値は8と32です。 デフォルトの値は、 ツールチェイン（toolchain）によって異なります。 COFFをターゲットとするツールチェインではデフォルト値は8です。 大きい値を指定するほど、 高速で効率の良いコードが生成されますが、 プログラムのサイズは大きくなってしまう可能性があります。 上記の2つの値は潜在的には互換性がありません。 一方の値を指定してコンパイルされたコードと他方の値を指定してコンパイルされたコードやライブラリとの組み合わせは、 両者が構造体や共用体を使って情報の交換を行うのであれば、 うまく動作すると期待することは必ずしもできません。 将来のバージョンのツールチェインのデフォルト値は32となる可能性がありますので、 プログラマは32という値を使うことが推奨されます。

MN10200オプション

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

-mrelax

分岐、 呼び出し、 および、 絶対メモリ・アドレスのサイズを小さくするために、 緩和最適化パス（relaxation optimization pass）を実行するべきであることをリンカに示唆します。 このオプションは、 最終リンク段階に対してコマンドラインから指定された場合にのみ効果を持ちます。 このオプションを使うと、 シンボリック・デバッグはできなくなります。

MN10300オプション

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

-mmult-bug

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

-mno-mult-bug

MN10300プロセッサの乗算命令のバグを回避するコードを生成しません。

-mrelax

分岐、 呼び出し、 および、 絶対メモリ・アドレスのサイズを小さくするために、 緩和最適化パス（relaxation optimization pass）を実行するべきであることをリンカに示唆します。 このオプションは、 最終リンク段階に対してコマンドラインから指定された場合にのみ効果を持ちます。 このオプションを使うと、 シンボリック・デバッグはできなくなります。

M32R/Dオプション

以下の`-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'のいずれか1つの中に置かれます。 これがデフォルトです。 スモール・データ域は、 `.sdata'セクションと`.sbss'セクションから構成されます。 section属性にこれらのセクションの1つを指定することにより、 オブジェクトを明示的にスモール・データ域に置くことができます。

-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の仕様に従います。 デフォルトでは、 GCCは引数領域の最適化を行いません。

-mshort-data-num

データへの参照をr0への相対とすることにより、 データ参照に要するコードをより少なくします。 （通常、 値をロードするのには2命令が必要になりますが、） これにより、 ただ1つの命令によって値をロードすることができるようになります。 このオプションの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'） にします。 これにより、 以下のことが制御されます。

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

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

-mversion-03.00

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

-mno-check-zero-division

-mcheck-zero-division

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

-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ビットを超えるビット・シフトを検出するコードを挿入します。 そのような個々のシフトをトラップするか、 もしくは、 それらを正しく処理するためのコードを出力します。 デフォルトでは、 GCCは、 シフト数の大きいビット・シフトに対して特別な準備を行いません。

-mwarn-passed-structs

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

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

-mpowerpc64

-mno-powerpc64

GCCは、 RS/6000とPowerPCに対して2つの関連する命令セット・アーキテクチャをサポートしています。 POWER命令セットは、 初期のRS/6000システムにおいて使われていた`rios'チップ・セットによりサポートされている命令群です。 一方、 PowerPC命令セットは、 Motorola MPC5xx、 MPC6xx、 MPC8xxマイクロプロセッサとIBM 4xxマイクロプロセッサのアーキテクチャです。 どちらのアーキテクチャも他方のサブセットではありません。 しかし、 両方のアーキテクチャによってサポートされるかなりの数の共通命令サブセットが存在します。 POWERアーキテクチャをサポートするプロセッサには、 MQレジスタが含まれています。 これらのオプションを使って、 使用しているプロセッサ上において利用可能な命令群を指定します。 これらのオプションのデフォルト値は、 GCCのコンフィギュレーションを行う際に決定されます。 `-mcpu=cpu_type'を指定すると、 これらオプションのデフォルトの指定は無効になります。 上にリストされているオプションよりも、 `-mcpu=cpu_type'オプションを使うようお勧めします。 `-mpower'オプションが指定されるとGCCは、 POWERアーキテクチャにのみ存在する命令の生成とMQレジスタの使用ができるようになります。 `-mpower2'を指定すると、 暗黙のうちに`-mpower'(9)が指定されたことになり、 この場合GCCは、 初期のPOWERアーキテクチャには存在しないがPOWER2アーキテクチャには存在する命令を生成することができるようになります。 `-mpowerpc'オプションが指定されるとGCCは、 PowerPCアーキテクチャの32ビット・サブセットにのみ存在する命令群を生成することができるようになります。 `-mpowerpc-gpopt'を指定すると、 暗黙のうちに`-mpowerpc'が指定されたことになり、 この場合GCCは、 浮動小数点平方根を含む、 General Purposeグループに属する任意選択のPowerPCアーキテクチャ命令群を使うことができるようになります。 `-mpowerpc-gfxopt'を指定すると、 暗黙のうちに`-mpowerpc'が指定されたことになり、 この場合GCCは、 浮動小数点セレクトを含む、 Graphicsグループに属する任意選択のPowerPCアーキテクチャ命令群を使うことができるようになります。 `-mpowerpc64'オプションが指定されるとGCCはさらに、 完全なPowerPC64アーキテクチャに存在する64ビット命令群を生成することができるようになり、 かつ、 GPRを64ビットのダブルワード値として扱うことができるようになります。 GCCのデフォルトは`-mno-powerpc64'です。 `-mno-power'と`-mno-powerpc'を両方とも指定すると、 GCCは、 両方のアーキテクチャの共通サブセットに属する命令群だけを使います。 またこれに加えて、 いくつかの特殊なAIX共通モード呼び出し（common-mode call）を使い、 MQレジスタは使いません。 `-mpower'と`-mpowerpc'が両方とも指定されると、 GCCは、 いずれかのアーキテクチャに存在するものであれば任意の命令を使うことができるようになり、 MQレジスタの使用もできるようになります。 これは、 Motorola MPC601に対して指定してください。

-mnew-mnemonics

-mold-mnemonics

生成されるアセンブラ・コードの中で使われるニーモニックを選択します。 `-mnew-mnemonics'は、 PowerPCアーキテクチャに対して定義されたアセンブラ・ニーモニックを使った出力を要求するものです。 一方、 `-mold-mnemonics'は、 POWERアーキテクチャに対して定義されたアセンブラ・ニーモニックを要求します。 1つのアーキテクチャにおいてのみ定義されている命令に対しては、 ただ1つのニーモニックしか存在しないので、 どちらのオプションが指定されたかに関わりなく、 そのニーモニックをGCCは使うことになります。 GCCは、 使われているアーキテクチャにとって適切なニーモニックをデフォルトとします。 `-mcpu=cpu_type'が指定されると、 ときにはこれらのオプションの値が覆されることがあります。 クロス・コンパイラをビルドしようとしているのでなければ、 通常は`-mnew-mnemonics'も`-mold-mnemonics'も指定するべきではなく、 デフォルトを受け入れるべきです。

-mcpu=cpu_type

-mcpu=cpu_type

マシン・タイプcpu_typeに対応したアーキテクチャ・タイプ、 レジスタ使用、 ニーモニック選択、 命令スケジューリング・パラメータを設定します。 cpu_typeとしてサポートされている値は、 `rs6000'、 `rios1'、 `rios2'、 `rsc'、 `601'、 `602'、 `603'、 `603e'、 `604'、 `604e'、 `620'、 `740'、 `750'、 `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ファミリのメンバ上で動作するでしょう。 この場合GCCは、 両方のアーキテクチャの共通サブセットに属する命令群といくつかの特殊なAIX共通モード呼び出し（common-mode call）だけを使い、 MQレジスタは使いません。 GCCは、 スケジューリングについては、 一般的なプロセッサ・モデルを想定します。 オプション`-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'オプションが選択されます。 この場合GCCは、 プログラムの中にある、 一意であり自動変数ではない個々の変数参照に対して、 TOCエントリを少なくとも1つ割り当てます。 またGCCは、 浮動小数点定数をTOCの中に置きます。 しかし、 TOCの内部には16,384個のエントリしか入れることができません。 利用可能なTOC領域を超えてしまったことを示すエラー・メッセージがリンカから出された場合は、 `-mno-fp-in-toc'オプションと`-mno-sum-in-toc'オプションによって、 使用されるTOC領域の量を減らすことができます。 `-mno-fp-in-toc'は、 GCCが浮動小数点定数をTOCの中に入れることがないようにします。 また、 `-mno-sum-in-toc'は、 アドレス値と定数値の加算結果をTOCの中に入れるのではなく、 そのような計算を実行時に行うコードを生成するようGCCに強制します。 この2つのオプションは、 どちらか一方だけを指定することも可能ですし、 両方とも指定することも可能です。 どちらのオプションも、 TOC領域を節約する代わりに 非常に僅かながら実行速度が遅くサイズも大きいコードをGCCに生成させることになります。 これらのオプションを両方とも指定した場合でもTOC内の領域が不足するのであれば、 これらのオプションの代わりに`-mminimal-toc'を指定してください。 このオプションを指定するとGCCは、 個々のファイルに対してただ1つのTOCエントリを作成するようになります。 この場合にGCCが生成するコードは、 実行速度が遅くサイズも大きいものになりますが、 使用するTOC領域は極めて小さいものになります。 このオプションは、 実行される頻度が比較的少ないコードを含むファイルに対して使うのが良いでしょう。

-maix64

-maix32

AIX 64ビットABIとその呼び出し規約を有効にします。 64ビットのポインタ、 64ビットのlong型、 および、 これをサポートするために必要となるインフラストラクチャを有効にします。 `-maix64'を指定すると、 暗黙のうちに`-mpowerpc64'と`-mpowerpc'が指定されます。 一方`-maix32'は、 64ビットABIを無効にし、 `-mno-powerpc64'を暗黙のうちに指定します。 GCCのデフォルトは`-maix32'です。

-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'オプションを使うと、 ソフトウェアによる浮動小数点エミュレーションが提供されます。 このオプションは、 リンクを行う際にGCCに渡します。

-mmultiple

-mno-multiple

複数ワードのロード命令と複数ワードのストア命令を使う （あるいは、 使わない） コードを生成します。 これらの命令は、 POWERシステム上ではデフォルトで生成され、 PowerPCシステム上では生成されません。 これらの命令は、 プロセッサがリトル・エンディアン・モードにあるときには機能しないので、 リトル・エンディアンのPowerPCシステム上では`-mmultiple'を使わないでください。 ただしPPC740とPPC750は、 リトル・エンディアン・モードでもこれらの命令が使えますので、 例外です。

-mstring

-mno-string

複数のレジスタの内容を待避したり小さいブロックの移動を行ったりするために文字列のロード命令と文字列のストア命令を使う （あるいは、 使わない） コードを生成します。 これらの命令は、 POWERシステム上ではデフォルトで生成され、 PowerPCシステム上では生成されません。 これらの命令は、 プロセッサがリトル・エンディアン・モードにあるときには機能しないので、 リトル・エンディアンのPowerPCシステム上では`-mstring'を使わないでください。 ただしPPC740とPPC750は、 リトル・エンディアン・モードでもこれらの命令が使えますので、 例外です。

-mupdate

-mno-update

計算されたメモリ位置のアドレスへのベース・レジスタを更新するロード命令、 ストア命令を使う （あるいは、 使わない） コードを生成します。 これらの命令はデフォルトで生成されます。 `-mno-update'を使うと、 スタック・ポインタの更新と1つ前のフレームのアドレスの格納（ストア）の間に僅かな時間的なずれが発生します。 このことは、 割り込みやシグナルの発生の前後にまたがってスタック・フレームを移動するコードが、 正しくないデータを獲得する可能性があるということを意味しています。

-mfused-madd

-mno-fused-madd

浮動小数点の乗算命令と蓄積（accumulate）命令を使う （あるいは、 使わない） コードを生成します。 ハードウェアによる浮動小数点サポートが使用される場合には、 これらの命令はデフォルトで生成されます。

-mno-bit-align

-mbit-align

System V.4と組み込みPowerPCシステムにおいて、 ビット・フィールドを含む構造体と共用体が、 そのビット・フィールドの基本型にあわせて境界整列されるよう強制しません （あるいは、 強制します）。 例えば、 長さが1でunsigned型のビット・フィールドを8個持ち、 それ以外にはメンバを持たない構造体は、 デフォルトでは、 4バイト境界に境界整列され、 サイズは4バイトになります。 `-mno-bit-align'を使うと、 この構造体は1バイト境界に境界整列され、 サイズは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が、 プログラム中で使われるアドレス群を指すある広域領域へのポインタを保持していると想定しません （あるいは、 想定します）。

-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年3月版の「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'オプションを指定した場合に、 2つの別個のスモール・データ域を指すためにr2とr13の両方を使うことができるということを意味しています。 -mno-eabiを選択することは、 スタックが16バイト境界に境界整列されること、 mainから初期化関数が呼び出されないこと、 および、 `-msdata'オプションを指定した場合に、 単一のスモール・データ域を指すためにr13のみが使われるということを意味しています。 `powerpc*-*-eabi*'というパターンのオプションの1つを使って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

サイズが1ワードを超える構造体は、 レジスタにではなくメモリ上に置いて返します。 これにより、 MetaWare HighC (hc)コンパイラとの互換性がもたらされます。 Portable C Compiler (pcc)との互換性のためには`-fpcc-struct-return'を使ってください。

-mnohc-struct-return

サイズが1ワードを超える構造体であっても、 その方が都合が良い場合にはレジスタに入れて返します。 これがデフォルトです。 IBMにより提供されるコンパイラとの互換性のためには、 オプション`-fpcc-struct-return'かオプション`-mhc-struct-return'を使ってください。

MIPSオプション

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

-mcpu=cpu type

命令をスケジュールする際には、 マシン・タイプcpu typeのデフォルトの設定を想定します。 cpu typeに対する選択肢には、 `r2000'、 `r3000'、 `r3900'、 `r4000'、 `r4100'、 `r4300'、 `r4400'、 `r4600'、 `r4650'、 `r5000'、 `r6000'、 `r8000'、 `orion'があります。 また、 `r2000'、 `r3000'、 `r4000'、 `r5000'、 `r6000'は、 それぞれ、 `r2k' （あるいは`r2K'）、 `r3k'等々のように省略可能です。 特定のcpu typeを選択すると、 その特定のチップにとって適切なスケジューリングを行うようになりますが、 `-mipsX'オプションか`-mabi'オプションが使われていない限り、 コンパイラが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です。

-mips4

MIPS ISAのレベル4の命令 （条件付移動命令、 プリフェッチ命令、 拡張FPU命令） を出力します。 このISAレベルでは`r8000'がデフォルトのcpu typeです。

-mfp32

32個ある32ビット浮動小数点レジスタが利用可能であると想定します。 これがデフォルトです。

-mfp64

32個ある64ビット浮動小数点レジスタが利用可能であると想定します。 `-mips3'オプションが使われている場合は、 これがデフォルトです。

-mgp32

32個ある32ビット汎用レジスタが利用可能であると想定します。 これがデフォルトです。

-mgp64

32個ある64ビット汎用レジスタが利用可能であると想定します。 `-mips3'オプションが使われている場合は、 これがデフォルトです。

-mint64

int型とlong型を強制的に64ビットとします。 デフォルトについての説明とポインタ型のサイズについては、 `-mlong32'の項を参照してください。

-mlong64

long型を強制的に64ビットとします。 デフォルトについての説明とポインタ型のサイズについては、 `-mlong32'の項を参照してください。

-mlong32

long型、 int型、 および、 ポインタ型を強制的に32ビットとします。 `-mlong32'、 `-mlong64'、 `-mint64'のいずれも指定されない場合、 int型、 long型、 ポインタ型のサイズは、 選択されたABIとISAに依存します。 `-mabi=32'と`-mabi=n32'が指定された場合のintとlongは32ビットです。 `-mabi=64'が指定された場合は、 intが32ビットで、 longが64ビットとなります。 `-mabi=eabi'とともに、 `-mips1'と`-mips2'のうちいずれか一方が指定された場合は、 int、longはともに32ビットです。 `-mabi=eabi'とともに、 より高いISAレベルが指定された場合は、 intが32ビットで、 longが64ビットとなります。 ポインタ型のサイズは、 longのサイズと汎用レジスタのサイズのうち小さいほうとなります （これは、 結局のところISAに依存します）。

-mabi=32

-mabi=o64

-mabi=n32

-mabi=64

-mabi=eabi

指定されたABI用のコードを生成します。 デフォルトの命令レベルは、 `32'が指定された場合は`-mips1'、 `n32'が指定された場合は`-mips3'、 それ以外の場合は`-mips4'です。 逆に、 `-mips1'または`-mips2'が指定されると、 デフォルトのABIは`32'となり、 それ以外の場合は デフォルトのABIは`64'となります。

-mmips-as

MIPSアセンブラ用のコードを生成し、 通常のデバッグ情報を付加するために`mips-tfile'を起動します。 これは、 OSF/roseオブジェクト形式を使用するOSF/1リファレンス・プラットフォームを除くすべてのプラットフォームに対するデフォルトです。 `-gstabs'オプションと`-gstabs+'オプションのいずれかが使われると、 `mips-tfile'プログラムは、 MIPS ECOFFの内部にstabs情報を包含させます。

-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アセンブラは、 サイズの小さい広域データ要素、 静的データ要素に対して、 2ワードを使ったメモリ参照ではなく1ワードを使ったメモリ参照を生成することができるようになります。 最適化を行うよう選択されている場合には、 このオプションはデフォルトで設定されています。

-mstats

-mno-stats

`-mstats'オプションが指定されると、 コンパイラは、 処理される個々の非インライン関数について、 そのプログラムの統計情報 （待避されたレジスタの数、 スタック・サイズ等） を1行にして標準エラー・ファイルに出力します。

-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

浮動小数点を処理するためのライブラリ呼び出しを含む出力を生成します。 注意: 必要となるライブラリはGCCには付属していません。 通常、 そのマシンにおいて通常使われる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レジスタを使ってアドレス付けされます。 65,536バイトを超える広域データを使うことはできません。 このオプションは、 実際の仕事のほとんどを行うGNU asとGNU ldを必要とします。 現在のところこれは、 ECOFFを使うターゲット上でしか機能しません。 ELFでは機能しません。

-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'も有効にします。

-mips16

-mno-mips16

16ビット命令を有効にします。

-mentry

関数の入口と出口における擬似演算を使用します。 このオプションは、 `-mips16'との組み合わせでのみ使うことができます。

-EL

リトル・エンディアン・モードのプロセッサ用にコードをコンパイルします。 必要となるライブラリは存在するものと想定されます。

-EB

ビッグ・エンディアン・モードのプロセッサ用にコードをコンパイルします。 必要となるライブラリは存在するものと想定されます。

-G num

numバイト以下の広域データ項目と静的データ項目を、 通常のdataセクション、 bssセクションではなく、 small dataセクション、 small bssセクションに置きます。 これによりアセンブラは、 通常の2ワードを使ったメモリ参照命令ではなく、 広域ポインタ （gpあるいは$28） をベースにした1ワードのメモリ参照命令を生成することができるようになります。 デフォルトの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'	`i686'
`pentium'	`pentiumpro'	`k6'

特定のcpu typeを選択すると、 その特定のチップに対して適切な方法でスケジューリングが行われるようになります。 その一方で、 `-march=cpu type'オプションが使われていなければ、 コンパイラは、 i386上では動作しないコードを生成することはありません。 `i586'は`pentium'と同等であり、 `i686'は`pentiumpro'と同等です。 `k6'はIntelのチップではなく、 AMDのチップです。

-march=cpu type

マシン・タイプcpu type用の命令を生成します。 cpu typeに対する選択肢は`-mcpu'と同じです。 `-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

浮動小数点を処理するためのライブラリ呼び出しを含む出力を生成します。 注意: 必要となるライブラリはGCCには付属していません。 通常、 そのマシンにおいて通常使われる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

GCCがdouble、 long double、 long long型の変数を2ワード境界に境界整列するか1ワード境界に境界整列するかを制御します。 double型の変数を2ワード境界に境界整列すると、 消費されるメモリは多くなりますが、 `Pentium'上においていくらかより高速に実行されるコードが生成されます。 注意: `-malign-double'オプションを使うと、 上記の型を含む構造体については、 出版されている386のアプリケーション・バイナリ・インターフェイス仕様とは異なる境界整列が行われます。

-msvr3-shlib

-mno-svr3-shlib

初期化されない局所変数をGCCがbssセクションとdataセクションのどちらに置くかを制御します。 `-msvr3-shlib'は、 初期化されない局所変数をbssセクションに置きます。 これらのオプションは、 System V Release 3においてのみ意味があります。

-mno-wide-multiply

-mwide-multiply

long long型の乗算や定数による32ビット除算を実行するのに、 32ビットのオペランドから64ビットの結果を生成してeax:edxに格納するmulやimulをGCCが使うかどうかを制御します。

-mrtd

異なる関数呼び出し規約を使います。 この関数呼び出し規約では、 引数の数が固定である関数は、 復帰の際に引数をポップするret num命令を使って呼び出し元に復帰します。 これにより呼び出し元では、 引数をポップする必要がなくなるので、 命令を1つ節約することができます。 関数属性`stdcall'を使うことによって、 個々の関数ごとに、 この呼び出しシーケンスを使って呼び出すことを指定することができます。 また、 関数属性`cdecl'を使うことによって、 `-mrtd'オプションを覆すこともできます。 関数属性の宣言を参照してください。 注意: この呼び出し規約は、 通常UNIX上において使われる呼び出し規約とは互換性がありません。 したがって、 UNIXのコンパイラによりコンパイルされたライブラリを呼び出す必要がある場合には、 これを使うことはできません。 また、 （printfも含めて） 可変個数の引数を取るすべての関数について関数プロトタイプを提供しなければなりません。 さもないと、 これらの関数が呼び出されているところで、 正しくないコードが生成されることになります。 さらに、 関数の呼び出しに際して引数の数が多すぎると、 深刻な問題を持つコードが生成されてしまいます （通常は、 余分な引数は実害なく無視されます）。

-mreg-alloc=regs

整数レジスタのデフォルトの割り当て順序を制御します。 文字列regsは、 レジスタを指定する一連の文字です。 サポートされている文字を列挙すると以下のようになります。 aはEAXを、 bはEBXを、 cはECXを、 dはEDXを、 SはESIを、 DはEDIを、 BはEBPをそれぞれ割り当てます。

-mregparm=num

整数引数を渡すのにレジスタを何個使うかを制御します。 デフォルトでは引数を渡すのにレジスタは使われません。 最大では3個のレジスタまでを使うことができます。 関数属性`regparm'を使うことによって、 特定の関数におけるこの振る舞いを制御することができます。 関数属性の宣言を参照してください。 注意: このオプションをnumにゼロ以外の値を指定して使う場合には、 ライブラリも含めたすべてのモジュールを同一の値を指定してビルドしなければなりません。 これには、 システム・ライブラリやスタートアップ・モジュールも含まれます。

-malign-loops=num

2をnum乗したバイト数単位にループを境界整列します。 `-malign-loops'が指定されないと、 デフォルトのnumの値は2となります。 ただし、 gas 2.8以降を使っている場合は、 その結果が8バイト以上離れていない場合には、 ループを16バイト境界に整列するのがデフォルトとなります。

-malign-jumps=num

ジャンプ命令によってのみ到達される命令を、 2をnum乗したバイト数単位に境界整列します。 `-malign-jumps'が指定されない場合のデフォルトのnumの値は、 386用に最適化している場合には2、 486用に最適化している場合には4となります。 ただし、 gas 2.8以降を使っている場合は、 その結果が8バイト以上離れていない場合には、 その命令を16バイト境界に整列するのがデフォルトとなります。

-malign-functions=num

関数の先頭を、 2をnum乗したバイト数単位に境界整列します。 `-malign-functions'が指定されない場合のデフォルトのnumの値は、 386用に最適化している場合には2、 486用に最適化している場合には4となります。

-mpreferred-stack-boundary=num

スタック境界を、 2をnum乗したバイト数単位に境界整列します。 `-mpreferred-stack-boundary'が指定されない場合のデフォルト値は4 （16バイト、 あるいは、 128ビット） です。 スタックは4バイト境界に整列される必要があります。 また、 PentiumとPentiumProでは、 doubleとlong doubleの値は8バイト境界に整列しなければなりません （`-malign-double'を参照）。 さもないと、 実行時の性能に重大な影響が出ます。 Pentium IIIでは、 Streaming SIMD Extention（SSE）のデータ型である__m128が16バイト境界に整列されていない場合に、 同様の影響が出ます。 これらの値がスタック上において適切な境界に整列されることを確実にするためには、 スタック境界そのものが、 そのスタック上に格納される可能性のある値が要求する最大の境界に整列されていなければなりません。 さらにすべての関数が、 スタックが常に境界整列されるように、 生成されなければなりません。 より大きいスタック境界値を指定してコンパイルされた関数を、 より小さいスタック境界値を指定してコンパイルされた関数から呼び出すと、 ほとんどの場合、 境界整列が正しくなくなります。 コールバックを使うライブラリでは、 常にデフォルトの設定を使うようお勧めします。 この余分の境界整列は余分のスタック領域を消費します。 組み込みシステムやオペレーティング・システムのカーネルのようにスタック領域の使用に敏感なコードでは、 `-mpreferred-stack-boundary=2'によって希望する境界整列の値を小さくすることもできます。

HPPAオプション

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

-march=architecture type

指定されたアーキテクチャに対応したコードを生成します。 architecture typeの選択肢としては、 PA 1.0プロセッサ用の`1.0'、 PA 1.1プロセッサ用の`1.1'、 PA 2.0プロセッサ用の`2.0'があります。 お使いのマシンにとって適切なアーキテクチャ・オプションを決定するためには、 HP-UXシステム上の`/usr/lib/sched.models'を参照してください。 番号の小さいアーキテクチャ用にコンパイルされたコードは、 番号の大きいアーキテクチャでも動作します。 この逆は成り立ちません。 現在、 PA 2.0をサポートするためには、 スナップショット19990413以降のgasが必要になります。 binutilsの次のリリース （現リリースは2.9.1） には、 おそらくPA 2.0のサポートが組み込まれるでしょう。

-mpa-risc-1-0

-mpa-risc-1-1

-mpa-risc-2-0

それぞれ、 -march=1.0、 -march=1.1、 -march=2.0と同義です。

-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の選択肢としては、 `700'、 `7100'、 `7100LC'、 `7200'、 `8000'があります。 お使いのマシンにとって適切なスケジューリング・オプションを決定するためには、 HP-UXシステム上の`/usr/lib/sched.models'を参照してください。

-mlinker-opt

HPUXリンカの最適化処理のパスを使用できるようにします。 これによりシンボリック・デバッグは不可能になることに注意してください。 HPUX 8やHPUX 9のリンカには、 ある種のプログラムをリンクする際に偽のエラー・メッセージを出力するというバグがありますが、 このオプションを使うとこうしたバグを表面化させるきっかけにもなります。

-msoft-float

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

-mlong-double-64

`long double'型を64ビットの浮動小数点数として実装します。 このオプションを指定しないと、 `long double'は80ビットの浮動小数点数によって実装されます。 このオプションが存在する唯一の理由は、 `fp-bit.c'においてまだ128ビットの`long double'がサポートされていないということです。 したがってこれは、 -msoft-floatが指定されているターゲットを使用している人にとってのみ役に立つものです。 それ以外の場合は、 このオプションを使わないようお勧めします。

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' の3つのオプションを加えたものの短縮系です。 いくつかのAlphaの実装では、 このオプションを指定した結果生成されるコードは、 デフォルトの設定において生成されるコードと比較して、 かなり実行速度が遅くなることがあるかもしれません。 inexact flagに依存するコードはほとんどありませんから、 通常はこのオプションを指定するべきではありません。 他のAlpha用コンパイラでは、 このオプションは`-ieee_with_inexact'と呼ばれています。

-mfp-trap-mode=trap mode

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

`n'

これがデフォルト （通常） の設定です。 有効なトラップは、 ソフトウェアでは無効化できないものだけです （例えば、 ゼロによる除算によるトラップ）。

`u'

`n'において有効であるトラップに加えて、 アンダフローによるトラップもまた有効化されます。

`su'

`u'(10)と似ていますが、 ソフトウェアが終了した場合に問題がないよう、 命令にマークが付けられます （詳細については、 Alphaアーキテクチャ・マニュアルを参照）。

`sui'

`su'と似ていますが、 精密でないトラップも有効化されます。

-mfp-rounding-mode=rounding mode

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

`n'

通常のIEEE丸めモードです。 浮動小数点数は、 マシン上で表現できる数のうち最も近い数に丸められます。 最も近い数が2つある場合には、 偶数のものに丸められます。

`m'

負の無限大の方向に丸めます。

`c'

切り捨ての丸めモードです。 浮動小数点数はゼロの方向に丸められます。

`d'

動的な丸めモードです。 浮動小数点制御レジスタの中の1つのフィールド （fpcr。 詳細については、 Alphaアーキテクチャ・リファレンス・マニュアルを参照） が、 実際に使われる丸めモードを制御します。 Cライブラリは、 正の無限大の方向に丸めるようこのレジスタを初期化します。 したがって、 プログラムの中でfpcrを変更しない限り、 `d'は正の無限大の方向への丸めに対応します。

-mtrap-precision=trap precision

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

`p'

プログラム・レベルの精度。 このオプションがデフォルトです。 トラップ・ハンドラは浮動小数点例外を発生させたプログラムを識別することしかできない、 ということを意味しています。

`f'

関数レベルの精度。 トラップ・ハンドラは、 浮動小数点例外を発生させた関数を識別できます。

`i'

命令レベルの精度。 トラップ・ハンドラは、 浮動小数点例外を発生させた命令を正確に識別できます。

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

-mieee-conformant

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

-mbuild-constants

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

-malpha-as

-mgas

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

-mbwx

-mno-bwx

-mcix

-mno-cix

-mmax

-mno-max

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

-mcpu=cpu_type

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

`ev4'

`21064'

EV4としてスケジュールを行い、 拡張命令セットを持ちません。

`ev5'

`21164'

EV5としてスケジュールを行い、 拡張命令セットを持ちません。

`ev56'

`21164a'

EV5としてスケジュールを行い、 BWX拡張をサポートします。

`pca56'

`21164pc'

`21164PC'

EV5としてスケジュールを行い、 BWX拡張とMAX拡張をサポートします。

`ev6'

`21264'

（Digital社がEV6のスケジューリング・パラメータをリリースするまでの間は） EV5としてスケジュールを行い、 BWX拡張、 CIX拡張、 MAX拡張をサポートします。

-mmemory-latency=time

典型的なメモリ参照の際にアプリケーションが経験する待ち時間として、 スケジューラが想定するべき時間をセットします。 この数は、 アプリケーションが使うメモリ・アクセスのパターンとマシンの外部キャッシュのサイズに大きく依存します。 timeの正当なオプションには、 以下のものがあります。

`number'

クロック・サイクルを表わす10進数。

`L1'

`L2'

`L3'

`main'

コンパイラは、 「典型的な」EV4ハードウェア、 EV5ハードウェアにおける、 メイン・メモリへのアクセスの想定クロック数だけではなく、 レベル1キャッシュ、 レベル2キャッシュ、 レベル3キャッシュ （それぞれ、 Dcache、 Scache、 Bcacheとも呼ばれる） へのアクセスの想定クロック数を保持しています。 L3はEV５においてのみ有効である点に注意してください。

Clipperオプション

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

-mc300

C300 Clipperプロセッサ用のコードを生成します。 これがデフォルトです。

-mc400

C400 Clipperプロセッサ用のコードを生成します。 すなわち、 浮動小数点レジスタf8..f15を使います。

H8/300オプション

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

-mrelax

可能であれば、 リンク時にいくつかのアドレス参照を短くします。 リンカ・オプション`-relax'を使います。 より詳しい説明については、 Using ldの`ld and the H8/300'を参照してください。

-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

リトル・エンディアン・モードのプロセッサ用にコードをコンパイルします。

-mdalign

double型を64ビット境界に整列します。 このオプションは呼び出し規約を変更しますので、 標準Cライブラリの中の関数のいくつかは、 まず最初に-mdalignを指定して再コンパイルしないと機能しなくなります。

-mrelax

可能であれば、 リンク時にいくつかのアドレス参照を短くします。 リンカ・オプション`-relax'を使います。

System V用のオプション

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

-G

共用オブジェクトを作成します。 このオプションではなく、 `-symbolic'か`-shared'を使うことをお勧めします。

-Qy

コンパイラにより使われる各ツールのバージョンを、 出力中のアセンブラ指示子.identに明記します。

-Qn

出力ファイルの中に.ident指示子を追加するのを差し控えます （これがデフォルトです）。

-YP,dirs

`-l'で指定されたライブラリを探す際には、 ディレクトリdirsだけを探索し、 それ以外のディレクトリを探索しません。

-Ym,dir

M4プリプロセッサを見つけるためにディレクトリdirを探索します。 アセンブラがこのオプションを使います。

TMS320C3x/C4xオプション

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

-mcpu=cpu_type

マシン・タイプcpu_typeに対応した命令セット・パラメータ、 レジスタ・セット・パラメータ、 命令スケジューリング・パラメータを設定します。 cpu_typeの値としてサポートされるのは、 `c30'、 `c31'、 `c32'、 `c40'、 `c44'です。 デフォルトは、 TMS320C40用のコードを生成する`c40'です。

-mbig-memory

-mbig

-msmall-memory

-msmall

ビッグ・メモリ・モデル、 あるいは、 スモール・メモリ・モデル用のコードを生成します。 スモール・メモリ・モデルでは、 すべてのデータが1つの64Kワード・サイズのページに収まることを想定しています。 実行時に、 データ・ページ（DP）レジスタは、 .bss、 .dataプログラム・セクションを含む64Kのページを指すようセットされなければなりません。 ビッグ・メモリ・モデルがデフォルトで、 この場合は、 個々の直接メモリ・アクセスの際にDPレジスタを再ロードすることが必要になります。

-mbk

-mno-bk

一般的な整数オペランドを、 ブロック・カウント・レジスタBKに割り当てることができるよう （あるいは、 できないよう） にします。

-mdb

-mno-db

デクリメントと分岐を行うDBcond(D)命令を使うコードの生成を有効 （無効） にします。 これはC4xではデフォルトで有効です。 安全を図るため、 C3xでは無効となっています。 C3xでの最大繰り返し回数は2^23 + 1だからです （もっとも、 C3x上で2^23回を超えるループ繰り返しを行う人がいるでしょうか？）。 GCCは、 デクリメントと分岐を行う命令を利用するべく、 ループの方向を昇順から降順に変更することを試みますが、 ループの中に複数のメモリ参照が存在する場合にはその試みを断念します。 したがって、 ループ・カウンタの値が減少していくようなループは、 RPTB命令が利用できない場合には、 若干効率の良いコードを生成することになります。

-mdp-isr-reload

-mparanoid

割り込みサービス・ルーチン(ISR)に入ったところで、 強制的にDPレジスタが待避され、 dataセクションを指すようロードし直されます。 また、 ISRの終了時にDPレジスタは強制的に復元されます。 例えばオブジェクト・ライブラリの中で誰かがDPレジスタの値を変更することによってスモール・メモリ・モデルに違反しない限り、 このようなことは必要ではないはずです。

-mmpyi

-mno-mpyi

C3xにおける整数乗算について、 32ビットの結果を保証するためにライブラリ・コールするのではなく、 24ビットのMPYI命令を使います。 オペランドの1つが定数である場合には、 乗算はシフト命令と加算命令を使って実行されることに注意してください。 C3xにおいて-mmpyiオプションが指定されていない場合、 2乗演算は、 ライブラリ・コールにはよらず、 インライン展開されて実行されます。

-mfast-fix

-mno-fast-fix

C3x/C4x FIX命令は、 浮動小数点値を整数値に変換する際に、 その浮動小数点値に最も近い整数値ではなく、 その浮動小数点値以下の整数のうち最も近いものを選択します。 したがって、 浮動小数点値が負の場合、 結果は誤って切り捨てられることになり、 このようなケースを検出して訂正するためのコードが追加で必要となります。 このオプションを使うことによって、 結果を訂正するために必要とされる追加的なコードの生成を行わないようにすることができます。

-mrptb

-mno-rptb

オーバーヘッドのないループを実現するために、 RPTB命令を使った繰り返しブロック・シーケンス（repeat block sequence）を有効 （無効） にします。 RPTBは、 関数呼び出しやループ境界をまたがるジャンプのない、 最も内側のループに対してのみ使われます。 RC、 RS、 REの各レジスタの退避と復元を行う必要があるということがオーバーヘッドとなるため、 入れ子になったRPTBループを持っても利点はありません。 これは、 -O2が指定されるとデフォルトで有効になります。

-mrpts=count

-mno-rpts

単一命令の繰り返し命令であるRPTSの使用を有効 （無効） にします。 繰り返しブロックの中に単一の命令しかなく、 ループ・カウントの値がcountで指定される値よりも小さいことが保証される場合、 GCCはRPTB命令ではなくRPTS命令を出力します。 値が指定されないと、 ループ・カウントがコンパイル時に決定できない場合でもRPTS命令が出力されます。 RPTSの後ろの繰り返される命令は、 個々の繰り返しのたびにメモリから再ロードされなくても構わないため、 オペランドのためのCPUバスは解放されるますが、 この命令によって割り込みがブロックされるため、 デフォルトでは無効になっています。

-mloop-unsigned

-mno-loop-unsigned

RPTS、 RPTB （および、 C40上のDB） を使う場合の最大繰り返しカウントは2^31 + 1です。 これらの命令が、 ループの繰り返しを停止するのに、 繰り返しカウントが負であるかどうかをテストするからです。 符号無しの繰り返しカウントは、 2^31 + 1の上限を超える可能性があります。 このオプションにより、 符号無しの繰り返しカウントを使うことができるようになります。

-mti

TIアセンブラ （asm30） が認識できるアセンブラ構文を出力するよう試みます。 また、 TI C3x Cコンパイラにより採用されているAPIとの互換性も強制的にもたらします。 例えばlong doubleは、 浮動小数点レジスタに入れて渡されるのではなく、 構造体として渡されます。

-mregparm

-mmemparm

関数へ引数を渡す際にレジスタ （スタック） を使うコードを生成します。 デフォルトでは、 可能である限り、 引数はスタックにプッシュされるのではなく、 レジスタに入れて渡されます。

-mparallel-insns

-mno-parallel-insns

パラレル命令の生成を許します。 -O2が指定されている場合は、 デフォルトで有効になっています。

-mparallel-mpy

-mno-parallel-mpy

-mparallel-insnsがあわせて指定されているという条件のもとで、 MPY||ADDパラレル命令、 MPY||SUBパラレル命令の生成を許します。 これらの命令がレジスタに対して課す制約は厳しいので、 サイズの大きい関数のコード生成は期待できないかもしれません。

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）に適するコードを生成します。 分岐可能範囲外への分岐命令がスイッチ・テーブルの中に存在する旨のメッセージを、 アセンブラやリンカが出力する場合にのみ、 このオプションを使ってください。

ARCオプション

以下のオプションがARCの実装に対して定義されています。

-EL

リトル・エンディアン・モード用にコードをコンパイルします。 これがデフォルトです。

-EB

ビッグ・エンディアン・モード用にコードをコンパイルします。

-mmangle-cpu

すべてのパブリックなシンボル名の前にCPUの名前を付けます。 マルチプロセッサ・システムでは、 異なる命令セットやレジスタ・セットを特徴として持つ、 ARCの変種が数多く存在します。 このフラグによって、 あるCPU用にコンパイルされたコードが、 別のCPU用にコンパイルされたコードとリンクされてしまうという事態を防ぐことができます。 「ほとんど同一」な変種を処理するための機能は提供されていません。 これは、 「全か無か」のオプションです。

-mcpu=cpu

cpuによって指定されるARCの変種用にコードをコンパイルします。 どの変種がサポートされるかは、 コンフィギュレーションに依存します。 すべての変種がデフォルトの`-mcpu=base'をサポートします。

-mtext=text section

-mdata=data section

-mrodata=readonly data section

関数、 データ、 読み込みのみ可能なデータを、 デフォルトでそれぞれ、 text section、 data section、 readonly data sectionによって指定されるセクションに置きます。 この設定は、 section属性によって無効にすることができます。 変数属性の指定を参照してください。

NS32Kオプション

以下の`-m'オプションが32000シリーズに対して定義されています。 これらのオプションのデフォルト値は、 コンパイラがconfigureによって構成された際に選択された32000スタイルに依存します。 最も一般的な選択肢に対するデフォルトを以下に示してあります。

-m32032

-m32032

32032用の出力を生成します。 これは、 コンパイラが、 configureによって32032ベースのシステム、 および、 32016ベースのシステム用に構成されている場合のデフォルトです。

-m32332

-m32332

32332用の出力を生成します。 これは、 コンパイラが、 configureによって32332ベースのシステム用に構成されている場合のデフォルトです。

-m32532

-m32532

32532用の出力を生成します。 これは、 コンパイラが、 configureによって32532ベースのシステム用に構成されている場合のデフォルトです。

-m32081

浮動小数点用の32081命令を含む出力を生成します。 これは、 すべてのシステムのデフォルトです。

-m32381

浮動小数点用の32381命令を含む出力を生成します。 これは、 暗黙のうちに`-m32081'を指定します。 32381と互換性を持つCPUは、 32332と32532だけです。 これは、 pc532-netbsdコンフィギュレーションのデフォルトです。

-mmulti-add

乗算-加算（multiply-add）浮動小数点命令である、 polyFとdotFを生成するよう試みます。 このオプションは、 `-m32381'オプションが指定されている場合にのみ利用可能です。 これらの命令を使うためには、 レジスタ割り当てに対する変更が必要ですが、 これは一般的には性能に対して悪影響を持ちます。 このオプションは、 特に乗算-加算命令を多用する見込みのあるコードをコンパイルする場合にのみ有効にするべきです。

-mnomulti-add

乗算-加算（multiply-add）浮動小数点命令である、 polyFとdotFを生成することを試みません。 これは、 すべてのプラットフォームにおけるデフォルトです。

-msoft-float

浮動小数点を処理するためのライブラリ呼び出しを含む出力を生成します。 注意: 必要となるライブラリが入手できない場合もあります。

-mnobitfield

ビット・フィールド命令を使いません。 マシンによっては、 シフト演算とマスク演算を使うほうが高速です。 これはpc532のデフォルトです。

-mbitfield

ビット・フィールド命令を使います。 これは、 すべてのプラットフォームにおけるデフォルトです。

-mrtd

異なる関数呼び出し規約を使います。 この関数呼び出し規約では、 引数の数が固定である関数は、 復帰の際に引数をポップするret命令を使って呼び出し元に復帰します。 この呼び出し規約は、 通常UNIX上において使われる呼び出し規約とは互換性がありません。 したがって、 UNIXのコンパイラによりコンパイルされたライブラリを呼び出す必要がある場合には、 これを使うことはできません。 また、 （printfも含めて） 可変個数の引数を取るすべての関数について関数プロトタイプを提供しなければなりません。 さもないと、 これらの関数が呼び出されているところで、 正しくないコードが生成されることになります。 さらに、 関数の呼び出しに際して引数の数が多すぎると、 深刻な問題を持つコードが生成されてしまいます （通常は、 余分な引数は実害なく無視されます）。 このオプションの名前は、 680x0のrtd命令からとられています。

-mregparam

最初の2つの引数がレジスタに入れて渡される関数呼び出し規約を使います。 この呼び出し規約は、 通常UNIX上において使われる呼び出し規約とは互換性がありません。 したがって、 UNIXのコンパイラによりコンパイルされたライブラリを呼び出す必要がある場合には、 これを使うことはできません。

-mnoregparam

どのような引数もレジスタに入れて渡すことをしません。 これは、 すべてのターゲットにおけるデフォルトです。

-msb

常にゼロがロードされるインデックス・レジスタとしてsbを使うことができます。 これは、 pc532-netbsdターゲットのデフォルトです。

-mnosb

sbレジスタは使用できない状態であるか、 あるいは、 ランタイム・システムによって未だゼロに初期化されていません。 これは、 pc532-netbsdを除くすべてのターゲットのデフォルトです。 また、 `-mhimem'または`-fpic'が指定された場合には、 暗黙のうちに指定されます。

-mhimem

多くのns32000シリーズにおけるアドレッシング・モードは、 最高で512MBまでの配置転換（displacement）を利用します。 アドレスが512MBを超える場合、 ゼロからの配置転換は利用できません。 このオプションを指定すると、 512MBを超えるアドレスにロードすることのできるコードが生成されます。 これは、 オペレーティング・システムやROMコードにおいて役に立つかもしれません。

-mnohimem

仮想アドレス空間の最初の512MBの範囲にコードがロードされるものと想定します。 これは、 すべてのプラットフォームにおけるデフォルトです。

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

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

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

-fexceptions

例外処理を有効にし、 例外を伝播するために必要となる追加のコードを生成します。 ターゲットによっては、 暗黙のうちに、 すべての関数に対してフレーム解放のための情報が生成されることになります。 これによって、 処理の実行そのものが影響を受けることはありませんが、 データ・サイズのオーバーヘッドは非常に大きくなります。 このオプションが指定されないと、 C++のように通常から例外処理を必要とする言語についてはデフォルトでこのオプションが有効となり、 Cのように通常は例外処理を必要としない言語についてはデフォルトでこのオプションは無効となります。 しかし、 C++で書かれた例外ハンドラと適切にやりとりする必要のあるCのコードをコンパイルする際には、 このオプションを有効にする必要があるかもしれません。 また、 例外処理を使わない古いC++のプログラムをコンパイルする場合には、 このオプションを無効にするのが良いかもしれません。

-fpcc-struct-return

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

-freg-struct-return

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

-fshort-enums

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

-fshort-double

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

-fshared-data

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

-fno-common

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

-fno-ident

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

-fno-gnu-linker

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

-finhibit-size-directive

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

-fverbose-asm

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

-fvolatile

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

-fvolatile-global

外部データ項目と広域データ項目に対するメモリ参照はすべてvolatile指定されたものとみなします。 このオプションが指定されても、 GCCは静的データ項目をvolatile指定されたものとはみなしません。

-fvolatile-static

静的データに対するメモリ参照はすべてvolatile指定されたものとみなします。

-fpic

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

-fPIC

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

-ffixed-reg

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

-fcall-used-reg

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

-fcall-saved-reg

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

-fpack-struct

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

-fcheck-memory-usage

個々のメモリ・アクセスをチェックするための追加のコードを生成します。 GCCは、 例えば`Checker'のような、 不正なメモリ・アクセスを検出するツールに適したコードを生成するようになります。 通常は、 このオプションを指定してすべてのソース・コードをコンパイルするか、 このオプションを指定せずにすべてのソース・コードをコンパイルするか、 どちらか一方にするべきです。 このオプションを指定してコンパイルしたコードと、 このオプションを指定せずにコンパイルしたコードを混在させる場合は、 副作用を持ち、 かつ、 このオプションを指定してコンパイルされたコードから呼び出されるすべてのコードが、 それ自身確実にこのオプションを指定してコンパイルされるようにしなければなりません。 ライブラリの中に含まれる関数で （例えばreadのように） 副作用を持つものを使うのであれば、 そのライブラリをこのオプションを指定して再コンパイルすることはできないかもしれません。 その場合には、 `-fprefix-function-name'オプションを使うことができます。 このオプションは、 ユーザのコードをカプセル化して、 他の関数が`-fcheck-memory-usage'を指定してコンパイルされたかのように見えるようにすることを、 GCCに対して要求するものです。 これは、 検出ツールにより提供される「スタブ」を呼び出すことで実現されます。 呼び出されるすべての関数に対するスタブを見つけることも構築することもできない場合は、 `-fprefix-function-name'を指定せずに`-fcheck-memory-usage'を指定しなければならないかもしれません。 このオプションを指定すると、 メモリ・チェックが有効となっている関数の中では、 asmキーワードや__asm__キーワードは使えません。 コンパイラは、 asm文が何をするものであるかを理解することができないので、 適切なコードを生成することができず、 よってこれらは拒絶されます。 しかし、 関数属性no_check_memory_usageを指定すれば、 その関数の中ではメモリ・チェックは無効となりますので、 asm文を含めることができるようになります。 チェックを行う関数の中に、 チェックを行わない関数をインライン展開することは許されています。 その場合、 インライン関数の部分についてはメモリ・アクセスはチェックされず、 それ以外の部分についてはチェックされます。 asm文を、 チェックを行わないインライン関数側に移動したにもかかわらず、 それらの関数の中でメモリ・アクセスが行われる場合、 インライン関数の中にサポート・コードの呼び出しを追加して、 実行される読み込み、 書き込み、 コピーを示すことができます。 これらの呼び出しは、 上記のスタブの中で行われるものと類似しています。

-fprefix-function-name

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

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

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

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

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

-finstrument-functions

関数の入口と出口に、 計測用の呼び出しを生成します。 関数の中に入った直後と関数から出る直前に、 以下のプロファイル用の関数が、 カレントな関数のアドレスとその呼び出し個所（call site）を引数として呼び出されます。 （プラットフォームによっては、 __builtin_return_addressはカレントな関数の範囲外では機能しないため、 呼び出し個所に関する情報はプロファイル用の関数側では利用できないかもしれません。）

void __cyg_profile_func_enter (void *this_fn, void *call_site);
void __cyg_profile_func_exit  (void *this_fn, void *call_site);

最初の引数は、 カレントな関数の先頭アドレスです。 これは、 シンボル・テーブルから正確に調べることができます。 この計測用のコードの組み込みは、 他の関数の中にインライン展開された関数についても行われます。 プロファイル用の関数の呼び出しは、 概念的には、 インライン関数の入口と出口を示すことになります。 このことは、 その関数のアドレス付け可能なバージョンが存在しなければならないということを意味しています。 その関数が、 呼び出されるすべての個所でインライン展開されている場合、 このことは、 コードのサイズがさらに大きくなることを意味しています。 Cのコードの中で`extern inline'を使えば、 その関数のアドレス付け可能なバージョンが提供されなければならなくなります。 （いずれしろこれが通常のケースなのですが、 幸運なことに最適化プログラムがその関数を常にインライン展開してしまうと、 静的なコピーの提供をしないままになってしまうかもしれません。 関数に対してno_instrument_function属性を指定することができます。 この場合、 計測用のコードの組み込みは行われなくなります。 例えば、 上記のプロファイル用関数、 プライオリティの高い割り込みルーチン、 および、 プロファイル用関数を安全に呼び出すことのできない任意の関数 （プロファイル・ルーチンが出力を生成したり、 メモリの割り当てを行う場合、 シグナル・ハンドラがこれに相当するでしょう） について、 この属性を使うことができます。

-fstack-check

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

-fargument-alias

-fargument-noalias

-fargument-noalias-global

パラメータ間、 および、 パラメータと広域データの間の可能な関連付けを指定します。 `-fargument-alias'は、 引数 （パラメータ） が、 相互に別名となること、 および、 広域記憶域の別名となることができることを指定します。 一方、 `-fargument-noalias'は、 引数が、 相互に別名となることはないが、 広域記憶域の別名となることはできることを指定します。 `-fargument-noalias-global'は、 引数が、 相互に別名となることも広域記憶域の別名となることもないことを指定します。 個々の言語は、 その言語標準によって要求されるオプションを自動的に使用します。 これらのオプションをユーザが自分で使う必要はないはずです。

-fleading-underscore

このオプションとその逆のオプションである-fno-leading-underscoreは、 オブジェクト・ファイルの中でCのシンボルが表現される方法を強制的に変更します。 過去に作成されたアセンブラ・コードとのリンクを支援するのが、 このオプションの用途の1つです。 このオプションを指定する際には、 自分が何をしているのかを理解している必要があるということ、 および、 すべてのターゲットにおいてこれが完全にサポートされているわけではないということに注意してください。

GCCに影響を与える環境変数

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

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

LANG

LC_CTYPE

LC_MESSAGES

LC_ALL

これらの環境変数は、 異なる国の慣習をサポートできるようにGCCが地域固有情報（localization information）を使う方法を制御します。 GCCは、 configureによってそのようにするように構成されている場合には、 ロケール・カテゴリLC_CTYPE、 LC_MESSAGESを調べます。 これらのロケール・カテゴリには、 インストール環境によりサポートされている任意の値をセットすることができます。 典型的な値としては、 英国英語に対する`en_UK'があります。 環境変数LC_CTYPEは、 文字分類（character classification）を指定します。 GCCはこれを、 文字列内における文字境界を決定するのに利用します。 通常は文字列の終端として解釈されてしまう引用符や、 通常はエスケープ文字として解釈されてしまう文字を含むような、 いくつかのマルチバイト・エンコーディングにおいてこれが必要となります。 環境変数LC_MESSAGESは、 診断メッセージにおいて使用する言語を指定します。 環境変数LC_ALLがセットされると、 その値によってLC_CTYPEやLC_MESSAGESのもとの設定は無効にされます。 環境変数LC_ALLがセットされていない場合は、 LC_CTYPEとLC_MESSAGESのデフォルトの値は環境変数LANGの値となります。 これらの変数がいずれもセットされていない場合、 GCCのデフォルトは、 伝統的な英語環境であるCとなります。

TMPDIR

TMPDIRがセットされていると、 それは一時ファイルを作成するのに使われるディレクトリを指定します。 GCCは、 コンパイル処理のある1つの段階の出力を保存するのに一時ファイルを使い、 それが次の段階の入力として使われることになります。 例えば、 プリプロセッサの出力は狭義のコンパイラの入力となります。

GCC_EXEC_PREFIX

GCC_EXEC_PREFIXがセットされていると、 それはコンパイラにより実行される下位プログラムの名前の接頭語を指定します。 この接頭語が下位プログラムの名前に結合される際にはスラッシュは追加されません。 しかし、 もしそうしたいのであれば、 末尾がスラッシュである接頭語を指定することもできます。 指定された接頭語を使った名前で下位プログラムを見つけることができない場合、 GCCは下位プログラムが通常置かれている場所を探そうとします。 GCC_EXEC_PREFIXのデフォルトの値は `prefix/lib/gcc-lib/'です。 prefixは、 `configure'スクリプトを実行したときのprefixの値です。 `-B'オプションで指定された別の接頭語があれば、 そちらが優先されます。 この接頭語は、 リンクに使われる`crt0.o'のようなファイルを見つける際にも使われます。 さらに、 ヘッダ・ファイルを探すディレクトリを見つける際にも、 この接頭語は変わった方法で使われます。 通常は`/usr/local/lib/gcc-lib' （より正確には、 GCC_INCLUDE_DIRの値） で始まる名前を持つ個々の標準ディレクトリを、 指定された接頭語で始まる名前に置き換えることによって、 GCCは別のディレクトリ名を作成しようとします。 したがって、 `-Bfoo/'が指定されると、 通常であれば`/usr/local/lib/bar'を探すところを、 GCCは`foo/bar'を探します。 これらの代替ディレクトリが最初に探索され、 標準ディレクトリはその次に探索されます。

COMPILER_PATH

COMPILER_PATHの値は、 PATHと同様、 コロンで区切られたディレクトリのリストです。 GCCは、 GCC_EXEC_PREFIXを使って下位プログラムを見つけることができない場合、 この環境変数で指定されたディレクトリを探索します。

LIBRARY_PATH

LIBRARY_PATHの値は、 PATHと同様、 コロンで区切られたディレクトリのリストです。 configureによってネイティブ・コンパイラとして構成された場合、 GCCは、 GCC_EXEC_PREFIXを使って特殊なリンカ・ファイルを見つけることができないと、 この環境変数で指定されたディレクトリを探索します。 GCCを使ったリンク処理では、 `-l'オプションで指定された通常のライブラリを探す際にもこれらのディレクトリが使われます （ただし、 `-L'で指定されたディレクトリが最初に使われます）。

C_INCLUDE_PATH

CPLUS_INCLUDE_PATH

OBJC_INCLUDE_PATH

これらの環境変数は特定の言語に関係するものです。 個々の変数の値は、 PATHと同様、 コロンで区切られたディレクトリのリストです。 GCCがヘッダ・ファイルを探す際には、 まず`-I'で指定されたディレクトリが探索され、 続いて、 上記の環境変数のうち使用している言語に対応するものにリストされているディレクトリが探索されます。 標準のヘッダ・ファイル・ディレクトリは、 このあとに探索されます。

DEPENDENCIES_OUTPUT

この変数がセットされていると、 その値は、 コンパイラにより処理されるヘッダ・ファイルに基づいてmake用の依存関係をどのように出力するかを指定します。 この出力は、 `-M'オプション （プリプロセッサを制御するオプションを参照） による出力とよく似ていますが、 この出力は別ファイルに書き込まれ、 かつ、 通常のコンパイル処理も行われます。 DEPENDENCIES_OUTPUTの値は単にファイル名であることもあります。 この場合、 makeルールはそのファイルに書き込まれ、 ターゲットの名前はソース・ファイルの名前から推測されます。 また、 DEPENDENCIES_OUTPUTの値は`file target'という形式を取ることもあります。 この場合、 targetをターゲット名として、 ファイルfileにルールが書き込まれます。

LANG

この環境変数は、 コンパイラに対してロケール情報を渡すために使われます。 この情報の用途の1つに、 C/C++において文字リテラル、 文字列リテラル、 コメントが解析される際に使う文字セットの決定があります。 コンパイラが、 configureによってマルチバイト文字を取り扱えるよう構成されている場合、 LANGの値として以下のものが認識されます。

C-JIS

JIS文字を認識します。

C-SJIS

SJIS文字を認識します。

C-EUCJP

EUCJP文字を認識します。

LANGが定義されていない場合、 あるいは、 その値が上記以外のものである場合、 コンパイラは、 マルチバイト文字の認識と変換を行うために、 デフォルト・ロケールにより定義されているmblenとmbtowcを使うことになります。

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はいずれも、 プログラムをスキャンしてその中で使われている関数に関する情報を収集する部分はGCCに依存しています。 したがって、 どちらのプログラムも、 GCCがインストールされるまでは機能しません。

以下に、 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(14) においてのみ有効です。 unprotoizeは、 プロトタイプ化された関数定義を旧方式の関数定義に変換します。 この旧方式の関数定義では、 引数は、 引数リストと最初の`{'の間で宣言されます。 デフォルトでは、 unprotoizeは5個の空白をインデントに使います。 5個の空白ではなく1個の空白でインデントを行いたい場合は、 `-i " "'を使ってください。

-k

`.X'ファイルを保持します。 通常このファイルは、 変換処理の終了後に削除されます。

-l

明示的な局所宣言を追加します。 `-l'を指定するとprotoizeは、 宣言されていない関数を呼び出す個々のブロックの中に、 その関数のプロトタイプ宣言を挿入します。 このオプションは、 protoizeにおいてのみ有効です。

-n

実際の変更処理を行いません。 このモードでは、 `-n'が指定されなかった場合に実行されたであろう変換処理に関する情報が表示されるだけです。

-N

`.save'ファイルを作成しません。 元のファイルは削除されてしまいます。 このオプションは注意して使ってください。

-p program

programという名前のプログラムをコンパイラとして使います。 通常は`gcc'という名前が使われます。

-q

静かに処理を実行します。 ほとんどの警告は表示されません。

-v

gccの`-v'と同様、 バージョン番号を表示します。

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

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

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

protoizeを上手に使うための方法に関する詳細については、 protoize の使用に関する警告を参照してください。

ここに記載されている情報のほとんどは最新ではなく、 EGCSインストール手順によって取って代わられたものです。 これらの情報は、 過去のインストール手順を参照するという目的のためだけに提供されています。