Node:Top, Next:G++ and GCC, Previous:(dir), Up:(dir)

Introduction

このマニュアルでは、GNU コンパイラの使い方、インストール方法、移植方法や、新しい機能や互換性の無い部分、それにバグレポートの方法などについて説明している。GNU CC のバージョン 2.95 に対応している。(日本語版ドラフト-17 July 2001)

G++ and GCC: C や C++ のプログラムがコンパイル可能
Invoking GCC: gcc のコマンド行オプション
Installation: GCC のインストール方法
C Extensions: C 言語の GNU の拡張
C++ Extensions: C++ 言語の GNU の拡張
Gcov: gcov: GCC のテストカバレージプログラム
Trouble: GCC のインストールで問題が起きたときは
Bugs: バグレポートの方法
Service: GCC のサポートの提供者
Contributing: GCC のテストと開発の支援方法
VMS: VMS 上での GCC の使い方
Portability: GNU CC の互換性についての目標
Interface: GNU CC の出力の関数呼び出しインターフェース
Passes: 各パスについて
RTL: 中間言語について
Machine Desc: 命令パターンの書き方
Target Macros: マシンを記述する C マクロの書き方
Config: xm-machine.h の書き方
Fragments: t-target と x-host の書き方
Funding: フリーソフトウェアへの資金提供を保証するには
GNU/Linux: Linux と GNU プロジェクト
Copying: GNU General Public License について
Contributors: GCC に貢献した人々
Index: 概念とシンボル名についての索引

Node:G++ and GCC, Next:Invoking GCC, Previous:Top, Up:Top

C, C++, Objective C, Fortran のコンパイル

C, C++, Objective C, Fortran 毎に分かれていたコンパイラは現在では一つに統合されている。このため我々は「GNU コンパイラ集」(GNU Compiler Collection) という名前を使うことにした。GNU C コンパイラは, C, C++, Objective C, Fortran で書かれたプログラムをコンパイルすることが可能である。Fortran コンパイラについては独立したマニュアルで説明している。

GCC というのは、GNU コンパイラ集(GNU Compiler Collection)のよくある省略形である。我々のコンパイラの最も一般的な名前でもあるし、C 言語のプログラムをコンパイルすることに焦点が置かれている場合に使われる名前でもある(この省略形は以前は "GNU C Compiler" を表していた)。

C++ プログラムのコンパイルについて言うときには、G++ と呼ぶのが普通である。コンパイラ自体は一つしかないので、対象とする言語がなんであれ、GCC と呼ぶのは全く正しい。だが、C++ プログラムをコンパイルするのだということを強調するときは、G++ と呼ぶのが便利である。

我々は、"GCC" をコンパイラシステム全体を指す名前として使う。もう少し正確には、このコンパイラの言語非依存部を指す。例えば、「GCC」の動作に影響する最適化オプションと言ったり、あるいは単に「コンパイラ」と言ったりすることもある。

他の言語フロントエンドとして、Ada 9X, Fortran, Modula-3, Pascal について開発中である。これらのフロントエンドは、C++ と同様、GNU CC のサブディレクトリで構築され、GCC にリンクされる。この結果、統合されたコンパイラが出来上がり、C, C++, Objective C, あるいはユーザがインストールしたフロントエンドの言語がコンパイル出来ることになる。

本マニュアルでは、C、Objective-C、C++ コンパイラのオプションと、GCC の中核部分のオプションについてのみ解説を行う。他の言語で書かれたプログラムをコンパイルする際に使用するオプションについては、その言語のフロントエンドの文書を参照すること。

G++ は本物のコンパイラである。単なるプリプロセッサではない。G++ は、C++ プログラムのソースから直接オブジェクトコードを生成する。中間的な C のコードは作らない。(対照的に、例えば他の実装の中には、C++ ソースから C プログラムを生成するものもある。) C 言語による中間表現を使わないことで、より良いオブジェクトコード、より良いデバッグ情報を得ることができる。GNU デバッガ GDB を使えば、オブジェクトコード中の、このより良いデバッグ情報と合わせて、C++ プログラムのソースコードレベルの編集(デバッグ)機能の恩恵を受けることができる。

Node:Invoking GCC, Next:Installation, Previous:G++ and GCC, Up:Top

GCC コマンド行オプション

GCC を起動すると、普通は、プリプロセス、コンパイル、アセンブル、リンクを行なう。"overall options" を指定することで、この過程を中間の段階で止めることができる。例えば、-c オプションを指定すると、リンカを起動しない。そして、出力はアセンブラの出力であるオブジェクトファイルからなる。

その他のオプションは、上記の過程の一つの段階に受け渡される。プリプロセッサを制御するオプションもあるし、コンパイラ本体を制御するオプションもある。さらに、その他に、アセンブラとリンカを制御するオプションもあるが、ほとんどのオプションは滅多に必要になることはないので、ここでは説明しない。

GCC に指定できるコマンド行オプションは、大部分が C 言語向けである。他の言語(C++ であることが多い)でも使えるオプションについては、明示的にその旨を書くようにしている。ソースプログラムの言語について記述のないオプションは、サポートされている全ての言語に対して使うことができる。

C++ プログラムをコンパイルするときの特別なオプションの要約については、See Compiling C++ Programs.

gcc は、オプションとファイル名を引数として受け付ける。複数の文字からなる名前を持つオプションがたくさんあるので、一文字のオプションをまとめて指定することはできない。例えば、-dr というオプションは、-d -r とは全く異なる指定になる。

オプションとそれ以外の引数を入り混ぜて使うことができる。引数の順序は問題にならない場合が多い。問題になるのは、同じ種類のオプションを重ねて使うときである。例えば、-L オプションを複数回指定すると、指定された順番でディレクトリを検索する。

-f や -W で始まる長い名前のオプションがたくさんある。例えば、-fforce-mem、-fstrength-reduce、-Wformat といったものだ。この種類のオプションは、ほとんどが、肯定形式と否定形式の両方の形式を持つ。例えば、-ffoo の否定形式は -fno-foo になる。このマニュアルでは、二つの形式のうちのどちらかのみ、つまりデフォルトでない方のみを説明する。

Option Summary: 解説抜きの全オプションの一覧
Overall Options: 出力の種類の制御: 実行形式、オブジェクトファイル、アセンブラファイル、プリプロセス済のファイル
Invoking G++: C++ プログラムのコンパイル
C Dialect Options: コンパイルされる C 言語の種類の制御
C++ Dialect Options: 様々な C++
Warning Options: どれぐらい口うるさくしますか?
Debugging Options: シンボルテーブル、各種測定、デバッグ用出力
Optimize Options: どれぐらい最適化しますか?
Preprocessor Options: ヘッダファイルとマクロ定義の制御。 make 用依存関係情報の取得。
Assembler Options: アセンブラのオプションの指定方法
Link Options: ライブラリなどの指定方法
Directory Options: ヘッダファイルとライブラリのありか。コンパイラを構成する実行形式ファイルのありか。
Target Options: クロスコンパイラや GCC の古いバージョンの実行方法
Submodel Options: 68010 vs 68020 のようなハードウェアや規約の細かな違いを指定するには。
Code Gen Options: 関数呼出し、データ配置、レジスタの使い方に関する約束。
Environment Variables: GCC で使われる環境変数
Running Protoize: 関数プロトタイプ宣言の自動生成／削除

Node:Option Summary, Next:Overall Options, Previous:Invoking GCC, Up:Invoking GCC

オプション要約

以下に全オプションの要約を種類毎に分けて示す。解説は後の節で行なう。

Overall Options

See 出力の種類の制御オプション.

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

C 言語オプション

See C 方言を扱うオプション.

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

C++ 言語オプション

See 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

警告オプション

See 警告を要求／抑止するオプション.

-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

デバッグオプション

See 読者のプログラムや 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

最適化オプション

See 最適化オプション.

-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

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

See プリプロセッサオプション.

-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

アセンブラのオプション

See アセンブラに渡されるオプション.

-Wa,option

リンカのオプション

See リンクオプション.

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

ディレクトリに関するオプション

See ディレクトリ検索用オプション.

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

ターゲットオプション

See Target Options.

-b machine  -V version

機種依存のオプション

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

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

コード生成オプション

See コード生成規約についてのオプション.

-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

Overall Options: 出力の種類の制御: 実行形式、オブジェクトファイル、アセンブラファイル、前処理済みソース
C Dialect Options: コンパイルされる C 言語の種類の制御
C++ Dialect Options: 様々な C++
Warning Options: どれぐらい口うるさくしますか?
Debugging Options: シンボルテーブル、各種測定、デバッグ用出力
Optimize Options: どれぐらい最適化しますか?
Preprocessor Options: ヘッダファイルとマクロ定義の制御。 make 用依存関係情報の取得。
Assembler Options: アセンブラのオプションの指定方法
Link Options: ライブラリの指定方法など
Directory Options: ヘッダファイルとライブラリのありか。コンパイラを構成する実行形式ファイルのありか。
Target Options: クロスコンパイラや GCC の旧版の動かし方

Node:Overall Options, Next:Invoking G++, Previous:Option Summary, Up:Invoking GCC

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

コンパイル過程は、四つの段階に分けることができる。プリプロセス、コンパイルそのもの、アセンブル、それにリンクであり、必ずこの順番である。前の三つの段階は個々のソースファイルに対して適用され、オブジェクトファイルの生成で終わる。リンクでは、全てのオブジェクトファイル(新しくコンパイルされ、入力としてしていされたもの)を組み合わせて、一つの実行形式ファイルを作る。

指定された入力ファイル毎に、ファイル名のサフィックスからコンパイル過程のどれが実行されるかが決定される。

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: アセンブラソースファイルで、プリプロセスが必要である。
other: オブジェクトファイルは、そのままリンクフェーズに渡される。認識できないサフィックスを持たないファイル名も同じように扱われる。

-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 のどれか一つを使って指定する。組合せによっては(例えば、-x cpp-output -E)、gcc は何もしないことがある。

-c

ソースファイルのコンパイルやアセンブルは行なうが、リンクは行なわない。単にリンク段階を行なわないのである。この場合の最終的な出力は、各ソースファイル毎のオブジェクトファイルという形になる。

デフォルトでは、オブジェクトファイル名は、ソースファイル名のサフィックス .c、.i、.s 等を .o に置き換えたものになる。

認識できない入力ファイルで、コンパイルやアセンブルが要求されないものは無視される。

-S

コンパイル本体の段階で終了する。アセンブルは行なわない。出力は、指定されたアセンブラソースでない各入力ファイルに対して、アセンブラコードファイル形式となる。

デフォルトでは、アセンブラファイル名は、ソースファイル名のサフィックス .c、.i 等を .s に置き換えたものになる。

コンパイルを必要としない入力ファイルは無視される。

-E

プリプロセス段階で終了する。コンパイラ本体は実行しない。出力はプリプロセスされたソースコードの形式で、標準出力に出力される。

プリプロセスを必要としない入力ファイルは無視される。

-o file

出力を指定されたファイル file に置く。これは、生成される出力の種類によらない。実行形式ファイルでも、オブジェクトファイルでも、アセンブラフィアルでも、プリプロセス済の C コードでもかまわない。

出力ファイルは一つしか指定できないので、複数の入力ファイルがある場合に-o を指定するのは、実行形式ファイルを出力とする場合しか意味がない。

-o の指定がない場合は、実行形式ファイルは a.out という名前で、source.suffix というソースファイルのオブジェクトファイルは、source.o という名前で、アセンブラファイルはsource.s という名前で作られ、プリプロセスした C のソースは、標準出力に出力される。

-v

コンパイルの各段階で実行されるコマンドを標準エラー出力に表示する。また、コンパイラドライバプログラム、プリプロセッサ、コンパイラ本体のバージョン番号も合わせて表示する。

-pipe

コンパイルの各段階間での情報の受渡しに、一時ファイルではなく、パイプを使う。これはアセンブラがパイプからの読み出しができないシステムでは動作しない。もちろん、GNU アセンブラを使えば問題ない。

--help

gcc が理解するコマンド行オプションの説明を標準出力に表示する。合わせて -v オプションも指定すると、--help はgcc が起動する色々なプロセスにも渡されので、渡されたプロセスは受付可能なコマンド行オプションを表示することができる。-W オプションを一緒に指定すると、説明が用意されていないコマンド行オプションも表示される。

Node:Invoking G++, Next:C Dialect Options, Previous:Overall Options, Up:Invoking GCC

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

C++ のソースファイル名は普通はサフィックスが、.Cか.cc、.cpp、.c++、.cp、.cxx のどれかになる。プリプロセス済のファイルは、.ii というサフィックスになる。GCC はこのような名前を持つファイルを認識し、コンパイラを C プログラムをコンパイルする場合と同じ方法で起動しても(gcc という名前を使っても)、C++ のプログラムとしてコンパイルを行なう。

しかし、C++ プログラムは C++ 言語を理解するコンパイラだけではなく、クラスライブラリを必要とすることが多い。また、場合によっては、標準入力から読み込んだプログラムや、C++ プログラムであることを示すサフィックスを持たないファイルにあるプログラムを、C++ プログラムとしてコンパイルしたいこともあるだろう。そのような場合向けに、g++ というプログラムがあり、デフォルトの言語を C++ に設定したうえで GCC を呼び出し、さらにC++ ライブラリを自動的にリンクする。多くのシステムでは、g++ というスクリプトは、c++ という名前でもインストールされる。(訳注: g++ は、現在はスクリプトではなく、実行形式になっている。)

C++ プログラムをコンパイルするときは、他の任意の言語のプログラムをコンパイルするときに使うのと同じコマンド行オプションの多くが使用可能である。あるいは、C とそれに関係する言語で意味のあるコマンド行オプションを指定することもできる。あるいは、C++ プログラムのみで意味を持つオプションを指定することもできる。C に関係する言語向けのオプションの説明は、See Options Controlling C Dialect. C++ プログラムでのみ意味を持つオプションの説明は、See Options Controlling C++ Dialect.

Node:C Dialect Options, Next:C++ Dialect Options, Previous:Invoking G++, Up:Invoking GCC

C 方言を扱うオプション

以下のオプションは、コンパイラが受け付ける、C(あるいは、C++ やObjective C のように C から導出された言語)の方言を制御する。

-ansi

ANSI 規格に則った C プログラムをサポートする。

C モードでは、ANSI C 規格の C プログラムを全てサポートする。C++ モードでは ANSI C++ に合致しない GNU の拡張機能を削除する。

このオプションは、ANSI C 規格(C 言語コードをコンパイルするとき)、あるいは ANSI C++ 規格(C++ 言語のコードをコンパイルするとき) と互換性のない GCC の機能をオフにする。オフになる機能は、キーワード asm、typeof、システムの形式を特定する unix や vax 等の定義済マクロ等がある。また、好ましくない、滅多に使われることのない ANSI のトリグラフの機能を有効にする。C コンパイラの場合は、C++ 形式の // によるコメントやキーワード inline を無効にする。C++ コンパイラの場合は、-foperator-names が有効になる。

-ansi を指定しても、別の形のキーワード __asm__、__extension__、__inline__、__typeof__ は使用可能である。もちろん、こういったキーワードを ANSI C プログラムで使うことはないだろうが、-ansi つきで行なわれるコンパイルの際にインクルードされる可能性のあるヘッダファイルで使うと便利である。別の形の定義済マクロ、__unix__ や __vax__ が、-ansi の有無に関わらず、使用可能である。

-ansi オプションを指定しただけでは、非 ANSI プログラムをいわれなく拒絶することはない。拒絶するには、-ansi に加えて-pedantic を指定する必要がある。See Warning Options.

-ansi オプションを指定すると、マクロ __STRICT_ANSI__ が定義済となる。ヘッダファイルの中には、このマクロが定義されていると、ANSI 規格では使用しない関数の宣言やマクロの定義をしないようにするものもある。これは、そのような関数やマクロの名前を別のものに使っているかもしれないプログラムとの干渉を避けるためである。

関数 alloca、abort、exit、_exit は-ansi が指定されると組み込み関数ではなくなる。

-flang-isoc9x

C9X 規格にある機能のサポートを有効にする。特に、C9X のキーワード restrict のサポートを有効にする。

-fstd=

言語規格を指定する。このオプションには値を指定しなければならない。指定できる値は以下の通り。

iso9899:1990 -ansi に同じである。
iso9899:199409 補遺 1 で修正された ISO C である。
iso9899:199x ISO C 9x
c89 -std=iso9899:1990 に同じである。
c9x -std=iso9899:199x に同じである。
gnu89 iso9899:1990 + gnu 拡張であり、デフォルトである。
gnu9x iso9899:199x + gnu 拡張である。

このオプションが指定されていない場合でも、以前の C 規格と矛盾しない限り、より新しい規格の幾つかの機能を使うことが可能である。例えば、-fstd=c9x が指定されていない場合でも__restrict__ を使って良い。

-fno-asm

asm、inline、typeof をキーワードとして認識しない。これらの名前は識別子として使用可能になる。替わりに、__asm__、__inline__、__typeof__ がキーワードとして使える。-ansi を指定すると -fno-asm も有効になる。

C++ では、このオプションはキーワード typeof にだけ影響がある。C++ では、asm と inline は、規格にあるキーワードだからである。キーワード typeof を認識しないようにするには代わりに-fno-gnu-keywords オプションを使っても良い。その場合は、typeof の他に、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

ホスト環境でコンパイルが行なわれていることをアサートする。これにより、-fbuiltin も暗黙に指定される。ホスト環境とは、そこで全標準ライブラリが利用可能であり、main の戻り値型が int であるような環境である。例としては、OS のカーネル以外はほとんどなんでも当てはまる。このオプションは、-fno-freestanding と等価である。

-ffreestanding

孤立した環境でコンパイルが行なわれていることをアサートする。孤立した環境とは、標準ライブラリがない可能性があり、プログラムの起動が必ずしも main から始まらない可能性がある環境である。最もわかりやすい例は、OS のカーネルである。このオプションは、-fno-hosted オプションと等価である。

-trigraphs

ANSI C のトリグラフ機能をサポートする。トリグラフについては問題が多い機能なので、ユーザは詳細を知る必要はないと思う。-ansi を指定すると、-trigraphs が有効になる。

-traditional

旧来の C のコンパイラの機能をいくつかサポートする。特に以下の機能がサポートされる。

全ての extern 宣言が、関数定義の中で書かれているものであっても、グローバルとして扱われる。これは、暗黙の関数宣言も含む。
新しい予約語である、typeof、inline、signed、const、volatile を認識しない。(これらの代わりとして、__typeof__、__inline__ 等を引き続き使うことができる。)
ポインタと整数の比較が常に許される。
整数型 unsigned short と unsigned char は、unsigned int に格上げされる。
許される範囲外の浮動小数点数リテラルはエラーとならない。
ANSI C では一個の不正な前処理トークンとしての数として認識する構文、例えば 0xe-0xd を、代わりに式として取り扱う。
文字列「定数」は必ずしも定数とは限らない。書き込み可能な空間に配置され、同じ値を持つ定数は別途確保される。(-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 プリプロセッサの機能のいくつかをサポートする。特に以下の機能をサポートする。

コメントを一個の空白に変換するのではなくて、完全に除去する。これにより、古い形式のトークン接続が可能になる。
プリプロセッサ制御子では、記号 # が行頭に置く必要がある。
マクロの引数は、マクロ定義の文字列定数の中でも認識される(引数の値は、引用符を付けなくても、このような文脈に現れると文字列化される。)。プリプロセッサは常に、文字列定数は改行で終わると考える。
定義済マクロ __STDC__ は、-traditional を指定すると定義されないが、__GNUC__ は定義される。(なぜなら、__GNUC__ が指示する GNU の拡張は、-traditional によって影響されないからである。) -traditional が指定されるかどうかに依存して異なる動作をするヘッダファイルを書く必要がある場合は、この両方の定義済マクロが定義されるかどうかを調べることで、次の四つの場合を区別することができる。すなわち、GNU C、GNU の旧来の C、他の ANSI C コンパイラ、他の旧来の C コンパイラである。定義済マクロ __STDC_VERSION__ もまた、-traditional を指定した場合には定義されない。これらを含む定義済マクロの詳細については See Standard Predefined.
プリプロセッサは、文字列定数は改行に出会うと終了すると想定している(改行が \ で保護されていない限り)。(-traditonal を付けないと、文字列定数には字面どおりに改行文字を含めることができる。)

-fcond-mismatch

3項演算子式で、二番目と三番目の引数の型が違っても許す。そういう式の値は void である。

-funsigned-char

char 型を、unsigned char のように符号なしとする。

各機種により、char のデフォルトがどうあるべきかが決まっている。デフォルトでは、unsigned char のようになるか、signed char のようになるかのどちらかである。

理想的には、移植性の良いプログラムにするなら、オブジェクトの符号の意味によって、必ず signed char か unsigned char のどちらかを使うべきである。だが、たくさんのプログラムが単なる char 型を使って書かれており、それが書かれたマシンに依存して、符号付きか、符号なしかであるかを想定している。このオプションと、これの逆のオプションにより、デフォルトが反対になっているマシンでプログラムを動作させることができる。

char 型は常に signed char とも unsigned char とも異なる型である。たとえ、動作が必ずどちらか一方と同じであっても。

-fsigned-char

char 型を、signed char のように符号つきとする。

これは、-fno-unsigned-char と同じであり、-funsigned-char の否定形である。同様に、-fno-signed-char は -funsigned-char と同じである。

-fsigned-bitfields

-funsigned-bitfields

-fno-signed-bitfields

-fno-unsigned-bitfields

これらのオプションは、ビットフィールドの宣言に signed も unsigned も使っていないときに、そのビットフィールドが符号付きとなるか符号なしとなるかを制御する。デフォルトでは、そのようなビットフィールドは符号付きである。何故なら、そうすると首尾一貫するからである。int のような基本整数型は符号付きの型である。

だが、-traditional を指定すると、ビットーフィールドは何があろうと全て符号なしになる。

-fwritable-strings

文字列定数を書き込み可能なデータセグメントに格納し、一意化しない。これは、文字列定数に書き込みが可能であると仮定している古いプログラムとの互換性を取るためにある。-traditional オプションを指定してもこの機能が有効になる。

文字列定数に書き込もうとするのは全くの間違いである。「定数」は定数であるべきなのだ。

-fallow-single-precision

-traditional を指定してコンパイルした場合でも、単精度の数学演算を倍精度に格上げしない

K&R C では、オペランドのサイズに関わらずに、全ての浮動小数点演算を倍精度に格上げする。アーキテクチャによっては、単精度の方が倍精度より速いことがある。-traditional オプションを使わなければならない場合で、かつ、オペランドが単精度の場合には単精度の演算を使用したければ、このオプションを指定すれば良い。このオプションは ANSI または GNU C の規約(デフォルト)でコンパイルする場合には、動作に影響はない。

Node:C++ Dialect Options, Next:Warning Options, Previous:C Dialect Options, Up:Invoking GCC

C++ 方言を扱うオプション

この節では、C++ プログラムの場合にのみ意味のあるコマンド行オプションを説明する。だが、GNU コンパイラのオプションの大部分は、プログラムの言語が何であるかに関わらず使うことができる。例えば、firstClass.C というファイルを以下のようにコンパイル出来る。

g++ -g -frepo -O -c firstClass.C

この例では、-frepo だけが、C++ プログラムの場合にだけ意味を持つオプションである。他のオプションは、GCC がサポートしているどの言語でも使用できる。

以下のリストは、C++ プログラムをコンパイルする場合にのみ意味のあるオプションである。

-fno-access-control

全てのアクセス検査を行なわない。これは、主にアクセス制御コードのバグを回避するためにある。

-fcheck-new

operatr new により返されるポインタがヌルでないことを、確保した領域を変更する前に、検査する。最新の ANSI C++ の "Working Paper" では、operator new は決してヌルポインタを返さないことを要求しているので、この検査は普通は必要でない。

このオプションの代わりとなる方法としては、自作の operator new がなんら例外を投げないと指定する方法がある。throw() と宣言すると、g++ は戻り値を検査する。new (nothrow) も参照のこと。

-fconserve-space

非初期化、あるいは実行時初期化グローバル変数を C の場合のように、コモンセグメントに置く。これは、二重定義を検査しないというコストを払ったうえで、実行形式中のスペースを節約する。このオプションをつけてコンパイルしたプログラムが、main() の終了後に、不可解にも異常終了したなら、二つの定義がマージされたために二回破壊されるオブジェクトが存在する可能性がある。

このオプションはもはやほとんどのターゲットで意義がなくなっている。変数を、コモンにすることなく BSS に置く方法がサポートされているからである。

-fdollars-in-identifiers

識別子中に $ を使うことを許す。-fno-dollars-in-identifiers オプションを使って、$ を明示的に使用禁止にすることも可能である。(GNU C は、ほとんどのターゲットでデフォルトで $ を許すが、2,3 の例外がある。) 旧来の C は、識別子の一部に $ を使うことを許している。しかし、ANSI C と C++ は、識別子中の $ を禁止している。

-fno-elide-constructors

C++ 規格は、同じ型の別のオブジェクトを初期化するのにしか使われない一時オブジェクトを作るのを省略する実装を許している。このオプションを指定すると、その最適化を無効にし、g++ が全ての場合にコピー・コンストラクタを呼ぶようにする。

-fexternal-templates

テンプレートの実体化を #pragma interface と implementation に従わせる。テンプレートの実体が生成されるか、テンプレート定義の位置には従わない。詳細については See Template Instantiation。

このオプションは廃止要求が出ている。

-falt-external-templates

-fexternal-templates と同様だが、テンプレートの実体は生成されるか、最初に実体化された場所には従わない。詳細については See Template Instantiation。

このオプションは廃止要求が出ている。

-ffor-scope

-fno-for-scope

-ffor-scope が指定されると、for 文の初期化文で宣言された変数の有効範囲は、その for ループ自体に限られる。これは、C++ 規格のドラフトで規定されている動作である。-fno-for-scope が指定された場合は、for 文の初期化文で宣言された変数の有効範囲は、for 文を囲む有効範囲の最後までとなる。これは、gcc の古いバージョンや、他の(古い) C++ の実装での動作である。

どちらのオプションも指定されない場合のデフォルトは規格に従うが、無効であったり、異なる動作にならない限り、古い形式のコードも警告がでるが許される。

-fno-gnu-keywords

classof、headof、signature、sigof、typeof をキーワードとして認識せず、識別子として使えるようにする。その場合、代わりに__classof__、__headof__、__signature__、__sigof__、__typeof__ を使うことができる。-ansi は -fno-gnu-keywords を含む。

-fguiding-decls

潜在的な関数テンプレートの実体化と同じ型を持つ関数の宣言があったとき、それを普通の関数としてではなく、あたかも実体化を宣言しているかのように扱う。その関数の定義が、同じ翻訳単位の後ろで与えられていれば(あるいは、ターゲットにウィークシンボルがあれば、別の翻訳単位でも良い)、その定義が使われる。定義がければ、そのテンプレートは実体化される。この動作は、1996年9月以前の C++ 言語仕様を反映したものであり、この後、案内宣言(guiding declaration)が仕様から削除された。

このオプションを指定すると、-fname-mangling-version-0 も指定したことになるので、これ以外の名前のエンコード版(name mangling version) と一緒には使えない。ABI を変更する全てのオプション同様、libgcc.a を含む全ての C++ コードをこのオプションの設定を同一にして構築しなければならない。

-fhandle-signatures

抽象型を指定するキーワード、 signature と sigof を認識する。デフォルト(-fno-handle-signatures) では認識しない。

-fhonor-std

namespace std をネームスペースとして、無視せずに取り扱う。g++ の昔のバージョンとの互換性のために、GCC はデフォルトでは namespace-declarations、using-declarations、using-declarations、using-directives、namespace-names が、std を含んでいれば、それを無視する。

-fhuge-objects

short int で表現可能な大きさを越えるオブジェクトについて仮想関数呼び出しをサポートする。ユーザはデフォルトではこのオプションを使うべきでない。このオプションを使う必要があるときは、コンパイラが知らせてくれる。

このオプションは、-fvtable-thunks を使ってコンパイルした場合には役に立たない。

ABI を変更する全てのオプション同様、libgcc を含む全ての C++ コードをこのオプションの設定を同一にして構築しなければならない。

-fno-implicit-templates

暗黙に(すなわち、使うことにより)実体化される非インラインのテンプレート用のコードを生成しない。明示的な実体化に対してのみコードを生成する。より詳細については、See Template Instantiation。

-fno-implicit-inline-templates

インラインテンプレートの暗黙の実体化についてのコードも生成しない。デフォルトはインラインを違ったやり方で取扱うので、最適化ありでもなしでも、コンパイラは明示的な実体化の同じセットが必要になる。

-finit-priority

__attribute__ ((init_priority (n))) をサポートし、ファイルスコープのオブジェクトの初期化順序を制御できるようにする。ELF ターゲットでは、このためには GNU ld 2.10 以降が必要である。

-fno-implement-inlines

スペースの節約のために、#pragma implementation により制御されるインライン展開関数の展開コードのコピーを生成しない。こうすると、インライン展開関数が、どの呼び出し個所でもインライン展開されないと、リンク時のエラーになる。

このオプションは、C++ リンケージの宣言には影響しない。

-fname-mangling-version-n

名前のマングル方法を制御する。バージョン 0 は、2.8 以前の g++ のバージョンと互換である。バージョン1がデフォルトである。バージョン1 は、関数テンプレートの正しいマングルが可能である。例えば、バージョン 0 のマングルでは、foo<int, double> をマングルせず、foo<int, char> は以下の宣言になる。

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

規格がコンパイラが発行する必要はないと規定している診断メッセージを出さないようにする。現在、g++ が発行する診断メッセージで該当するのは、ある名前があるクラス内で複数の意味を持っているというものに対するものである。

-fpermissive

規格に準拠していないコードについてのメッセージをエラーから警告に格下げする。デフォルトでは、g++ は -pedantic を指定しない場合は実質的に -pedantic-errors を指定している。このオプションはそれを逆にする。この動作とオプションは、-pedantic により打ち消される。-pedatnic は GNU C の場合と同様の動作になる。

-frepo

自動的なテンプレートの実体化を有効にする。このオプションは、暗黙に -fno-implicit-templates も設定する。もっと詳しいことについては、 See Template Instantiation。

-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 を指定すると、識別子の名前のマングリングの圧縮形を有効にする。これは、特に、複数回現れる型名とクラス名を認識し、特別に短い 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 * 型の非左辺値として取り扱う。しかし、以前との互換性のために、-fthis-is-variable を指定することで有効とすることができる。

-fvtable-thunks=thunks-version

サンク を使って仮想関数のディスパッチテーブル(vtable)を実装する。vtable を実装する旧来の方法(cfrontの方法)では、仮想関数へのポインタと、呼び出し側で this ポインタを調整するための二つのオフセットを格納していた。新しい実装方法では、あるサンク関数への一個のポインタを格納する。そのサンク関数が必要な調整を行ったうえで目的の関数を呼び出す。

サンクの最初の実装(バージョン1)には、仮想基底クラスに関するバグがあった。このバグは、サンクの実装のバージョン 2 で修正されている。バージョンを 2 に指定すると、バージョン 1 のサンクとの互換性が保たれるが、余分な機械語コードがかかる。バージョン 3 にはこの互換性はない。

このオプションはまた、発見的方法を使って、仮想関数テーブルの生成を制御する。あるクラスに一つでも非インライン仮想関数があれば、その非インライン関数のうちの先頭の一つを含む翻訳単位に、vtable が射出される。

ABI を変更する全てのオプション同様、libgcc.a を含む全ての C++ コードをこのオプションの設定を同一にして構築しなければならない。バージョン 1 とバージョン 2 も非互換である(仮想関数を定義している仮想基底をもつクラスについて)、全てのコードを同じバージョンでコンパイルしなければならない。

このバージョンの gcc では、バージョン 2 のサンクがデフォルトになっているターゲットはない。全てのターゲットで、オプションを指定しないと旧来の実装を使い、-fvtable-thunks を指定するとバージョン 2 のサンクを生成する。

-nostdinc++

ヘッダファイルを、C++ 固有の標準ディレクトリから探さない。だが、他の標準ディレクトリに対しては検索を行なう。(このオプションは、GNU の C++ ライブラリを構築するときに使われる。)

さらに、以下の最適化、警告、コード生成に関するオプションはC++ プログラムの場合にのみ意味を持つ。

-fno-default-inline

クラススコープ内で定義されている関数に inline を仮定しない。See Options That Control Optimization. こういう関数はインライン関数と似たリンケージを持つ。単にデフォルトではインライン展開されないのである。

-Wctor-dtor-privacy (C++ のみ)

クラスが使用不可能だと思える場合に警告を出す。これは、クラスの全てのコンストラクタまたはデストラクタが private であり、friend や public static のメンバ関数が無いときである。

-Wnon-virtual-dtor (C++ のみ)

クラスが、おそらく 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++ のみ)

廃止要求が出ている機能を使った場合の警告を出さない。See Deprecated Features.

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

テンプレート化されていないフレンド関数がテンプレート内で宣言されている時の警告を出さないようにする。明示的なテンプレート指定が g++ でサポートされたことにより、そのフレンドの名前が修飾子無しの識別子(例えば、friend foo(int)) なら、C++ 言語規格ではそのフレンドが通常の、非テンプレート関数を宣言するか定義することを要求している。(14.5.3節。) g++ が明示的な規定を実装する前は、修飾子無しの識別子は、テンプレート化された関数の特定の特殊化と解釈可能であった。この規格に合致しない動作はもはや g++ のデフォルトの動作ではないので、-Wnon-teplate-friend を指定すると GCC は既存のコードの中から潜在的に問題になりそうなところを検査する。これはデフォルトで有効になっている。この新しい動作は -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++ のみ)

多重定義の解決の際に、unsigned 型または列挙型から signed 型への格上げが、同じ大きさの unsigned 型への変換を越えて選択されたときに警告を出す。以前のバージョンの g++ は、unsigned 性を保存することを試みていたが、規格が現在の動作を要求しているのである。

-Wsynth (C++ のみ)

g++の合成の振るまいが cfront のものと一致しない場合に警告する。例えば、

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

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

という例では、g++ はデフォルトの A& operator = (const A&); を合成するが、cfront はユーザ定義の operator = を使う。

Node:Warning Options, Next:Debugging Options, Previous:C++ Dialect Options, Up:Invoking GCC

警告を要求／抑止するオプション

警告とは診断メッセージであり、本来のエラーではないが、潜在的な危険性があったり、誤りが存在する可能性のある構文について報告する。

-W で始まるオプションを指定することで、多くの特定の警告を要求することができる。例えば、-Wimplicit は、暗黙の宣言についての警告を出すよう要求する。これらの特定の警告オプションには、警告を抑止する、-Wno- で始まる否定形がある。例えば、-Wno-implicit というのがある。このマニュアルでは、二つの形式のうちの、デフォルトでは無い方だけを列挙する。

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

-fsyntax-only

文法チェックのみを行ない、それ以上のことは一切行なわない。

-pedantic

ANSI C と ISO C++ に厳密に準拠した場合に要求される警告を全て発する。また、禁じられている拡張を使っているプログラムを全て拒絶する。

ANSI C と ISO C++ に則ったプログラムは、このオプションを指定してもしなくても、正しくコンパイルが行なわれる(まれに、-ansi をオプションを必要とする場合もあるが)、しかし、このオプションを指定しない場合は、GNU の拡張機能と古い形式の C と C++ の機能もサポートされる。このオプションを指定するとそれらは拒絶される。

-pedantic は、先頭と末尾が __ である名前を持つ別キーワードを使う分には警告メッセージを出さない。「衒学的」(pedantic)な警告は、__extension__ に続く式についても抑止される。しかし、このような抜け道を使うのはシステムのヘッダファイルにとどめるべきであり、アプリケーションプログラムは使わないようにしたほうが良い。See Alternate Keywords.

このオプションは役に立つことを目的としていない。単に、これがないと、GCC が ANSI 標準をサポートしていないと文句を言い立てる輩を満足させるためだけのものである。

読者の中には、-pedantic を使って、プログラムが厳密に ANSI C に適合しているかどうかを検査してみる人がいるかもしれない。でもすぐに、期待通りというわけではないことが分かるだろう。-pedantic は、非 ANSI 的な構文のうちの幾つかを見つけるだろう。だが、全部ではない。ANSI C が診断メッセージを要求しているものだけなのである。

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 を返し、適切な型の引数をゼロ個か、二個か、三個を取る関数とすべきである。

-Wmultichar

複数文字からなる文字定数('FOOF' が使われた場合に警告を出す。こういうものは普通はユーザのコードのタイポを示しており、実装定義の値になるので、可搬なコードでは使うべきではないからである。

-Wparentheses

特定の文脈において括弧が省略されている場合に警告を出す。そのような文脈としては、真偽値が期待されている文脈で代入を行なっていたり、優先順位を良く間違える人が多いような演算子が入れ子になっている場合等である。

また、ある else 文がどの if 文に属するか混乱する可能性のある構文についても警告する。以下にその例を挙げる。

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

C では、どの else 文も可能なうちで最も内側の if 文に所属する。これは、プログラマが期待するものと違うことが良くある。上の例では、プログラマが期待するものは字下げで示されているものである。このような混乱の可能性がある場合は、GNU C は、このオプションを指定している場合には、警告を出す。警告を出さない用にするには、最も内側の if 文を括弧で明示的に括って、else が外側の if には属する術が無いことを知らせる。それを反映したコードは以下のようになる。

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

-Wreturn-type

関数定義で、戻り値型の指定がなくデフォルトの int 型になる関数について警告を出す。また、戻り値型が void でない関数内で、戻り値なしの return 文があったら警告を出す。

-Wswitch

switch 文のインデックスが列挙型であり、その列挙型の列挙定数のうち、一個以上について case が欠けている場合に、警告を出す。(ラベル default があれば、この警告はでない。) 列挙値の範囲外の case ラベルがある場合も、このオプションが指定されていれば、この警告が出される。

-Wtrigraphs

トリグラフを見つけたら警告を出す(トリグラフが有効になっている場合)。

-Wunused

変数が、宣言以外の所で使われていない場合、関数が static として宣言されているが定義されていない場合、ラベルが宣言されているが使われていない場合、それに明示的には使われない結果を計算している文がある場合に警告を出す。

使われていない関数の仮引数についての警告を出すには、-W と -Wunused を両方指定しなければならない。

ある式について、この警告を出さないようにするには、単にその式をvoid にキャストする。変数と仮引数、ラベルについてこの警告を出さないようにするには、unused 属性を使う(see Variable Attributes)。

-Wuninitialized

自動変数が、最初に初期化する前に使われている場合に警告をだす。

この警告は、最適化を伴うコンパイルの場合にのみ発生する。なぜなら、この警告を出すには、最適化を行なった場合にのみ計算される、データフロー情報を必要とするからである。-O を指定しない場合には、単にこの警告が出ないだけである。

この警告は、レジスタ割当の候補となる変数に対してだけ出される。このため、volatile と宣言されていたり、アドレスを取っていたり、サイズが 1、2、4、8 バイト以外の変数に対してのみ発生する。また、構造体、共用体、配列についても、たとえそれらがレジスタに置かれていても警告はでない。

それ自身決して使われることのない値を計算するのにだけ使われる変数については警告が出ないことに注意。そういう計算自体が、警告が出力される前のデータフロー解析で削除されるからである。

これらの警告がデフォルトではなくてオプションになっているのは、そのコードにエラーがあるように見えるのに、正しいかもしれないという理由が全て分かるほど GCC は賢くないからである。以下に、どういうふうに発生するかの例を一つ示す。

{
  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 はそのことを知らない。次の例はもう一つの良くあるケースである。

{
  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 命令に出会った場合に警告を出す。このコマンド行オプションを指定すると、システムヘッダファイルの中に知らない pragma があった場合にも警告を出す。これは、警告がコマンド行オプション -Wall によってのみ有効になる場合ではない。

-Wall

上記の全ての -W オプションを組み合わせる。これにより、ユーザによっては疑問に思うような構文のうち、回避したり抑止するよう修正するのが簡単なものついては、それがマクロを使っているものであっても、全てについて警告を出す。

以下の -W... オプションは、-Wall には含まれない。この中の幾つかは、一般にはユーザが問題とは考えないことが多い構文に関して警告するが、検査したくなることも時々あるような問題でもある。その他のものは、ある場合には回避することが必要だったり、あるいは回避することが難しい構文について警告する。これらの警告は、出さないようにするためのコードの簡単な修正方法がないものである。

-W

以下の出来事に対して追加で警告メッセージを出力する。

非 volatile 自動変数が longjmp の呼び出しにより変えられる可能性がある。この警告は最適化コンパイルの場合にのみ可能になる。
コンパイラは setjmp の呼び出ししか分からない。どこで longjmp が呼ばれるかを知ることはできない。実際、シグナルハンドラからは、コードの任意の点で呼び出される可能性がある。その結果、実際には何も問題がなくても警告を受けることがある。これは、longjmp が、実際に問題を起こした箇所から呼び出されることはありえないからである。
関数が値なしでも値付きでもどちらでも戻ることができる。(関数本体の終点を通り抜けるのは、値なしで戻るものと考えられる。) 例えば、以下の関数ではそういう警告が出る。
```
foo (a)
{
  if (a > 0)
    return a;
}
```
式分やカンマ式の左辺に副作用がない。この警告を押さえるためには、使われない式を 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 で動作が異なる構文について警告する。

マクロの引数が、マクロ本体の文字列定数中に現れている。この場合、旧来の C では引数の置換が行なわれるが、ANSI C では定数の一部である。
関数が一つのブロック内で外部宣言され、そのブロック以降で使われている。
switch 文の引数が、long 型である。
非 static 関数の宣言の後に static 版が続く。この構文は、幾つかの古い C コンパイラが受け付けない。

-Wundef

未定義の識別子が、#if 制御子の中で評価される場合に警告を出す。

-Wshadow

あるローカル変数が別のローカル変数を覆い隠す時に警告を出す。

-Wid-clash-len

二つの異なる識別子の最初の len 文字が一致するときに警告する。これは、プログラムをある種の古い、腐ったコンパイラでコンパイルが通るようにするときに役に立つであろう。

-Wlarger-than-len

len バイトより大きなオブジェクトが定義された場合に警告を出す。

-Wpointer-arith

関数型や void 型の「大きさ」に依存しているもの全てについて警告する。GNU C は、void * ポインタと関数へのポインタの計算に便利なように、これらの型の大きさに 1 を割り当てている。

-Wbad-function-cast

関数呼び出しが、マッチしない型にキャストされた時に警告する。例えば、int malloc() が anything * にキャストされると警告を出す。

-Wcast-qual

ポインタが、それが指す型から型修飾子を取り除いた型にキャストされると警告を出す。例えば、const char * を char * にキャストすると警告を出す。

-Wcast-align

ポインタが、その指す型に必要とされるアラインメントが大きくなるようにキャストされると警告を出す。例えば、整数は2バイトまたは4バイト境界でしかアクセスできない機種で、char * を int * にキャストすると警告が出る。

-Wwrite-strings

文字列定数の型を const char[length] とし、その文字列のアドレスを非constの char * 型のポインタにコピーしたときに警告を出させるようにする。この警告は、文字列定数に書き込む可能性のあるコンパイル時コードを見つける助けとなる。ただし、宣言とプロトタイプで const を注意深く使わなければならない。そうしないと、単に邪魔になるだけである。このため、-Wall ではこの警告を出さないようにしている。

-Wconversion

プロトタイプ宣言のために、プロトタイプ宣言がない場合に同じ引数が受けるのとは異なる型変換が起こる場合に警告を出す。これは、固定小数点と浮動小数点間の変換を含み、デフォルトの格上げと同じになる場合を除いて、固定小数点引数の幅や符号を変える変換も含む。

また、負の整数定数式が暗黙に符号なし型に変換されるときも警告を出す。例えば、x が符号なしであれば、x = -1 という代入に警告を出す。しかし、(unsigned) -1 のような明示的なキャストには警告を出さない。

-Wsign-compare

符号付きの値と符号なしの値を比較するとき、符号付きの値が符号なしに変換されると間違った結果になるときに警告を出す。この警告は -W によっても有効になる。-W が出す他の警告を、この警告を出さずに得るには、-W -Wno-sign-compare を使う。

-Waggregate-return

構造体や共用体を返す関数が定義されているか呼び出されていると警告する。(配列を返せる言語でも、警告を引き出す。)

-Wstrict-prototypes

関数が、引数の型指定なしで宣言されていたり、定義されていると警告を出す。(古い形式の関数定義は、引数の型を指定する宣言が事前にあれば、許され、警告は出ない。)

-Wmissing-prototypes

グローバルな関数が事前のプロトタイプ宣言なしで定義された場合に警告を出す。この警告は、関数の定義自身がプロトタイプ宣言を提供している場合でも発行される。目的は、ヘッダファイルで宣言されていないグローバルな関数を検出することにある。

-Wmissing-declarations

グローバルな関数が事前の宣言なしで定義された場合に警告を出す。関数の定義自身がプロトタイプ宣言を提供している場合でも警告が出る。このオプションを使って、ヘッダファイルで宣言されていないグローバルな関数を検出する。

-Wmissing-noreturn

属性 noreturn の候補になる可能性のある関数について警告する。これらはあくまで候補であって、絶対的なものではないことに注意。noreturn 属性を追加する前に、関数が実際に決して戻らないことを自分で注意深く検証する必要がある。そうしないと、微妙なコード生成のバグが持ち込まれる可能性がある。

-Wredundant-decls

同じスコープ内で複数回宣言されているものがあれば警告する。これは、複数回宣言することが有効であり、何も変えない場合でも該当する。

-Wnested-externs

extern 宣言が関数内にあると警告する。

-Winline

関数が inline 宣言されているか、-finline-functions オプションが指定されているときに、インライン展開できない関数があれば警告を出す。

-Wlong-long

long long 型が使われていると警告を出す。これはデフォルトである。この警告メッセージを出さないようにするには、-Wno-long-long を指定する。-Wlong-long と-Wno-long-long オプションは、-pedantic オプションが指定されている場合にのみ、考慮される。

-Werror

全ての警告をエラーに変える。

Node:Debugging Options, Next:Optimize Options, Previous:Warning Options, Up:Invoking GCC

読者のプログラムや 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 向け拡張も含まれる。

-gstabs

stabs 形式のデバッグ情報(サポートされていれば)を GDB 向け拡張なしで生成する。この形式が、ほとんどの BSD システムの DBX で使われるものである。MIPS、Alpha、System V Release 4 のシステムでは、このオプションは、DBX や SDB が理解できない形式の stabs デバッグ情報を生成する。System V Release 4 のシステムでこのオプションを使うにはGNU assembler が必要である。

-gstabs+

stabs 形式のデバッグ情報(サポートされていれば)を、GNU debugger (GDB) だけが理解できる GNU 拡張付きで生成する。この拡張を使うと、他のデバッガは落ちたり、プログラムを読み込めなくなったりする。

-gcoff

デバッグ情報を COFF 形式(サポートされていれば)で生成する。これは、System V Release 4 以前の System V 上の SDB で使われていた形式である。

-gxcoff

デバッグ情報を XCOFF 形式(サポートされていれば)で生成する。これは、IBM の RS/6000 システム上の DBX デバッガで使われている形式である。

-gxcoff+

デバッグ情報を XCOFF 形式(サポートされていれば)で、GNU デバッガ(GDB) だけが理解できる GNU の拡張付きで生成する。この拡張を使うと、他のデバッガは落ちたり、プログラムを読み込めなくなったりする。また、GNU assembler (GAS) 以外のアセンブラだとエラーが出て失敗する。

-gdwarf

デバッグ情報を DWARF のバージョン1の形式(サポートされていれば)で生成する。これは、System V Release 4 のシステム上の SDB で使われている形式である。

-gdwarf+

デバッグ情報を DWARF のバージョン1の形式(サポートされていれば)で、GNU debugger (GDB) だけが理解できる GNU の拡張付きで生成される。この拡張を使うと、他のデバッガは落ちたり、プログラムを読み込めなくなったりする。

-gdwarf-2

デバッグ情報を DWARF のバージョン2の形式(サポートされていれば)で生成する。これは、IRIX 6 上の DBX で使われている形式である。

-glevel

-ggdblevel

-gstabslevel

-gcofflevel

-gxcofflevel

-gdwarflevel

-gdwarf-2level

デバッグ情報を出すことを要求し、かつ、 level でどれぐらいの情報を出すかを指定する。デフォルトのレベルは 2 である。

レベル 1 は、デバッグする予定のないプログラムの一部のバックトレースが取れるぐらいの、最小限の情報を生成する。この情報には、関数と外部変数の記述が含まれるが、ローカル変数と行番号についての情報は含まれない。

レベル 3 は余分の情報を含める。例えば、プログラムに存在する全てのマクロ定義などが含まれる。デバッガの中には、-g3 を使った場合にマクロの展開をサポートするものもある。

-p

prof プログラムによる解析に適したプロファイル情報を書き出す余分のコードを生成する。このオプションは、データを必要とするソースファイルをコンパイルするときに指定しなければならない。また、リンク時にも指定しなければならない。

-pg

gprof プログラムによる解析に適したプロファイル情報を書き出す余分のコードを生成する。このオプションは、データを必要とするソースファイルをコンパイルするときに指定しなければならない。また、リンク時にも指定しなければならない。

-a

基本ブロックに関するプロファイル情報を書き出す余分のコードを生成する。このコードは、各基本ブロックが実行された回数、基本ブロックの開始アドレス、その基本ブロックを含む関数名を記録する。-g が指定されていると、基本ブロックの開始点の行番号とファイル名も記録される。マシン記述で上書きされていない限り、デフォルトの動作はテキストファイル bb.out に追加することである。

このデータは、tcov のようなプログラムで解析することができる。だが、このデータの形式は tcov が想定しているものでないことに注意すること。将来的には GNU gprof を、このデータを処理できるように拡張する必要があるだろう。

-Q

各関数のコンパイルが終わる毎にその関数名を出力し、各パスが終了したときにそのパスについての統計情報を出力する。

-ax

基本ブロックプロファイル用の余分なコードを生成する。実行形式を実行すると、-a が指定されたときに生成されるもののスーパーセットが出力される。出力に付け加わるのは、ジャンプが起きたところの基本ブロックのジャンプ元とジャンプ先のアドレスと、ジャンプの実行回数、それにオプションで実行される基本ブロックの完全な列である。出力は、ファイル bb.out に追加される。

再コンパイルしなくても異なるプロファイリングの面を試すことができる。実行形式ファイルは、ファイル bb.in から関数名のリストを読み込む。プロファイリングは、リストにある関数に入った時点で開始し、その関数の実行が終わった点で終了する。プロファリングから関数を除外する場合は、その名前の前に `-' を付ける。関数名が一意的でない場合は、/path/filename.d:functionname という形式で書くことで区別できる。実行形式ファイルの実行により、利用可能なパス名とファイル名がファイル bb.out に書き出される。

幾つかの関数名には特別な意味がある。

__bb_jumps__: ジャンプ元、ジャンプ先、ジャンプの頻度をファイル bb.out に書き出す。
__bb_hidecall__: 頻度の計数から関数呼び出しを除外する。
__bb_showret__: 頻度の計数に関数からの戻りを含める。
__bb_trace__: 実行された基本ブロックの列をファイル bbtrace.gz に書き出す。このファイルは gzip プログラムを使って圧縮されるので、gzip が PATH に入っていなければならない。popen 関数のないシステムでは、このファイルは bbtrace という名前になり、圧縮は行なわれない。そういうシステムでは、ほんの数秒のプロファイリングでも、非常に巨大なファイルができる。 注意: __bb_hidecall__ と __bb_showret__ はbbtrace.gz に書き出される列には影響しない。

以下に、ファイル bb.in で異なるプロファイリングパラメータを使った短い例を示す。関数 foo には、基本ブロック 1 と 2 があり、関数 main のブロック 3 から二回呼び出されるとする。その呼び出しの後、ブロック 3 は制御を main のブロック 4 に移す。

__bb_trace__ と main をファイル bb.in に入れておくと、0 3 1 2 1 2 4 というブロック列がファイル bbtrace.gz に書き出される。ブロック 2 からブロック 3 へ戻るのは示されていない。これは、ブロックの中のある点へ戻るためで最上位に戻るのではないからである。ブロックアドレス 0 は常に、制御が測定した関数のどこか外側から、トレースに移ったことを意味する。-foo を bb.in に入れると、関数 foo のブロックはトレースから除かれるので、0 3 4 だけが残る。

__bb_jumps__ と main をファイル bb.in に入れると、ジャンプの頻度がファイル 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 は、一個のプログラムの流れのグラフを作り、そのグラフのスパニング・ツリーを探す。スパニング・ツリー上にない弧だけが操作される。GCC は、そういう弧が実行される回数を数えるコードを追加する。ある弧が、あるブロックに対する出口にしかなっていないか、あるいは入り口にしかなっていない場合は、操作を行なうコードをそのブロックに追加することが可能である。その他の場合は、新しい基本ブロックを作り、操作を行なうコードを保持しなければならない。

プログラム中のあらゆる弧が操作されるわけではないので、このオプションを使ってコンパイルしたプログラムは、-a でコンパイルしたプログラムよりは高速である。-a を付けると、プログラム中のあらゆる基本ブロックに操作コードを追加する。トレードオフがある。gcov は、全ての分岐について実行回数を数えている訳ではないので、操作された分岐の実行回数から始めて、プログラムの流れのグラフについて、全グラフが解決するまで繰り返し行なう。このため、gcov は、-a で得られる情報を使うプログラムよりは、いくらか遅くなる。

-fprofile-arcs を指定すると、分岐確率を見積もったり、基本ブロックの実行回数を計算することも可能になる。一般に、基本ブロックの実行回数だけでは、全ての分岐確率を見積もることが出来るだけの情報は得られない。コンパイルしたプログラムが終了するとき、弧の実行回数を sourcename.da というファイルにセーブする。オプション -fbranch-probabilities (see Options that Control Optimization) を指定して再コンパイルして、見積もった分岐確率を使って最適化を行なう。

-ftest-coverage

コードカバレージプログラム gcov 用のデータファイルを作る(see gcov: a GCC Test Coverage Program). このデータファイル名は、ソースファイル名で始まる。

sourcename.bb: 基本ブロックと行番号の対応表である。gcov が行番号毎に基本ブロックの実行回数を対応させるのに使う。
sourcename.bbg: プログラムのフローグラフにおける、全ての弧のリストである。これにより gcov がプログラムのフローグラフを再構築することで、sourcename.da ファイルにある情報から、全ての基本ブロックと弧の実行回数を計算できるようになる。(sourcename.da は、-fprofile-arcs の出力である。)

-Q

各関数がコンパイルされるときにその関数名を出力し、コンパイルの各パスについて、それが終わったときに統計情報を出力する。

-dletters

letters で指定されるコンパイル過程のデバッグ出力を行なう。これは GCC のデバッグに使われる。デバッグ出力のファイル名は、ほとんどが、ソースファイル名にある単語を追加して作られる(例えば、foo.c.rtl や foo.c.jump 等)。以下に letters に指定できる文字とその意味を示す。

b: 分岐確率計算後に、file.bp に出力する。
c: 命令組合せ後に、ファイル file.combine にダンプする。
d: 遅延分岐スケジューリング後に、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: 二回目の命令スケジューリング・パス後に、file.sched2 にダンプする。
s: CSE(時々 CSE に続くジャンプ最適化を含む)後に、file.cse にダンプする。
S: 一回目の命令スケジューリング・パス後に、file.sched にダンプする。
t: 二回目のCSE(時々 CSE に続くジャンプ最適化を含む)後に、file.cse2 にダンプする。
a: 上記のダンプを全て生成する。
m: メモリ使用状況の統計を、最後に標準出力に出力する。
p: アセンブラ出力に、どのパターンと選択肢が使われたかを示すコメントで注釈を付ける。各命令の長さも表示される。
x: 関数をコンパイルするのではなく、単に RTL を生成する。普通、r と一緒に使う。
y: 構文解析中にデバッグ情報を標準エラー出力にダンプする。
A: アセンブラ出力に色々なデバッグ情報で注釈を付ける。

-fdump-unnumbered

デバッグダンプを出力するとき(上の -d オプションを参照のこと)、命令番号と行番号ノートを出力しない。これにより、別のオプションを指定して起動したコンパイルのデバッグダンプに diff を使いやすくなる。特に -g のありなしで有効である。

-fpretend-float

クロスコンパイラを実行する際に、ターゲット機種がホスト機種と同じ浮動小数点形式を使っている振りをさせる。こうすると、実際の浮動小数点定数としては正しくない出力を行なうが、実際の命令列は、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 を使いたいが、libgc.a はリンクしたいというときに便利である。それには以下のようにすれば良い。

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

-print-search-dirs

コンフィギュレーションで指定したインストール先ディレクトリ名と、GCC がプログラムとライブラリを検索するディレクトリのリストを表示する。その他の事は何も行なわない。

これは gcc が installation problem, cannot exec cpp: No such file or directory というエラーメッセージを出したときに役に立つ。このエラーが出たときには、cpp とその他のコンパイラのサブプログラムをgcc があると想定している場所に置くか、あるいはそれらをインストールしたディレクトリを環境変数 GCC_EXEC_PREFIX で指定する必要がある。ここで指定するディレクトリ名には最後に '/' を付けなければならないことに注意して欲しい。See Environment Variables.

Node:Optimize Options, Next:Preprocessor Options, Previous:Debugging Options, Up:Invoking GCC

最適化オプション

以下のオプションは色々な種類の最適化を制御する。

-O

-O1

最適化を行なう。最適化を行なうコンパイルには幾らか余計に時間がかかり、大きな関数についてはたくさんのメモリを余計に使う。

-O を指定しない場合は、コンパイラの目標はコンパイルのコストを小さくすることとデバッグが期待どおりの結果にすることである。各文は独立している。文と文の間にブレークポイントを設定してプログラムを止めたとき、どの変数にも新たな値を代入できるし、プログラムカウンタを変更して、その関数内の他のどの文にも飛ばすことができ、そしてソースコードから期待できる結果と全く同じものが得られる。

-O を指定しないと、register 宣言した変数しかレジスタに割り当てない。コンパイル結果のコードは、-O なしの PCC で作られるよりもやや悪い。

-O を指定すると、コードサイズと実行時間を小さくしようとする。

-O を指定すると、全機種で -fthread-jumps と-fdefer-pop を有効にする。遅延スロットのある機種では-fdelayed-branch をオンにし、フレームポインタなしでもデバッグをサポートできる機種では -fomit-frame-pointer をオンにする。機種によっては、他のオプションをオンにするものもある。

-O2

さらなる最適化を行なう。GCC は、スペース-速度のトレードオフを含まないほとんど全ての最適化を実行する。-O2 を指定した場合は、ループ展開や関数のインライン展開を行なわない。-O と比べると、このオプションはコンパイル時間が増え、生成コードの効率が良くなる。

-O2 を指定すると、ループ展開と関数のインライン展開、それに厳密なエイリアシングを除いた全ての最適化が有効になる。また、全ての機種で -fforce-mem オプションを付け、デバッグと干渉しない機種ではフレームポインタの削除を行なう。

-O3

さらに最適化を行なう。-O3 は -O2 で指定される全ての最適化を行ない、かつ inline-functions オプションを行なう。

-O0

最適化を行なわない。

-Os

サイズについて最適化する。-Os を指定すると、普通はコードサイズを大きくしない -O2 の最適化を全て有効にする。また、コードサイズを小さくするよう設計されたさらなる最適化を実行する。

-O オプションを複数指定した場合は、最適化レベルの数字が付いていてもいなくても、最後に指定したオプションが有効になる。

-fflag という形のオプションは機種独立のフラグを指定する。ほとんどのフラグには、肯定形と否定形がある。-ffoo の否定形は -fno-foo である。以下の表では、どちらか一方の形しか列挙していない。デフォルトでないほうを列挙している。もう一方の形式は、no- を取り除くか、追加すれば良い。

-ffloat-store: 浮動小数点変数をレジスタにストアせず、浮動小数点値をレジスタかメモリから取り出すかどうかを変更する可能性のあるオプションを禁じる。
このオプションを指定すると、68000 の様な機種で、好ましくない余分な精度を使わないようになる。68000 では、(68881 の)浮動小数点レジスタは、double が持つと想定されているよりも余分の精度を保持している。x86 アーキテクチャについても同様である。ほとんどのプログラムにとっては、精度が余分に高いのは利点が加わるだけであるが、幾つかのプログラムはIEEE 浮動小数点の厳密な定義を想定している。そういうプログラムに対しては、適当な中間計算結果を全て変数に格納するようにプログラムを修正しておいて、-ffloat-store を使うこと。
-fno-default-inline: メンバ関数を、それが単にクラススコープで定義されているからといってインライン展開しない(C++ のみ)。これを指定しないと、-O 付きでコンパイルした場合、クラススコープ内で定義されているメンバ関数はデフォルトでインライン展開される。すなわち、メンバ関数名の前に inline を付ける必要がないのである。
-fno-defer-pop: 関数呼び出しの度に常に、その関数から戻るとすぐ引数をポップする。関数呼び出しの後に引数をポップしなければならない機種では、GCC は普通は複数の関数呼び出しについてスタックに引数を蓄積し、それらを全て一度にポップする。
-fforce-mem: メモリオペランドについて算術演算を行なう前に、そのメモリオペランドをレジスタに強制的にコピーさせる。この結果、全てのメモリ参照を潜在的な共通部分式とすることにより、生成コードが良くなる。これらのメモリ参照が共通部分式でない場合は、命令組合せフェーズが独立したレジスタへのロードを削除する必要がある。-O2 を指定するとこのオプションが有効になる。
-fforce-addr: メモリ中のアドレス定数を、それについて算術演算を行なう前にレジスタにコピーすることを強制する。これは、-fforce-mem と同程度に良いコードを生成する。
-fomit-frame-pointer: フレームポインタを必要としない関数については、フレームポインタをレジスタに保持しないようにする。これにより、フレームポインタをセーブ、設定、リストアする命令をなくすことができる。また、多くの関数で利用可能なレジスタが一つ増える。また、機種によってはデバッグが不可能になる。
機種によっては、Vax のように、このオプションの効果がないものもある。標準の呼び出しシーケンスが自動的にフレームポインタを取扱うので、フレームポインタが存在しない振りをしても何もセーブされないからである。マシン記述マクロ FRAME_POINTER_REQUIRED が、ターゲット機種でこのオプションが使えるかどうかを決定する。See Registers.
-fno-inline: キーワード inline に注意を払わない。普通このオプションは、関数のインライン展開を一切行なわせないために使われる。最適化を行なわない場合には、どの関数もインライン展開されることはないことに注意して欲しい。
-finline-functions: 単純な関数を全て呼びだし元に統合する。GCC は、どの関数がこの方法で統合するのに充分単純かを発見的に決定する。
ある関数に対する全ての呼び出しが統合される場合、その関数がstatic と宣言されていれば、普通はその関数はアセンブラコードとしては出力されない。
-finline-limit-n: デフォルトでは、GCC はインライン展開可能な関数の大きさを制限している。このオプションを指定すると、明示的にインライン展開を行うと印を付けられている(すなわち、キーワード inline を指定されているか、C++ のクラス定義の中で定義されている)関数に対するこの制限を調整できるようになる。n は、インライン展開可能な関数の大きさを疑似命令の数で表したものである(パラメータの取扱いは数えない)。デフォルトの n の値は、10000 である。この値を大きくすると、インライン展開されたコードが多くなり、コンパイル時間とメモリ消費量が余計にかかるようになる。この値を小さくすると、普通はコンパイル時間が速くなり、インライン展開されるコードが少なくなる(これは、恐らくプログラムが遅くなることを意味するだろう)。このオプションが特に有効なのは、C++ の再帰的テンプレートに基づくような、インライン展開を非常にたくさん使っているプログラムである。
注意。疑似命令は、今のこの特定の文脈においては、関数の大きさの抽象的な尺度を表す。アセンブリ命令数を表し、その意味はあるリリースと別のリリースで変わる可能性がある。
-fkeep-inline-functions: ある関数に対する呼び出しが全部統合され、その関数が static と宣言されている場合でも、実行時に呼び出し可能な版の関数を別個に出力する。このオプションは extern inline 宣言された関数には影響しない。
-fkeep-static-consts: 最適化を実行しないときに、static const と宣言されている変数が参照されていなくても、その変数を出力する。
GCC はこのオプションをデフォルトで有効にする。最適化の有無に関わらずに、GCC に変数が参照されているかどうかを検査させたい場合は、-fno-keep-static-consts オプションを使えば良い。
-fno-function-cse: 関数のアドレスをレジスタに置かないようにする。ある一定の関数を呼び出す命令は一々その関数のアドレスを明示的に保持するようにする。
このオプションを指定するとコードの効率が悪くなるが、アセンブラの出力を変にいじったような場合、このオプションを指定しないと実行される最適化処理が混乱させられる可能性がある
-ffast-math: このオプションを指定すると、実行速度を最適化するという観点から、ある面で ANSI や IEEE の規則や仕様を破ることを GCC に許す。例えば、このオプションを指定すると、GCC は、sqrt 関数の引数が負にならないとか、浮動小数点値がNaN になることはないという仮定を行なう。
このオプションは、どの -O オプションを指定しても有効になることはない。何故なら、IEEE や ANSI の数学関数の規則／仕様に厳密に基づいて実装されているプログラムの場合は、出力が正しくなくなる可能性があるからである。

以下のオプション群は、特定の最適化を制御する。-O2 オプションは、-funroll-loops と -funroll-all-loops、 -fstrict-aliasing オプションを除く、全ての最適化を実行する。多くの機種では、-O オプションを指定すると、-fthread-jumps と-fdelayed-branch オプションを有効にするが、特定の機種では別の扱いをする。

以下のオプションは、高度な最適化を行ないたいという場合に使うことができる。

-fstrength-reduce

ループの強度削減と繰り返し変数の削除の最適化を実行する。

-fthread-jumps

あるジャンプの分岐先に、別のもう一つの比較があり、その比較が最初の比較に包括されるものかどうかを検査する最適化を実行する。もし包括されるものなら、最初の分岐の分岐先は、二番目の分岐の分岐先かその直後の地点のどちらかに、二番目の比較条件の真偽が既知かどうかに従って、変更される。

-fcse-follow-jumps

共通部分式削除(CSE)の際に、ジャンプ命令のうち、そのジャンプ先に他の経路を通って到達することがないものを探し出す。例えば、CSE がelse 節つきの if 文を見つけると、テストされた条件が偽のときのジャンプに従う。

-fcse-skip-blocks

これは -fcse-follow-jumps に良く似ているが、CSE は条件的にブロックを飛び越すジャンプに従う。CSE が else 節のないif 文を見つけると、if 節の本体のまわりのジャンプに従う。

-frerun-cse-after-loop

ループ最適化の実行後に共通部分式の削除をもう一度実行する。

-frerun-loop-opt

ループ最適化を二回実行する。

-fgcse

グローバル共通部分式削除パスを実行する。このパスは、グローバルな定数とコピーの伝播も実行する。

-fexpensive-optimizations

比較的コストがかかる、マイナーな最適化を幾つか行なう。

-foptimize-register-moves

-fregmove

移動命令中のレジスタ番号を他の単純な命令のオペランドとして再割当を行い、レジスタ結合の量を最大にすることを試みる。これは、とりわけ二オペランド命令の機種で役に立つ。GCC は、-O2 以上が指定されたときはデフォルトでこの最適化を有効にする。

なお、-fregmove と -foptimize-register-moves は同じ最適化である。

-fdelayed-branch

ターゲット機種でサポートされていれば、遅延分岐命令後の利用可能な命令スロットを利用するように命令の並べ替えを試みる。

-fschedule-insns

ターゲット機種でサポートされていれば、必要とされるデータが利用不可能なために起こる実行のストールをなくように命令の並べ替えを試みる。これにより、浮動小数点命令やメモリからのロード命令が遅い機種で、ロード命令や浮動小数点命令の結果が必要になるまでの間、他の命令を発行することが出来るようになる。

-fschedule-insns2

-fschedule-insns とほぼ同じで、違いはレジスタ割当が完了した後にもう一度命令スケジューリングのパスを行なうことである。これがとりわけ役に立つのは、レジスタ数が比較的少なく、メモリからのロード命令が複数サイクルかかるような機種の場合である。

-ffunction-sections

-fdata-sections

ターゲットが任意個数のセクションを使えるなら、各関数やデータ項目をそれぞれ専用のセクションに入れた出力ファイルを作る。関数名やデータ項目名から、出力ファイルでのセクション名が決まる。

リンカに命令空間の参照の局所性を改善する最適化を行なう機能があるシステムでは、これらのオプションを使うと良いだろう。HP-UX の稼働する HPPA プロセッサと Solaris 2 の稼働する SPARC プロセッサにはこのような最適化機能のあるリンカが存在する。ELF オブジェクトファイル形式を使っている他のシステムや、 AIX も将来この最適化機能が加わる可能性がある。

これらのオプションを使うのは、使うことによって著しい御利益がある場合に限ること。これらのオプションを使うと、アセンブラとリンカが作る、オブジェクトファイルや実行形式ファイルが大きくなり、そのために遅くなることもある。このオプションを指定すると、全てのシステムでgprof が使えなくなる。また、-g と共に指定すると、デバッグ時に問題が生じる可能性がある。

-fcaller-saves

関数呼び出しにより破壊されるレジスタに値を割り当てることを可能にする。このために、命令を余分に生成し、呼び出しの前後でレジスタのセーブとリストアを行なう。このような割当が行なわれるのは、他の方法を取るよりも結果的に良いコードが生成される見込みのある場合だけである。

いくつかの機種ではこのオプションが常にデフォルトで有効になっている。そういう機種には、代わりに使うべき、呼び出し時保存レジスタが普通ないのである。

全ての機種で、最適化レベルを 2 以上にするとこのオプションがデフォルトで有効になる。

-funroll-loops

ループ展開最適化を実行する。これは、コンパイル時か実行時に繰り返し回数が決められるループにしか行なわれない。-funroll-loops は、-fstrength-reduce と-frerun-cse-after-loop を含む。

-funroll-all-loops

ループ展開最適化を実行する。これは、全てのループに対して行なわれ、普通はプログラムの実行を遅くする。-funroll-all-loops は、-fstrength-reduce と-frerun-cse-after-loop を含む。

-fmove-all-movables

ループ中の不変な計算を全てループの外に移動する。

-freduce-all-givs

ループ中の一般誘導変数を全て強度削減する。

注意。Fortran で書かれたプログラムをコンパイルするときは-fmove-all-movables と -freduce-all-givs は、最適化を行うとデフォルトで有効になる。

これらのオプションで、生成されるコードがよくなることもあるし、悪くなることもある。結果は、ソースコードでのループに構造に強く依存する。

この二つのオプションは、ループ最適化を改良する色々な方法の有効性を知る役目が終わったなら、いつか削除する予定である。

これらのオプションを使うと、読者のコードの性能にどれぐらい効果があったかを、我々(gcc@gcc.gnu.org と fortran@gnu.org) に知らせて欲しい。これらのオプションが有効になっているときに遅くなったコードに我々は非常に興味がある。

-fno-peephole

機種固有の覗き穴最適化を無効にする。

-fbranch-probabilities

-fprofile-arcs (see Options for Debugging Your Program or gcc)を付けてコンパイルしたプログラムを実行した後、二回目は -fbranch-probabilities を付けてコンパイルすると、分岐が起こる経路の推測に基づく最適化を改良する。

-fbranch-probabilities を指定すると、GCC は REG_EXEC_COUNT というノートを各基本ブロックの最初の命令に付け、REG_BR_PROB というノートを各 JUMP_INSN と CALL_INSN に付ける。これらを使って最適化を向上させることができる。現在、これらは一箇所でしか使われていない。reorg.c で、ある分岐がどちらの方向に起こりそうかを推測する代わりに、REG_BR_PROB の値を使ってより分岐する頻度が高い方向を正確に決定する。

-fstrict-aliasing

GCC に、コンパイルされる言語に取りうる最も厳密な別名規則を取らせる。C(それに C++)の場合は、これにより式の型にもとづく最適化が有効になる。特に、一つの型のあるオブジェクトは、同じアドレスに異なる型のオブジェクトが存在することは、それらの型がほとんど同じでない限り、決してないと仮定する。例えば、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 を指定しても、型もじりは許されるので、メモリは共用体型を通じて参照される。このため、上記のコードは期待どおりに動作する。だが、次のコードは期待どおりにならない。

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

言語固有の別名解析を実行したい言語があれば、ある tree ノードが与えられた場合に、そのノードの別名セットを計算する関数を定義する必要がある。例えば、C 言語のフロントエンドの関数 c_get_alias_set を参照のこと。

Node:Preprocessor Options, Next:Assembler Options, Previous:Optimize Options, Up:Invoking GCC

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

以下のオプションは C プリプロセッサを制御する。C プリプロセッサは、各 C のソースファイルに対して、実際のコンパイルの前に実行される。

-E オプションを指定すると、前処理以外のことはやらない。以下のオプションのうち幾つかは、-E と組み合わせたときにだけ意味を持つ。何故なら、それらはプリプロセッサの出力を実際のコンパイルには適さないものにするからである。

-include file

正規の入力ファイルを処理する前に、file を入力として処理する。事実上、file の内容が先にコンパイルされる。コマンド行で指定した -D オプションと -U オプションはどれも、-include file の前に必ず処理される。これは、コマンド行に書かれた順番には関係しない。全ての -include オプションと -imacros オプションは、書かれた順に処理される。

-imacros file

入力として file を処理し、その結果の出力は捨て去った後で、正規の入力ファイルの処理に取りかかる。file から生成される出力は捨てられるので、-imacros file の唯一の効果は、file でマクロを定義し、正規の入力でそれを使えるようにすることである。

コマンド行で指定した -D オプションと -U オプションはどれも、-imacros file の前に必ず処理される。これは、コマンド行に書かれた順番には関係しない。全ての -include オプションと -imacros オプションは、書かれた順に処理される。

-idirafter dir

ディレクトリ dir を第二のインクルードパスに加える。第二のインクルードパスにあるディレクトリは、ヘッダファイルが第一のインクルードパス(-I が加えたもの)にあるディレクトリには見つからないときに、検索される。

-iprefix prefix

prefix を、後続の -iwithprefix オプションのプレフィックスとして指定する。

-iwithprefix dir

ディレクトリを一個、第二のインクルードパスに追加する。そのディレクトリの名前は、prefix と dir を連結することで作られる。ここで prefix は既出の -iprefix で指定されたものである。プレフィックスをまだ指定していなければ、コンパイラのインストールされたパスを含むディレクトリがデフォルトとして使われる。

-iwithprefixbefore dir

主となるインクルードパスにディレクトリを追加する。追加するディレクトリ名は、-iwithprefix の場合と同じように、prefix と dir をつなげて作られる。

-isystem dir

ディレクトリを一個、第二のインクルードパスの先頭に追加し、それをシステムのディレクトリとして印を付け、標準のシステムディレクトリが受けるのと同じ特別な扱いを受けられるようにする。

-nostdinc

システム標準のディレクトリにあるヘッダファイルを検索しない。-I で指定したディレクトリ(と、適切であればカレントディレクトリ) だけを検索する。-I については See Directory Options。

-nostdinc と -I- を両方使うと、インクルードファイルの検索パスを明示的に指定したディレクトリにだけ限定することができる。

-undef

非標準マクロは何も定義済としない。(アーキテクチャを知らせるフラグも含む。)

-E

C プリプロセッサのみを実行する。指定された全ての C ソースファイルをプリプロセスし、結果を標準出力か指定された出力ファイルに出力する。

-C

プリプロセッサにコメントを除去しないように指示する。-E オプションと合わせて使われる。

-P

プリプロセッサに #line 制御子を生成しないように指示する。-E オプションと合わせて使われる。

-M

各オブジェクトファイルの依存ファイルを記述する make のルールに適した出力を行なうようプリプロセッサに指示する。プリプロセッサは、各ソースファイル毎に make のルールを一つ出力する。そのルールのターゲットは、ソースファイルに対応するオブジェクトファイル名であり、依存ファイルはそのソースファイルが#include している全てのヘッダファイルである。このルールは一行でも良いし、長ければ \-改行で継続しても良い。ルールのリストは、前処理済みの C プログラムではなく、標準出力に出力される。

-M には -E が含まれる。

make のルールの出力を指定するもう一つの方法は、環境変数 DEPENDENCIES_OUTPUT を設定することである(see Environment Variables)。

-MM

-M と同様だが、#include "file" の形式でインクルードされるファイルだけを出力する。#include <file> の形式でインクルードされるシステムのヘッダファイルは除かれる。

-MD

-M と同様だが、依存関係情報は、入力ファイル名の最後の ".c" を".d" に置き換えたファイルに出力される。これは、指定されたファイルをコンパイルしたうえで行なわれる。-M は通常のコンパイルは行なわないが、-MD は行なう。

Mach では、md というユーティリティを使って、複数の依存関係ファイルを一個の依存関係にマージすることができ、make コマンドで使うのに適したものになる。

-MMD

-MD と同様だが、ユーザのヘッダファイルのみを出力し、システムのヘッダファイルは出力しない。

-MG

見当たらないヘッダファイルは生成されたファイルとして扱い、ソースファイルと同じディレクトリにあると仮定する。-MG を指定するなら、-M か -MM のどちらかも指定しなければならない。-MG は、-MD や -MMD と組み合わせるのはサポートされていない。

-H

通常の処理に加えて、使われている各ヘッダファイル名を表示する。

-Aquestion(answer)

question に対する回答 answer を表明する。それは、#if #question(answer) のような前処理の条件文でテストすることができる。-A- は、普通ターゲット機種を記述する標準の表明を無効にする。

-Dmacro

マクロを macro を定義し、文字列 1 をその定義とする。

-Dmacro=defn

マクロ macro を defn として定義する。コマンド行に現れる全ての -D は、どの -U オプションよりも前に処理される。

-Umacro

マクロ macro を未定義にする。-U オプションは、全ての -D オプションの後で、-include と -imacros オプションの前に評価される。

-dM

プリプロセッサに対し、前処理の終了段階で有効なマクロ定義の一覧だけを出力することを指示する。-E と組み合わせて使う。

-dD

プリプロセッサに対し、全てのマクロ定義を出力することを指示する。マクロ定義は、それ以外の出力中に元々の順番で現れる。

-dN

-dD と同様だが、マクロ引数と展開内容が省略される。#define name だけ出力する。

-trigraphs

ANSI C のトリグラフをサポートする。-ansi オプションを指定してもこの効果がある。

-Wp,option

option をプリプロセッサへのオプションとして渡す。option にカンマが入っていると、カンマのところで複数のオプションに分割される。

Node:Assembler Options, Next:Link Options, Previous:Preprocessor Options, Up:Invoking GCC

アセンブラに渡されるオプション

以下のようにして、アセンブラにオプションを渡すことが可能である。

-Wa,option: option をアセンブラにオプションとして渡す。option がコンマを含んでいるなら、コンマで複数のオプションに分割される。

Node:Link Options, Next:Directory Options, Previous:Assembler Options, Up:Invoking GCC

リンクオプション

以下のオプションは、コンパイラがオブジェクトファイルを実行形式ファイルにリンクするときに関係してくる。コンパイラがリンクの段階を行なわないなら、これらは意味がない。

object-file-name

特別に認識されるサフィックスで終わっていないファイル名は、オブジェクトファイルかライブラリを示すものと考えられる。(オブジェクトファイルは、ファイルの内容に従って、リンかによりライブラリと区別される。)リンクが行なわれると、これらのオブジェクトファイルはリンカへの入力として使われる。

-c

-S

-E

これらのオプションのどれかが指定されると、リンカは起動されない。また、オブジェクトファイル名は引数として与えるべきではない。See Overall Options.

-llibrary

リンク時に library という名前のライブラリを検索する。

このオプションをコマンド行のどこに置いたかで違いが出てくる。リンカは、ライブラリとオブジェクトファイルを指定された順番に検索し、処理する。すなわち、foo.o -lz bar.o とした場合、ライブラリ z は、ファイル foo.o の後で、bar.o の前に検索される。もし bar.o が z 内の関数を参照していても、その関数はロードされない。

リンカは、標準のディレクトリのリストからライブラリを探す。次に、見つけたファイルを、正確な名前で指定されたかのように使う。

検索されるディレクトリには、幾つかの標準のシステムディレクトリにの他に、-L で指定したディレクトリが加わる。

普通こうして見つかるファイルはライブラリファイル、すなわちオブジェクトファイルをメンバとするアーカイブファイルである。リンカのアーカイブファイルの扱い方は、アーカイブファイルを走査して、これまでに参照されているが定義はされていないシンボルを定義しているメンバオブジェクトファイルを探す。だが、こうして見つけたファイルが通常のオブジェクトファイルだった場合は、普通にリンクされる。-l オプションを使うのとファイル名を指定するのとの違いは、-l は library の前後にlib と .a を付けて、色々なディレクトリを検索するという点にある。

-lobjc

この特別な -l オプションは、Objective C のプログラムをリンクするのに必要である。

-nostartfiles

リンク時にシステム標準の起動ファイルを使わない。システムの標準ライブラリの方は、-nostdlib や-nodefaultlibs を指定しない限り、普通は使われる。

-nodefaultlibs

リンク時にシステム標準のライブラリを使わない。明示的に指定したライブラリだけがリンカに渡される。-nostartfiles を指定しない限り、標準の起動ファイルが普通は使われる。GCC は System V (それに ANSI C) の環境向けにはmemcmp、memset、memcpy の呼出しを生成し、BSD 環境向けには bcopy と bzero の呼出しを生成するだろう。これらのエントリは通常 libc 内のエントリで解決される。これらのエントリ・ポイントは、このオプションが指定された時には、何か他の仕組みによって提供される必要がある。

-nostdlib

リンク時に、システム標準の起動ファイルやライブラリを使わない。リンカには、起動ファイルは渡されず、ライブラリは明示的に指定したものだけが渡される。GCC は System V (それに ANSI C) の環境向けにはmemcmp、memset、memcpy の呼出しを生成し、BSD 環境向けには bcopy と bzero の呼出しを生成するだろう。これらのエントリは通常 libc 内のエントリで解決される。これらのエントリ・ポイントは、このオプションが指定された時には、何か他の仕組みによって提供される必要がある。

-nostdlib と -nodefaultslibs に影響を受けない標準ライブラリの一つに libcc.a がある。これは、GCC が内部的に使うサブルーチンライブラリであり、特定の機種の機能の不足や、幾つかの言語で特別に必要になる機能を提供するものである。(libgcc.a についてのさらに詳しい議論については、See Interfacing to GCC Output.) ほとんどの場合、他の標準ライブラリを使いたくないときでも libgcc.a は必要になる。言い換えると、-nostdlib や -nodefaultlibs を指定するときには、普通は -lgcc も指定すべきである。これにより、GCC 内部のライブラリサブルーチンに対する未解決参照がなくなることを保証する。(例えば、__main は、C++ のコンストラクタが呼ばれることを保証するのに使われる。see collect2。)

-s

実行形式から、シンボルテーブルと再配置情報を全て削除する。

-static

ダイナミックリンクをサポートしているシステムでは、このオプションを指定すると共有ライブラリとリンクするのを防ぐ。他のシステムでは、このオプションは何の効果もない。

-shared

他のオブジェクトとリンクして実行形式を作ることが可能な共有オブジェクトを生成する。このオプションは全てのシステムではサポートされていない。システムによっては、このオプションを指定するときには、-fpic や-fPIC を指定しなければならない。

-symbolic

共有オブジェクトを構築する際に、グローバルシンボルに対する参照を結合する。未解決の参照については警告を出す(ただし、リンクエディタのオプション -Xlinker -z -Xlinker defs が指定されていない場合)。このオプションをサポートしているシステムは、二、三種類しかない。

-Xlinker option

option をリンカへのオプションとして渡す。これを使うと、GCC には認識する方法が分からない、システム固有のリンカオプションを指定することができる。

引数を取るオプションを渡したい場合は、-Xlinker を二回指定しなければならない。一つはそのオプション用で、もう一つは引数用である。例えば、-assert definitions を渡すには、-Xlinker -assert -Xlinker definitions と書かなければならない。-Xlinker "-assert definitions" と書いたのではうまくいかない。何故なら、これは文字列全体を一個の引数として渡すので、リンカが期待しているのとは違ってしまうからである。

-Wl,option

option をリンカへのオプションとして渡す。option にカンマが含まれていると、コンマのところで複数のオプションに分割される。

-u symbol

シンボル symbol を未定義とし、そのシンボルを定義しているライブラリモジュールを強制的にリンクする。-u をオプションを複数、異なるシンボルに対して使うと、追加でライブラリモジュールを強制的にロードできる。

Node:Directory Options, Next:Target Options, Previous:Link Options, Up:Invoking GCC

ディレクトリ検索用オプション

以下のオプションは、ヘッダファイルやライブラリや GCC の構成部分を検索するディレクトリを指定する。

-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

このオプションは、GCC 自身が使用する実行形式ファイル、ライブラリファイル、インクルードファイル、それにデータファイルを探す場所を指定する。

GCC のドライバプログラムは、サブプログラム cpp、cc1、as、ld の少なくとも一つを実行する。prefix を実行を試みる各プログラムのプレフィックスとして試す。この時、machine/version/ (see Target Options) を付けるのと付けないのを両方試す。

実行すべきサブプログラム毎に、GCC のドライバは、指定されていればまず -B によるプレフィックスを試す。その名前が見つからなかったり、-B が指定されていない場合は、ドライバは標準的なプレフィックスを二つ試す。/usr/lib/gcc/ と /usr/local/lib/gcc-lib/ である。このどちらを使ってもファイル名が見つからない場合は、プログラム名をそのまま使って、環境変数 PATH で指定されたディレクトリを検索する。

-B によるプレフィックスは、リンカがリンクするライブラリにも適用されるディレクトリ名を指定する。これは GCC がこのオプションをリンカ用の -L オプションに変換するからである。またプリプロセッサがインクルードするファイルにも適用される。GCC がこのオプションをプリプロセッサ用の -isystem オプションに変換するからである。この場合、GCC は include をプレフィックスに追加する。

実行時サポートファイル libgcc.a も、必要であれば -B によるプレフィックスを使って検索することが可能である。-B で指定した場所に見つからなかった場合には、上述の二つの標準プレフィックスが試される。さらなる検索は行なわれない。これらの手段で見つからなかったファイルは、リンク時にそのまま残される。

-B によるプレフィックス指定と良く似たもう一つのプレフィックス指定方法として環境変数 GCC_EXEC_PREFIX を使う方法がある。See Environment Variables。

-specs=file

GCC が標準の specs ファイルを読み込んだ後にfile を処理し、ドライバプログラムである gcc が、cc1 やcc1plus、as、ld 等に渡すべきオプションを決定するときに使うデフォルトを変更する。-specs=file はコマンド行で複数指定することができ、その場合、左から右へ順に処理される。

Node:Target Options, Next:Submodel Options, Previous:Directory Options, Up:Invoking GCC

ターゲット機種とコンパイラバージョンの指定

デフォルトでは、GCC は、読者が使っているのと同じタイプの機種用にコードをコンパイルする。だが、クロスコンパイラとしてインストールすることもでき、何か他のタイプの機種用にコンパイルすることも可能である。実際、色々なコンフィギュレーションの GCC を、色々な対象機種に対して、同じにインストールすることが可能である。そのどれを使うかは、-b オプションで指定する。

さらに、GCC の旧版と新版も同じにインストールすることができる。そのうちの一つ(おそらく最新版)がデフォルトになるが、別の版を使いたいときもあるだろう。

-b machine

引数 machine は、コンパイルの対象となる機種を指定する。GCC をクロスコンパイラとしてインストールしたときに便利である。

machine の値は、GCC をクロスコンパイラとしてコンフィギュレーションしたときに指定したのと同じ機種になる。例えば、クロスコンパイラがconfigure i386v としてコンフィギュレーションされているなら、これは System V の稼働する 80386 マシン向けにコンパイルすることを意味し、このコンフィギュレーション向けのコンパイラを実行するには-b i386v と指定する。

-b を指定しないときは、普通は読者が使っているのと同じ型の機種用にコンパイルすることになる。

-V version

引数 version は、実行する GCC のバージョンを指定する。これは複数のバージョンがインストールされているときに役に立つ。例えば、version が 2.0 なら、GCC のバージョン 2.0 を実行することを意味する。

-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 はそのまま動き続け、実際の仕事を行なう他の実行形式(プリプロセッサ、コンパイラ本体、アセンブラ、リンカ)を起動するのである。しかし、ドライバプログラムは実際の仕事は何もしないので、ドライバプログラムが、指定したターゲットとバージョン向けのものでなくても普通は問題はない。

ドライバプログラムがターゲット機種に関わってくる唯一の点は、機種固有の特別なオプションのパースと取扱いである。しかし、これも他の実行形式ファイル同様、指定したバージョンとターゲット機種用のディレクトリに置かれているファイルにより制御されるのである。結局、ドライバプログラムが一個インストールしてあれば、どのターゲット機種やバージョンを指定しても適合するのである。

ただし、ドライバプログラムの実行形式は、一つ重要な点を取り扱う。デフォルトのバージョンとターゲット機種である。このため、ドライバプログラムの実体を、異なるターゲットとバージョン向けに別々にコンパイルして、別の名前でインストールしても良い

たとえば、バージョン 2.0 用のドライバを ogcc としてインストールし、バージョン 2.1 用のを gcc としてインストールしておくと、gcc というほうのコマンドはデフォルトでバージョン 2.1 を使い、ogcc のデフォルトは 2.0 になる。しかし、どちらのコマンドを使っても、-V オプションを使えばどちらのバージョンでも指定できるのである

Node:Submodel Options, Next:Code Gen Options, Previous:Target Options, Up:Invoking GCC

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

以前、標準のオプション -b について議論した。-b は、全く異なるターゲット機種、例えば、Vax と 68000 と 80386 用の、インストール済みコンパイラの中から選ぶ。

加えて、各ターゲット機種には -m で始まる、機種固有の特別なオプションがあり、例えば、68010 か 68020 かといった、色々なハードウェアのモデルやコンフィギュレーションから選択することができる。GCC が一つインストールされていれば、指定したオプションに従って、どのモデルやコンフィギュレーションに対してもコンパイルが可能である。

GCC のあるコンフィギュレーションでは、追加で特別なオプションをサポートしているものもある。これは、普通は、同じプラットフォーム上の他のコンパイラとの互換性のためにある。

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

M680x0 Options:
VAX Options:
SPARC Options:
Convex Options:
AMD29K Options:
ARM Options:
Thumb Options:
MN10200 Options:
MN10300 Options:
M32R/D Options:
M88K Options:
RS/6000 and PowerPC Options:
RT Options:
MIPS Options:
i386 Options:
HPPA Options:
Intel 960 Options:
DEC Alpha Options:
Clipper Options:
H8/300 Options:
SH Options:
System V Options:
TMS320C3x/C4x Options:
V850 Options:
ARC Options:
NS32K Options:

Node:M680x0 Options, Next:VAX Options, Previous:Submodel Options, Up:Submodel Options

M680x0 オプション

以下の -m オプションが 68000 シリーズ向けに定義されている。これらのオプションのデフォルト値は、コンフィギュレーション時に68000 のどの形式が選択されたかに依る。最も共通する選択のデフォルトは以下の通り。

-m68000

-mc68000

68000 用の出力を生成する。これは、コンパイラが68000 ベースのシステム向けにコンフィギュレーションされた場合のデフォルトである。

このオプションは、68000 や EC000 のコアを持つマイクロコントローラ、68008、68302、68306、68307、68322、68328、68356 等に対して使う。

-m68020

-mc68020

68020 用の出力を生成する。これは、コンパイラが68020 ベースのシステム向けにコンフィギュレーションされた場合のデフォルトである。

-m68881

浮動小数点数向けの 68881 の命令を含む出力を生成する。これは、-nfp がコンフィギュレーション時に指定されない限り、ほとんどの 68020 のシステムのデフォルトである。

-m68030

68030 用の出力を生成する。これは、コンパイラが68030 ベースのシステム向けにコンフィギュレーションされた場合のデフォルトである。

-m68040

68040 用の出力を生成する。これは、コンパイラが68040 ベースのシステム向けにコンフィギュレーションされた場合のデフォルトである。

このオプションは、68040 ではソフトウェアでエミュレートしなければならない 68881/68882 の命令を禁止する。読者の 68040 システムにこれらの命令をエミュレートしなければならないようなコードがなければ、このオプションを使うこと。

-m68060

68060 用の出力を生成する。これは、コンパイラが68060 ベースのシステム向けにコンフィギュレーションされた場合のデフォルトである。

このオプションは、68060 ではソフトウェアでエミュレートしなければならない 68881/68882 の命令を禁止する。読者の 68060 システムにこれらの命令をエミュレートしなければならないようなコードがなければ、このオプションを使うこと。

-mcpu32

CPU32 向けの出力を生成する。これは、GCC が CPU32 ベースのシステム向けにコンフィギュレーションされたときのデフォルトである。

このオプションは、CPU32 や CPU32+ のコアを持つマイクロコントローラ、68330、68331、68332、68333、68334、68336、68340、68341、68349、68360 等に対して使う。

-m5200

520X 「コールドファイア」シリーズの CPU 用にコードを生成する。GNU C コンパイラが 520X ベースのシステム用にコンフィギュレーションされた場合のデフォルトになる。

このオプションは、5200 のコアを持つマイクロコントローラ、MCF5202、MCF5203、MCF5204、MCF5202 等に使う。

-m68020-40

68040 用に出力を生成するが、新しい命令は何も使わない。この結果、68020/68881 や 68030、68040 のどれでも比較的効率の良いコードが生成される。生成されたコードでは、68881 の命令を使っており、68040 ではエミュレートされる。

-m68020-60

68060 用に出力を生成するが、新しい命令は何も使わない。この結果、68020/68881 や 68030、68040 のどれでも比較的効率の良いコードが生成される。生成されたコードでは、68881 の命令を使っており、68060 ではエミュレートされる。

-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 命令で戻る。この命令は戻る際に引数をポップする。これにより、呼び出し側では、引数をポップする必要がないので命令を一個節約できる。

この呼び出し規約は、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 用の、公表されているほとんどのアプリケーション・バイナリ・インターフェース仕様とは異なるアライメントを取るように置く。

Node:VAX Options, Next:SPARC Options, Previous:M680x0 Options, Up:Submodel Options

VAX オプション

以下の -m オプションが Vax 用に定義されている。

-munix: 特定のジャンプ命令群(aobleq 等)を出力しない。これらの命令は、Vax 用の Unix アセンブラが長い範囲を越えて扱うことが出来ないものである。
-mgnu: GNU アセンブラを使ってアセンブルを行なうという想定のもとに、上記のジャンプ命令群を出力する。
-mg: 浮動小数点形式として、d 形式の代わりに g 形式で出力する。

Node:SPARC Options, Next:Convex Options, Previous:VAX Options, Up:Submodel Options

SPARC オプション

以下の -m オプションが SPARC ではサポートされている。

-mno-app-regs

-mapp-regs

-mapp-regs を指定するとグローバルレジスタの 2 ～ 4 を使うコード生成を行なう。グローバルレジスタの 2 ～ 4 は SPARC SVR4 ABI がアプリケーション用に予約している。これがデフォルトである。

完全に 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 の実装は存在しない。全ての実装で、これらの命令のうちの一つに対してはトラップハンドラを起動し、そのトラップハンドラでその命令の効果をエミュレートしている。トラップハンドラのオーバーヘッドにより、ABI のライブラリルーチンを呼び出すよりもずっと遅くなる。このため、-msoft-quad-float オプションがデフォルトになっている。

-mno-epilogue

-mepilogue

-mepilogue を指定すると(デフォルトで指定される)、GCC は、各関数の最後に必ず関数の出口用のコードを生成する。関数の途中での出口(例えば、C 言語の return 文)に対しては、関数の最後の出口コードへのジャンプを生成する。

-mno-epilogue を指定すると、GCC は関数の出口毎に出口コードを展開する。

-mno-flat

-mflat

-mflat を指定すると、GCC はセーブ／リストアを行なう命令群を生成せず、「平らな」あるいは、一個のレジスタウィンドウ呼出し規約を使う。この方式では、%i7 をフレームポインタとして使い、通常のレジスタウィンドウ方式と互換性がある。どちらのコードもお互いに混ぜて使うことができる。ローカルレジスタと入力レジスタ(0-5)は、以前として呼出し時セーブレジスタとして取り扱われ、必要に応じてスタックにセーブされる。

-mno-flat を指定すると(デフォルト)、GCC はセーブ／リストア命令群を生成し(末端関数は除く)、通常の操作モードになる。

-mno-unaligned-doubles

-munaligned-doubles

double は 8 バイト境界に整列されると仮定する。これがデフォルトである。

-munaligned-doubles を指定すると、double 型が 8 バイト境界に整列させられるのは、別の型に含まれている場合や、絶対アドレスを持つ場合に限られる。その他の場合は、4 バイト境界に整列される。このオプションを指定すると、滅多にないことだが、他のコンパイラで生成したコードとの互換性の問題を回避できる。これはデフォルトにはなっていない。性能が、とりわけ浮動小数点コードの場合に悪くなるからである。

-mv8

-msparclite

この二つのオプションは、SPARC アーキテクチャの版のうちの一つを選択する。

デフォルトでは(富士通の SPARClite 用にコンフィギュレーションを行なわない限り)、GCC は、SPARC アーキテクチャの v7 用のコードを生成する。

-mv8 を指定すると、SPARC v8 用のコードを生成する。v7 との違いは、v7 にはないが v8 には存在する整数乗算と整数除算命令を生成する点にある。

-msparclite を指定すると SPARClite 用のコードを生成する。これは、整数乗算と整数除算、スキャン(ffs)命令を追加する。これらの命令は、v7 にはないが SPARClite に存在する。

これらのオプションは廃止要求が出ており、将来の GCC のリリースで削除される予定である。これらは、-mcpu=xxx に置き換えられることになる。

-mcypress

-msupersparc

この二つのオプションは、どのプロセッサ向けに最適化を行なうかを選択する。

-mcypress を指定すると(これがデフォルトである)、GCC は Cypress CY7C602 というチップ向けにコードを最適化する。このチップは、SPARCstation/SPARCserver 3xx シリーズで使われているものである。このオプションは、古目の SPARCstation 1、2、IPX 等にも適している。

GCC は SuperSPARC チップ向けにコードを最適化する。このチップは、SPARCstation 10、1000、2000 シリーズで使われているものである。このオプションは、完全な 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 が行なうような命令セットやレジスタセットの設定は行なわない。

-mcpu=
cpu_type に使えるのと同じ値が -mtune=cpu_type に対しても使える。ただし意味のある値は、特定の CPU の実装を選ぶものだけである。それは次の通り。cypress、supersparc、hypersparc、f930、f934、sparclite86x、tsc701、ultrasparc。

-malign-loops=num

ループを 2 の num 乗バイト境界に整列させる。-malign-loops が指定されていない場合のデフォルトは 2 である。

-malign-jumps=num

ジャンプ先の命令のみを 2 の num 乗境界に整列させる。-malign-jumps が指定されていない場合のデフォルトは 2 である。

-malign-functions=num

関数の開始位置を 2 の num 乗境界に整列させる。-malign-functions が指定されていない場合のデフォルトは、32 ビットの SPARC の場合は 2 で、64 ビットの SPARC の場合は 5 である。

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

-mlittle-endian: リトルエンディアン・モードで動作するプロセッサ用のコードを生成する。
-mlive-g0: レジスタ %g0 を普通のレジスタとして取り扱う。GCC は必要に応じて、引き続き、このレジスタを上書きするが、常に 0 を読み出すという想定は行なわない。
-mbroken-saverestore: save 命令と restore 命令の自明でない形を使わないコードを生成する。SPARCLET プロセッサの初期のバージョンは、引数付きのsave 命令と restore 命令を正しく扱えない。引数なしなら正しく扱うことができる。引数なしの save 命令は、現在のウィンドウポインタをインクリメントするが、新しいスタックフレームは割り当てない。ウィンドウのオーバフローのトラップハンドラが、この場合を、割り込みハンドラと同じように正しく扱うことを想定している。

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

-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 ビットの大きさであり、どちらも任意の位置(リンク時に決定される)から開始可能である。レジスタ %g4 が、データセグメントの基底を指す。ポインタは依然として 64 ビットである。
-mstack-bias
-mno-stack-bias: -mstack-bias を指定すると、GCC はスタックポインタと、それにもしあればフレームポインタは、スタックフレームの参照を作るときに、オフセットに -2047 を加えなければならないと想定する。

Node:Convex Options, Next:AMD29K Options, Previous:SPARC Options, Up:Submodel Options

Convex オプション

Convex 向けには以下の -m オプションが定義されている。

-mc1: C1 用の出力を生成する。これで生成したコードは Convex のどの機種でも動作する。プリプロセッサ用シンボル __convex__c1__ が定義される。
-mc2: C2 用の出力を生成する。C1 には存在しない命令を使う。スケジューリング、それにその他の最適化は、C2 で最大の性能を発揮するように選ばれる。プリプロセッサ用シンボル __convex__c2__ が定義される。
-mc32: C32xx 用の出力を生成する。C1 には存在しない命令を使う。スケジューリング、それにその他の最適化は、C32 で最大の性能を発揮するように選ばれる。プリプロセッサ用シンボル __convex__c32__ が定義される。
-mc34: C34xx 用の出力を生成する。C1 には存在しない命令を使う。スケジューリング、それにその他の最適化は、C34 で最大の性能を発揮するように選ばれる。プリプロセッサ用シンボル __convex__c34__ が定義される。
-mc38: C38xx 用の出力を生成する。C1 には存在しない命令を使う。スケジューリング、それにその他の最適化は、C38 で最大の性能を発揮するように選ばれる。プリプロセッサ用シンボル __convex__c38__ が定義される。
-margcount: 各引数リストの前に、引数の個数の入ったワードを置くようにコードを生成する。こうすると普通の CC と互換性があり、引数個数のワードを必要とするプログラムが幾つかある。GDB やそのたのソースコードレベルのデバッガは引数個数のワードを必要としない。引数の個数情報は、シンボルテーブルに入っているからである。
-mnoargcount: 引数個数のワードを省略する。これがデフォルトである。
-mvolatile-cache: 揮発性の参照をキャッシュする。これがデフォルトである。
-mvolatile-nocache: 揮発性参照について、データキャッシュを迂回させ、全てメモリを見に行かせる。これは、標準の同期命令を使わない、マルチプロセッサコードの場合にのみ必要になる。揮発性の位置に対する非揮発性の参照を作るのは、動作する必要はない。
-mlong32: long 型を int 型と同じ 32 ビットにする。これがデフォルトである。
-mlong64: long 型を long long 型と同じ 64 ビットにする。このオプションは、サポートするライブラリが存在しないので、使えない

Node:AMD29K Options, Next:ARM Options, Previous:Convex Options, Up:Submodel Options

AMD29K オプション

以下の -m オプションが AMD Am29000 用に定義されている。

-mdw: DW ビットが立っている、すなわちバイト演算と半語演算がハードウェアにより直接サポートされていることを想定したコードを生成する。これがデフォルトである。
-mndw: DW ビットが立っていないことを想定したコードを生成する。
-mbw: システムが、バイトと半語の書き込み演算をサポートしていることを想定したコードを生成する。これがデフォルトである。
-mnbw: システムが、バイトと半語の書き込み演算をサポートしていないことを想定したコードを生成する。-mnbw は -mndw を含む。
-msmall: スモール・メモリ・モデルを使う。このモデルでは、関数のアドレスは全て一個の 256KB のセグメント内にあるか、256k より小さい絶対アドレスにあることを想定する。これにより、call 命令が、const、consth、calli という命令列の代わりに使われる。
-mnormal: ノーマル・メモリ・モデルを使う。呼出し側関数が同一ファイル内にあるときのみcall 命令を生成し、それ以外の場合は calli 命令を生成する。これは、各ファイルが 256 KB 未満であれば動作する。この場合、実行形式全体は 256KB より大きくても良い。これがデフォルトである。
-mlarge: 常に calli 命令を使う。一個のファイルをコンパイルしたときに256KB より大きなコードになりそうなら、このオプションを指定する。
-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 を指定すると、mstrim 命令と storem 命令を分離して扱えない 29k プロセッサ(29050 を除く、現時点でのほとんどの 29000 チップ)を取り扱う。
-mno-reuse-arg-regs
-mreuse-arg-regs: -mno-reuse-arg-regs を指定すると、入力引数レジスタは引数をそのままコピーするためにしか使わないようにする。これは、宣言されたものよりも少ない引数で関数を呼び出しているのを検出する手助けになる。
-mno-impure-text
-mimpure-text: -mimpure-text を、-shared に加えて指定すると、享有オブジェクトをリンクするときにリンカに -assert pure-text オプションを渡さないようにする。
-msoft-float: 浮動小数点用ライブラリ呼び出しを含む出力を生成する。警告: 必要となるライブラリは GCC の一部ではない。普通はその機種の通常の C コンパイラの機能が使われるが、クロスコンパイルの場合はこれをそのまま行なうことはできない。クロスコンパイルの場合は、適切なライブラリ関数を自分で用意しなければならない。
-mno-multm: multm 命令や multmu 命令を生成しない。これは、これらの命令向けにトラップ・ハンドラを持たない幾つかの組み込みシステムで有用である。

Node:ARM Options, Next:Thumb Options, Previous:AMD29K Options, Up:Submodel Options

ARM オプション

以下のオプションが、Advanced RISC Machines (ARM) アーキテクチャ用に定義されている

-mapcs-frame: コードを正しく実行するには必ずしも必要でなくても、全ての関数に対し、ARM Procedure Call Standard に準拠したスタックフレームを生成する。このオプションと合わせて -fomit-frame-pointer を指定すると、末端関数に対してはスタックフレームが生成されなくなる。デフォルトは -mno-apcs-frame である。
-mapcs: これは -mapcs-frame の別名である。
-mapcs-26: プログラムカウンタが 26 ビットのプロセッサ用で、APCS 26 ビットオプション用の関数呼出し規約に準拠するコードを生成する。このオプションは、GCC の以前のリリースの -m2 オプションと-m3 オプションを置き換えるものである。
-mapcs-32: プログラムカウンタが 32 ビットのプロセッサ用で、APCS 32 ビットオプション用の関数呼出し規約に準拠するコードを生成する。このオプションは、GCC の以前のリリースの -m6 オプションを置き換えるものである。
-mapcs-stack-check: あらゆる関数(実際に少しでもスタックスペースを使うもの)の入り口点で、利用可能なスタックスペースの量を検査するコードを生成する。利用できるスタックスペースが足りなければ、関数 __rt_stkovf_split_small か __rt_stkovf_split_big のどちらかが呼ばれる。どちらが呼ばれるかは必要とするスタックスペース量による。実行時システムはこれらの関数を提供する必要がある。デフォルトは、-mno-apcs-stack-check である。生成されるコードが小さいからである。
-mapcs-float: 浮動小数点引数を浮動小数点レジスタを使って渡す。これは APCS の変種の一つである。このオプションは、ターゲットハードウェアが浮動小数点ユニットを持っている場合や、浮動小数点算術演算を大量に実行する場合にお勧めである。デフォルトは -mno-apcs-float である。整数しか含まないコードは、-mapcs-float を指定するとわずかにサイズが大きくなるためである。
-mapcs-reentrant: 再入可能な位置独立コードを生成する。これは、-fpic オプションを指定するのに等価である。デフォルトは、-mno-apcs-reentrant である。
-mthumb-interwork: ARM と THUMB の命令セット間での呼びだしをサポートするコードを生成する。このオプションを指定しないと、二つの命令セットを一つのプログラムの中で使用するのは信頼性に欠けることになる。デフォルトは、、-mno-thumb-interwork である。-mthumb-interwork を指定するとわずかにコードが大きくなるためである。
-mno-sched-prolog: 関数プロローグ内の命令並べ替えや、関数プロローグの命令と関数本体の命令の混合を抑止する。これは、全ての関数がある見分けの付く命令のセットで始まる(あるいは、実際には、異なる関数プロローグの幾つかのセットから一つ選んだもので始まる)ということを意味する。この情報を使って、関数が実行可能なコード断片の中にあるときにその関数の開始位置を見つけることが出来る。デフォルトは、-sched-prolog である。
-mhard-float: 浮動小数点命令を含む出力を生成する。これがデフォルトである。
-msoft-float: 浮動小数点用ライブラリ呼び出しを含む出力を生成する。警告: 必要となるライブラリは全ての ARM ターゲットで利用可能であるわけではない。普通はその機種の通常の C コンパイラの機能が使われるが、クロスコンパイルの場合はこれをそのまま行なうことはできない。クロスコンパイルの場合は、適切なライブラリ関数を自分で用意しなければならない。
-msoft-float を指定すると、出力ファイル中の呼び出し規約が変わる。このため、プログラム全体をこのオプションでコンパイルしないといけない。特に、GCC 付属のライブラリである、libgcc.a をコンパイルするときに、-msoft-float を指定してコンパイルしないとこのライブラリが正しく動作しない。
-mlittle-endian: リトル・エンディアンモードで動作するプロセッサ向けのコードを生成する。これが、全ての標準のコンフィギュレーションのデフォルトである。
-mbig-endian: ビッグ・エンディアンモードで動作するプロセッサ向けのコードを生成する。デフォルトは、リトル・エンディアンのプロセッサ向けのコードをコンパイルするものである。
-mwords-little-endian: このオプションは、ビッグ・エンディアンのプロセッサ用のコードを生成する時にのみ適用される。語に関してはリトル・エンディアンだが、バイトに関してはビッグ・エンディアンのコードを生成する。すなわち、バイト順は 32107654 という形である。このオプションを使うのは、ビッグ・エンディアンの ARM プロセッサ用のコードで、GCC の 2.8 以前のバージョンで生成されたものとの互換性が必要な場合だけにすべきである。
-mshort-load-bytes: 半語(例えば short型)をロードするのに、整列していないアドレスから語をロードすることで行なうことをしない。ターゲットの中には、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 ライブラリとリンクするための下準備として、標準のシンボルをいくらか修正する必要がある。このオプションはその修正過程を抑止する。後処理プログラムは、GCC がクロスコンパイラとして構築された場合には決して実行されない。
-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= は -mcpu= の別名であり、古いバージョンの GCC をサポートするためある。
-march=<name>: これは、ターゲットの ARM のアーキテクチャ名を指定する。GCC はこの名前を使って、アセンブリコードを生成するときに使える命令の種類を決定する。このオプションは、-mcpu= オプションと組み合わせて、あるいは-mcpu= オプションの代わりに使うことが出来る。指定できる名前は、armv2、armv2a、armv3、armv3m、armv4、armv4t である。
-mfpe=<number>
-mfp=<number>: これは、ターゲットで利用可能な浮動小数点エミュレーションのバージョンを指定する。指定できる値は 2 と 3 である。-mfp= は-mfpe= の別名であり、古いバージョンの GCC をサポートするためにある。
-mstructure-size-boundary=<n>: 全ての構造体と共用体の大きさを、このオプションで指定するビット数の倍数に切り上げる。指定可能な値は 8 と 32 である。デフォルト値は、ツール・チェーンが異なると変わってくる。COFF 向けのツールチェーンに対してはデフォルト値は 8 である。大きい数を指定すればそれだけ高速で効率の良いコードが得られるが、プログラムのサイズも大きくなる。指定できる二つの値は、潜在的には互換性がない。一方の値でコンパイルしたコードは、もう一方の値でコンパイルしたコードやライブラリと合わせたとき、それが構造体や共用体を使った情報を交換している場合には、動作するとは必ずしも期待できない。プログラマの皆さんには 32 という値を使うことをお勧めする。ツールチェーンの将来のバージョンでは、デフォルトがこの値になる可能性があるからである。
-mabort-on-noreturn: noreturn 関数の最後に関数 abort の呼出しを生成する。これは関数が戻ろうとしたときに実行される。

Node:Thumb Options, Next:MN10200 Options, Previous:ARM Options, Up:Submodel Options

Thumb オプション

-mthumb-interwork: THUMB と ARM の命令セット間での呼びだしをサポートするコードを生成する。このオプションを指定しないと、二つの命令セットを一つのプログラムの中で使用するのは信頼性に欠けることになる。デフォルトは、、-mno-thumb-interwork である。このオプションを指定するとわずかにコードが小さくなるためである。
-mtpcs-frame: 全ての末端でない関数に対し、Thumb Procedure Call Standard に準拠するスタックフレームを生成する。(末端関数とは、他の関数を全くよばない関数である。) デフォルトは -mno-tpcs-frame である。
-mtpcs-leaf-frame: 全ての末端関数に対し、Thumb Procedure Call Standard に準拠するスタックフレームを生成する。(末端関数とは、他の関数を全くよばない関数である。) デフォルトは -mno-tpcs-leaf-frame である。
-mlittle-endian: リトル・エンディアンモードで動作するプロセッサ向けのコードを生成する。これは、全ての標準のコンフィギュレーションのデフォルトである。
-mbig-endian: ビッグ・エンディアンモードで動作するプロセッサ向けのコードを生成する。
-mstructure-size-boundary=<n>: 全ての構造体と共用体の大きさを、このオプションで指定するビット数の倍数に切り上げる。指定可能な値は 8 と 32 である。デフォルト値は、ツール・チェーンが異なると変わってくる。COFF 向けのツールチェーンに対してはデフォルト値は 8 である。大きい数を指定すればそれだけ高速で効率の良いコードが得られるが、プログラムのサイズも大きくなる。指定できる二つの値は、潜在的には互換性がない。一方の値でコンパイルしたコードは、もう一方の値でコンパイルしたコードやライブラリと合わせたとき、それが構造体や共用体を使った情報を交換している場合には、動作するとは必ずしも期待できない。プログラマの皆さんには 32 という値を使うことをお勧めする。ツールチェーンの将来のバージョンでは、デフォルトがこの値になる可能性があるからである。

Node:MN10200 Options, Next:MN10300 Options, Previous:Thumb Options, Up:Submodel Options

MN10200 オプション

以下の -m オプションが Matushita MN10200 アーキテクチャ向けに定義されている。

-mrelax: リンカに対し、緩和最適化パスを実行して分岐、呼出し、絶対メモリアドレスを短くする。このオプションは、最終的なリンク段階のコマンド行で使った場合にだけ効果がある。
このオプションを使うと、シンボリックデバッグができなくなる。

Node:MN10300 Options, Next:M32R/D Options, Previous:MN10200 Options, Up:Submodel Options

MN10300 オプション

以下の -m オプションが松下 MN10300 アーキテクチャ用に定義されている。

-mmult-bug: MN10300 プロセッサの乗算命令のバグを回避するようにコードを生成する。これはデフォルトである。
-mno-mult-bug: MN10300 プロセッサの乗算命令のバグを回避するようなコードを生成しない。
-mrelax: リンカに対し、緩和最適化パスを実行して分岐、呼出し、絶対メモリアドレスを短くする。このオプションは、最終的なリンク段階のコマンド行で使った場合にだけ効果がある。
このオプションを使うと、シンボリックデバッグができなくなる。

Node:M32R/D Options, Next:M88K Options, Previous:MN10300 Options, Up:Submodel Options

M32R/D オプション

以下の -m オプションが三菱 M32R/D アーキテクチャ用に定義されている。

-mcode-model=small: 全てのオブジェクトが下位 16MB の範囲のメモリに収まり(そうなっているとアドレスが ld24 命令でロード可能である)、全てのサブルーチンは、bl 命令で到達可能であると想定する。これはデフォルトである。
特定のオブジェクトのアドレス可能性は、model 属性で設定可能である。
-mcode-model=medium: オブジェクトは 32 ビットのアドレス空間のどこにあっても良く(GCC はそれらのアドレスをロードするのに seth/add3 命令を生成する)、全てのサブルーチンは、bl 命令で到達可能であると想定する。
-mcode-model=large: オブジェクトは 32 ビットのアドレス空間のどこにあっても良く(GCC はそれらのアドレスをロードするのに seth/add3 命令を生成する)、サブルーチンは、bl 命令では到達できない可能性があると想定する(GCC は、さらに遅い seth/add3/jl 命令列を生成する)。
-msdata=none: 小データ領域を使わないようにする。変数は .data、bss、.rodata のどれか一つに置かれる(section 属性が指定されればその限りではない)。これはデフォルトである。
小データ領域は、セクション .sdata と .sbss からなる。section 属性でこのどちらかのセクションを指定すれば、オブジェクトを小データ領域に明示的に置くことができる。
-msdata=sdata: 小さいグローバルなデータと静的なデータを小データ領域に置きはするが、それらを参照するために特別なコードは生成しない。
-msdata=use: 小さいグローバルなデータと静的なデータを小データ領域に置き、それらを参照するために特別なコードを生成する。
-G num: num バイト以下の大きさのグローバルなオブジェクトと静的なオブジェクトを、普通のデータセクションや bss セクションではなく、小データセクションや小 bss セクションに置く。num のデフォルト値は 8 である。このオプションを有効にするためには、-msdata オプションでsdata か use のどちらかを指定しなければならない。
全てのモジュールは、-G num で同じ値を指定してコンパイルする必要がある。num の値が違っていると、正しく動作するかどうかわからない。動作しない場合は、リンカがエラーメッセージを出すはずである。正しくないコードは生成されない。

Node:M88K Options, Next:RS/6000 and PowerPC Options, Previous:M32R/D Options, Up:Submodel Options

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 形式デバッグ情報を出力するとき、正規のフレームアドレス、つまり関数の入り口点でのスタックポインタ(レジスタ 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-optimze-arg-area は、88open 規格に一致する。デフォルトでは、引数領域の最適化は行なわない。

-mshort-data-num

データへの参照をより小さくするために、それらをr0 相対にする。これにより、値をロードするのが一個の命令でできるようになる(普通は命令二個必要である)。どのデータ参照が影響を受けるかは、このオプションで指定する num で調整できる。例えば、-mshort-data-512 と指定すると、影響を受けるデータ参照は512 バイト未満の変位を含むものである。-mshort-data-num は、num が 64k より大きいと効果がない。

-mserialize-volatile

-mno-serialize-volatile

逐次的な揮発性メモリ参照の一貫性を保証するコードを生成する、あるいは生成しない。デフォルトでは一貫性は保証される。

MC88110 プロセッサによりなされるメモリ参照の順序は、その参照を必要とする命令の順序には必ずしも一致しない。特に、ロード命令は先行するストア命令よりも先に実行される可能性がある。このような並べ替えは、逐次的な揮発性メモリ参照の一貫性を、マルチプロセッサの場合には破る。一貫性が保証されなければならない場合は、GNU C は必要に応じて特別な命令を生成し、強制的に適切な順序で実行させるようにする。

MC88100 プロセッサはメモリ参照の並べ替えを行なわないので、常に逐次的な一貫性を提供する。だが、GNU C はデフォルトでは、 -m88100 を指定した場合でも、特別な命令を生成し、一貫性を保証するので、その生成コードは M88110 プロセッサでも実行可能である。M88100 プロセッサでしか実行しないつもりなら、-mno-serialize-volatile を指定することができる。

一貫性を保証するために生成された余分のコードは、読者のアプリケーションの実行速度に影響を及ぼす可能性がある。保証しなくても大丈夫であることが判っているなら、-mno-serialize-volatile を指定することができる。

-msvr4

-msvr3

SVR4 に関係した拡張機能をオンにしたり(-msvr4)、オフにする(-msvr3。これは以下の事項を制御する。

どのアセンブラ構文の変種を使うか。
-msvr4 を指定すると、C プリプロセッサが、SVR4 で使われている#pragma weak を認識するようになる。
-msvr4 を指定すると、GCC は SVR4 で使われている追加の宣言制御子を発行する。

-msvr4 は、m88k-motorola-sysv4 と m88k-dg-dgux という m88k のコンフィギュレーションではデフォルトになっている。-msvr3 は、その他の全ての m88k のコンフィギュレーションでデフォルトになっている。

-mversion-03.00

このオプションは廃れており、無視される。

-mno-check-zero-division

-mcheck-zero-division

整数のゼロによる除算が検出されることを保証するコードを生成するかどうかを指定する。デフォルトでは検出されることが保証される。

MC88100 プロセッサの幾つかのモデルでは、特定の条件下でゼロによる整数除算をトラップできないことがある。デフォルトでは、そういうプロセッサで実行される可能性があるコードをコンパイルするときは、GCC はゼロになる除数を明示的に検査し、検出された場合には例外番号 503 でトラップするコードを生成する。-mno-check-zero-division を使うと、MC88100 プロセッサで実行するように生成されたコードに対し、この様な検査を行なわない。

GNU C は、MC88110 プロセッサが、ゼロによる整数除算が起こった場合全てを正しく検出できることを想定している。-m88110 を指定したときは、-mcheck-zero-division も -mno-check-zero-division もどちらも無視され、除数がゼロになるかどうかを明示的に検査するコードは生成されない。

-muse-div-instruction

MC88100 プロセッサでの符号付き整数除算に対し、div 命令を使う。デフォルトでは、div 命令は使われない。

MC88100 プロセッサでは、符号付きの整数除算命令(div)は、オペランドが負の場合は OSへのトラップを発生する。OS は透過的に演算を完了することができるが、実行時間が非常にかかることになる。デフォルトでは、MC88100 プロセッサで実行される可能性があるコードをコンパイルするときは、GCC は符号付き整数除算を、符号なし整数除算命令(divu)を使ってエミュレートする。これにより、OS へのトラップという大きなペナルティを回避している。このエミュレーションのコストは、実行時間とコードサイズの両面で小さくなっている。読者のプログラムで、重要な符号付き整数除算が二つの負でないオペランドに対して実行される範囲なら、div 命令を直接使うのが望ましい。

MC88110 プロセッサの場合は、div 命令(divs 命令としても知られている)は、OS へのトラップを発生することなく、負のオペランドを処理する。-m88110 が指定されたときは、-muse-div-instruction は無視され、div 命令が符号付き整数除算に使われる。

INT_MIN を -1 で割った結果は未定義であることに注意して欲しい。特に、このような割り算の動作は、-muse-div-instruction の有無で変わってくる。

-mtrap-large-shift

-mhandle-large-shift

シフトビット数が 31 ビットを越えるものを検出するコードを挿入する。これらのオプションは、それぞれ、そのようなシフト命令をトラップするか、正しく取り扱うコードを生成する。デフォルトでは、GCC はシフトのビット数が大きくても特に何もしない。

-mwarn-passed-structs

関数が引数や戻り値として構造体を渡したときに警告する。構造体の渡し方の規約は、C 言語が進化するにつれて変わってきており、移植上の問題の元になることが多い。デフォルトでは、GCC はこの警告は出さない。

Node:RS/6000 and PowerPC Options, Next:RT Options, Previous:M88K Options, Up:Submodel Options

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 について、二つの関係のある命令セットをサポートしている。POWER 命令セットは、最初の RS/6000 システムで使われていたrios チップセットでサポートされていた命令セットである。PowerPC 命令セットは、モトローラのマイクロプロセッサ MPC5xx、MPC6xx、MPC8xx と IBM のマイクロプロセッサ 4xx のアーキテクチャである。

どちらのアーキテクチャも他方のサブセットにはなっていない。しかし、両方でサポートされている共通の命令の大きなサブセットがある。POWER アーキテクチャをサポートするプロセッサには MQ レジスタが含まれている。

これらのオプションを使って、自分のプロセッサで利用可能な命令を指定することができる。これらのオプションのデフォルト値は、GCC のコンフィギュレーション時に決定される。-mcpu=cpu_type を指定すると、これらのオプションの指定を上書きする。上に列挙したオプションではなく、-mcpu=cpu_type オプションを使うことをお勧めする。

-mpower オプションを指定すると、POWER アーキテクチャにのみ存在する命令を生成したり、MQ レジスタを使うことを GCC に許す。-mpower2 を指定すると、-power を含んだうえに、POWER2 アーキテクチャには存在するが、元々の POWER アーキテクチャには存在しない命令を生成することを GCC に許す。

-mpowerpc オプションを指定すると、PowerPC アーキテクチャの32ビット版のサブセットにのみ存在する命令の生成を GCC に許す。-mpowerpc-gpopt を指定すると、-mpowerpc を含んだうえに、PowerPC アーキテクチャの General Purpose グループのオプションの命令を使うことができるようになる。これには、浮動小数点平方根命令も含まれる。-mpowerpc-gfxopt を指定すると、-mpowerpc を含んだうえに、PowerPC アーキテクチャの Graphics グループのオプションの命令を使うことができるようになる。これには浮動小数点選択命令も含まれる。

-mpowerpc64 オプションを指定すると、GCC は完全な PowerPC64 アーキテクチャにある 64 ビット命令を追加で生成し、GPR を 64 ビットの倍語量として取り扱う。デフォルトは -mno-powerpc64 である。

-mno-power と -mno-powerpc の両方を指定すると、GCC は両方のアーキテクチャに共通する命令サブセットに加えて幾つかの特別なAIX 共通モード呼出し命令のみを使い、MQ レジスタは使わないようになる。-mpower と -mpowerpc を両方指定すると、どちらのアーキテクチャのどの命令でも使うことが可能になり、MQ レジスタも使うようになる。Motorola MPC601 にはこの両方を指定すること。

-mnew-mnemonics

-mold-mnemonics

どのニーモニックを生成されるアセンブラコードで使うかを選ぶ。-mnew-mnemonisc を指定すると、PowerPC アーキテクチャ向けに定義されたアセンブラニーモニックを使って出力する。一方、-mold-mnemonisc を指定すると、POWER アーキテクチャ用に定義されたアセンブラニーモニックを使用する。一つのアーキテクチャでしか定義されていない命令は、ニーモニックは一種類しかない。GCC は、一種類しかないニーモニックは、どのオプションが指定されたかに関係なく、それを使う。

GCC では使われているアーキテクチャに適したニーモニックをデフォルトで使う。-mcpu=cpu_type を指定すると、これらのオプションの値が変わることもある。クロスコンパイラを作るのでない限り、普通は -mnew-mnemonics や -mold-mnemonics を指定するのではなく、代わりにデフォルトを受け入れるようにすべきである。

-mcpu=cpu_type

アーキテクチャ型、レジスタ使用法、ニーモニックの選択、命令スケジューリングのパラメータを、機種 cpu_type 用に設定する。cpu_type として使えるのは、rs6000、rios1、rios2、rsc、601、602、603、603e、604、604e、620、740、750、power、power2、powerpc、403、505、801、821、823、860、common である。-mcpu=power、-mcpu=power2、-mcpu=powerpc は、POWER、POWER2、それに純粋な PowerPC(つまり、MPC601 は含まない) アーキテクチャの汎用の機種を指定する。スケジューリング用には、適切な汎用プロセッサモデルを想定する。

オプション -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=604e, -mcpu=620、-mcpu=403、-mcpu=505、-mcpu=801, -mcpu=821、-mcpu=823、-mcpu=860、-mcpu=powerpc のどれかを指定すると、-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 共通モード呼び出しを加えたものだけを使い、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 がやる設定は行なわない。cpu_type の値としては、-mcpu=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) の生成の仕方を変える。TOC は各実行形式ファイル毎に作られる。-mfull-toc オプションがデフォルトで選ばれている。その場合、GCC は、プログラム内の一意的で自動変数でない変数の参照一つ毎に、少なくとも一つのTOC エントリを割り当てる。GCC は、浮動小数点定数も TOC に置く。だが、TOC に入れられるエントリ数は、16,384 しかない。

リンカが、利用可能な TOC 空間が溢れたというエラーメッセージを出した場合は、TOC の使用量を -mno-fp-in-toc オプションや-mno-sum-in-toc オプションで減らすことができる。-mno-fp-in-toc を指定すると、浮動小数点定数を TOC に置くのを止める。-mno-sum-in-toc を指定すると、あるアドレスとある定数の和を TOC に置く変わりに、実行時にその和を計算するコードを生成する。この二つのオプションは、どちらか指定しても良いし、両方指定しても良い。どちらも、TOC 空間を保存することの代償として、ほんのちょっとだけ、コードが遅く、大きくなる。

両方指定してもまだ TOC が足りないという場合は、代わりに-mminimal-toc を指定すること。このオプションを指定すると、GCC は、各ファイルに一つしか TOC エントリを作らない。このオプションを指定すると、遅く、大きなコードを生成するが、TOC 空間は非常にわずかしか使わない。このオプションを使うのは、あまり頻繁に実行されないコードしか入っていないファイルに限るのが良いだろう。

-maix64

-maix32

AIX の 64 ビット ABI と呼出し規約を有効にする。すなわち、64ビットポインタ、64ビット long 型、それにそれらをサポートするのに必要なインフラストラクチャが有効になる。-maix64 を指定すると、-mpwoerpc64 と -mpowerpc も暗に指定される。一方、-maix32 を指定すると 64ビット ABI を無効にし、暗に -mno-powerpc64 を指定する。GCC のデフォルトは-maix32 である。

-mxl-call

-mno-xl-call

AIX で、プロトタイプ付きの関数に対する浮動小数点引数を、引数用 FPR に加えて、レジスタセーブ領域(register save area, RSA) を越えてスタックに渡される。AIX の呼出し規約は、引数のアドレスをとり、宣言されたよりも少ない引数しか渡さない関数を呼び出す、K&R の曖昧な場合を扱うように拡張されているが、最初はドキュメントにその記述がなかった。AIX XL コンパイラは、RSA に収まらない浮動小数点引数は、最適化なしでサブルーチンが最適化なしでコンパイルされたときは、スタックからアクセスする。浮動小数点引数を常にスタックに格納するのは効率が悪いし、滅多に必要にならない。このため、このオプションはデフォルトでは有効になっていない。必要になるのは、AIX XL コンパイラで最適化なしでコンパイルしたサブルーチンを呼び出すときだけである。

-mthreads

AIX Threads をサポートする。pthreads を使って書かれたアプリケーションを、特別なライブラリとスタートアップコードにリンクして、アプリケーションの実行を可能にする。

-mpe

IBM RS/6000 SP の Parallel Environment (PE) をサポートする。メッセージパッシングを使うように書かれているアプリケーションは、特別なスタートアップコードとリンクして、そのアプリケーションが正しく動作するようにする。システムには PE が標準の位置(/usr/lpp/ppe.poe/)にインストールされていなければならない。標準の位置にない場合は、-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-upate を指定すると、スタックポインタが更新されるのと直前のフレームのアドレスが更新されるのと間に間があき、割り込みやシグナルを越えてスタックフレームを歩き回るコードがあると、正しくないデータを受け取る可能性がある。

-mfused-madd

-mno-fused-madd

浮動小数点積和命令を使う(使わない)コードを生成する。これらの命令は、ハードウェアによる浮動小数点演算が使われる場合はデフォルトで生成される。

-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 システムでは、「System V Application Binary Interface, PowerPC processor supplement」の 1995年3月版ドラフトに従った呼び出し規約を使って、コードをコンパイルする。GCC を powerpc-*-eabiaix でコンフィギュレーションしない場合は、これがデフォルトになる。

-mcall-sysv-eabi

-mcall-sysv と -meabi の両方のオプションを指定する。

-mcall-sysv-noeabi

-mcall-sysv と -mno-eabi の両方のオプションを指定する。

-mcall-aix

System V.4 と組み込み PowerPC システムでは、AIX で使われている呼び出し規約に類似の呼び出し規約を使ってコードをコンパイルする。GCC を powerpc-*-eabiaix でコンフィギュレーションした場合は、これがデフォルトになる。

-mcall-solaris

System V.4 と組み込み PowerPC システムでは、Solaris オペレーティングシステム向けにコードをコンパイルする。

-mcall-linux

System V.4 と組み込み PowerPC システムでは、Linux ベースの GNU システム向けにコードをコンパイルする。

-mprototype

-mno-prototype

System V.4 と組み込み PowerPC システムでは、全ての可変数引数関数への呼出しは、正しくプロトタイプ宣言されていると想定する。想定しない場合は、GCC は、プロトタイプ宣言なしの呼出し毎にその直前に命令を一個挿入して、関数が可変数引数を取る場合、浮動小数点値が浮動小数点レジスタで渡されたかどうかを指示するために、条件コードレジスタ(CR)のビット 6 を立てるか落とすかしなければならない。-mprototype を指定すると、プロトタイプ宣言された可変数引数関数への呼出しでのみ、ビット 6 を立てたり落としたりする。

-msim

組み込み PowerPC システムで、起動モジュールが sim-crt0.o であり、標準 C ライブラリは libsim.a と libc.a であることを仮定する。これは、powerpc-*-eabisim のデフォルトである。

-mmvme

組み込み PowerPC システムで、起動モジュールが crt0.o であり、標準 C ライブラリは libmvmem.a と libc.a であることを仮定する。

-mads

組み込み PowerPC システムで、起動モジュールが crt0.o であり、標準 C ライブラリは libads.a と libc.a であることを仮定する。

-myellowknife

組み込み PowerPC システムで、起動モジュールが crt0.o であり、標準 C ライブラリは libyka.a と libc.a であることを仮定する。

-memb

組み込み PowerPC システムで、ELF フラグヘッダの PPC_EMB ビットを立てることで、eabi 拡張再配置情報が使われることを指示する。

-meabi

-mno-eabi

System V.4 と組み込み PowerPC システムで、組み込みアプリケーション・バイナリ・インターフェース(Embedded Applications Binary Interface (eabi)) を遵守する(遵守しない)。eabi は、System V.4 の仕様に対する一群の修正である。-meabi を選ぶと、スタックは 8 バイト境界に整合が行なわれ、関数 __eabi が main から呼び出され、eabi 環境の設定が行なわれ、さらに -msdata オプションを使った場合、r2 と r13 の両方を使い、二つの小さなデータ領域を指すことができるようになる。-mno-eabi を選ぶと、スタックは 16 バイト境界に整合が行なわれ、main から初期化関数を呼び出さず、-msdata オプションを指定しても、r13 だけが使われ、小さなデータ領域を一個しか指さない。-meabi オプションは、GCC を powerpc*-*-eabi* オプションのどれか一つを使ってコンフィギュレーションした場合は、デフォルトで有効になる。

-msdata=eabi

System V.4 と組み込み PowerPC システムでは、小さな初期化済みでconst のグローバルデータと静的データをセクション .sdata2 に置く。.sdata2 セクションはレジスタ r2 が指す。小さな初期化済みで非 const のグローバルデータと静的データをセクション .sdata に置く。.sdata セクションはレジスタ r13 が指す。小さな非初期化グローバルデータと静的データをセクション .sbss セクションに置く。.sbss は、セクション .sdata の直後に置かれる。オプション -msdata=eabi は、-mrelocatable オプションとは互換性がない。-msdata=eabi はまた、-memb オプションも設定する。

-msdata=sysv

System V.4 と組み込み PowerPC システムでは、小さなグローバルデータと静的データをセクション .sdata に置く。.sdata セクションはレジスタ r13 が指す。小さな非初期化グローバルデータと静的データをセクション .sbss に置く。.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 セクションではなく、小さなdata あるいは小さな bss セクションに置く。デフォルトでは、num は8 である。-G num は、リンカにも渡される。全てのモジュールを同じ値の -G num でコンパイルする必要がある。

-mregnames

-mno-regnames

System V.4 と組み込み PowerPC システムでは、アセンブリ言語出力で記号形式を使ったレジスタ名を出力する(出力しない)。

Node:RT Options, Next:MIPS Options, Previous:RS/6000 and PowerPC Options, Up:Submodel Options

IBM RT オプション

以下の -m オプションが IBM RT PC 用に定義されている。

-min-line-mul: 整数乗算にたいして、インライン展開したコード列を使う。これがデフォルトである。
-mcall-lib-mul: 整数の乗算にたいして lmul$$ を呼び出す。
-mfull-fp-blocks: IBM 推奨の最少量の詰めものスペースを取り込んだ、完全な大きさの浮動小数点データブロックを生成する。これがデフォルトである。
-mminimum-fp-blocks: 浮動小数点データブロックに余分な詰めもののスペースを取り込まない。この結果、コードは小さくなるが実行は遅くなる。詰めもののスペースを動的に確保しなければならないからである。
-mfp-arg-in-fpregs: IBM の呼出し規約と互換性のない呼出し規約を使う。この規約では、浮動小数点引数は浮動小数点レジスタで渡される。varargs.h と stdargs.h は、このオプションを指定した場合、浮動小数点演算と一緒に使うことはできない。
-mfp-arg-in-gregs: 浮動小数点引数に対し、通常の呼出し規約を使う。これがデフォルトである。
-mhc-struct-return: 一語より大きな構造体をレジスタではなく、メモリに入れて返す。これは MetaWare HighC(hc) コンパイラとの互換性のためにある。Portable C Compiler(pcc) との互換性を取るには-fpcc-struct-return オプションを使うこと。
-mnohc-struct-return: 一語を越えるいくつかの構造体を、レジスタで渡したほうが良い場合はレジスタで渡す。これはデフォルトである。IBM 提供のコンパイラとの互換性を取るためには、-fpcc-struct-return オプションか-mhc-struct-return オプションを使う。

Node:MIPS Options, Next:i386 Options, Previous:RT Options, Up:Submodel Options

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 の命令を発行する。これがデフォルトである。r3000 が、この ISA レベルのデフォルトの CPU タイプである。
-mips2: MIPS ISA のレベル 2 の命令(branch likely, square root 命令)を発行する。r6000 が、この ISA レベルのデフォルトの CPU タイプである。
-mips3: MIPS ISA のレベル 3 の命令(64ビット命令)を発行する。r4000 が、この ISA レベルのデフォルトの CPU タイプである。
-mips4: MIPS ISA のレベル 4 の命令(条件付き move 命令、プリフェッチ命令、強化された FPU 命令)を発行する。r8000 は、この ISA レベルのデフォルトの cpu type である。
-mfp32: 32個の32ビット浮動小数点レジスタが利用可能であることを仮定する。これはデフォルトである。
-mfp64: 32個の64ビット浮動小数点レジスタが利用可能であることを仮定する。これは、-mips3 オプションが指定されたときのデフォルトである。
-mgp32: 32個の32ビット汎用レジスタが利用可能であることを仮定する。これはデフォルトである。
-mgp64: 32個の64ビット汎用レジスタが利用可能であることを仮定する。これは、-mips3 オプションが指定されたときのデフォルトである。
-mint64: long 型と int 型を強制的に 64 ビット幅にする。デフォルトについての説明とポインタの大きさについては-mlong32 を参照のこと。
-mlong64: long 型を強制的に 64 ビットにする。デフォルトについての説明とポインタの大きさについては-mlong32 を参照のこと。
-mlong32: long 型、int 型、ポインタ型を強制的に 32 ビット幅にする。
-mlong32、-mlong64、-mint64 のどれも指定されていないと、int、long、ポインタのサイズは、ABI と選択された ISA に依存する。-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 になり、それ以外は 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 オプションを指定すると、全てのデータ宣言を、テキストセクションの命令部分の前に書き出す。これにより MIPS のアセンブラが小さいグローバルおよび静的データ項目に対し、二語ではなく、一語によるメモリ参照を生成することが可能になる。最適化が指定されている場合には、これはデフォルトで有効になる。
-mstats
-mno-stats: -mstats オプションを指定すると、非インライン関数が処理される度に、標準エラー出力に一行出力し、プログラムの統計情報(セーブされたレジスタ数、スタックの大きさ等)を表示する。
-mmemcpy
-mno-memcpy: -mmemcpy オプションを指定すると、全てのブロック移動に対し、インラインコードを生成する代わりに、適切な文字列関数(memcpy かbcopy)を呼び出すようにする。
-mmips-tfile
-mno-mips-tfile: -mno-mips-tfile を指定すると、MIPS のアセンブラがデバッグ情報を追加した後のオブジェクトファイルに対し、mips-tfile プログラムによる後処理を行なわない。mips-tfile を実行しておかないと、デバッガからローカル変数の情報が扱えなくなる。さらに、stage2 と stage3 のオブジェクトには、アセンブラに渡された一時ファイル名が、オブジェクトファイル内に埋め込まれた形で入っている。このため、stage2 のオブジェクトと stage3 のオブジェクトが同じになることはない。-mno-mips-tfile オプションを指定するのは、mips-tfile プログラムにバグがあり、コンパイルが行えない場合にだけに術器である。
-msoft-float: 浮動小数点用ライブラリ呼び出しを含む出力を生成する。警告: 必要となるライブラリは GCC の一部ではない。普通はその機種の通常の C コンパイラの機能が使われるが、クロスコンパイルの場合はこれをそのまま行なうことはできない。クロスコンパイルの場合は、適切なライブラリ関数を自分で用意しなければならない。
-mhard-float: 浮動小数点命令を含む出力を生成する。これは、GCC のソースを変更しなければ、デフォルトである。
-mabicalls
-mno-abicalls: 位置独立コード用に、System V.4 用の移植で使っている疑似命令.abicalls、.cpload、.cprestore を生成する(あるいは生成しない)。
-mlong-calls
-mno-long-calls: 全ての呼出しを JALR 命令で行う。このためには、呼出しの前に、関数のアドレスをレジスタにロードしておく必要がある。このオプションを使う必要があるのは、現在の 512 メガバイトのセグメントの外側の関数を、ポインタ経由でなく呼び出す場合である。
-mhalf-pic
-mno-half-pic: 外部参照へのポインタを、テキストセクションに置くのではなく、データセクションに置いてロードするようにする。
-membedded-pic
-mno-embedded-pic: いくつかの組み込みシステム向けに適した PIC コードを生成する。全ての呼出しは PC 相対アドレスを使って行われ、全てのデータのアドレスは$gp レジスタを使って扱われる。これには、そのための作業のほとんどを行う GNU as と GNU ld が必要である。これは、現在、ECOFF を使っているターゲットでしか動作していない。ELF では動いていない。
-membedded-data
-mno-embedded-data: 可能であれば、変数を、まず最初に読み出し専用データセクションに割り当てる。次に可能であれば、小データセクションに割り当てる。さもなければ、データセクションに置く。こうすると、デフォルトよりも幾分遅いコードになるが、実行時に必要な RAM の量が小さくなるので、いくつかの組み込みシステムにとっては望ましいだろう。
-msingle-float
-mdouble-float: -msingle-float オプションを指定すると、r4650 チップのように、浮動小数点コプロセッサが単精度演算しかサポートしていないと想定する。-mdouble-float オプションを指定すると、倍精度演算を使うようになる。こちらがデフォルトである。
-mmad
-mno-mad: r4650 チップの場合のように、mad、madu、mul 命令を使うことを許す。
-m4650: -msingle-float、-mmad、それに少なくとも現在のところでは、-mcpu=r4650 を有効にする。
-mips16
-mno-mips16: 16ビット命令を有効にする。
-mentry: 疑似命令 entry と exit を使う。このオプションは -mips16 を一緒にしか使えない。
-EL: リトルエンディアン・モードのプロセッサ用にコードをコンパイルする。必要となるライブラリが存在すると仮定する。
-EB: ビッグエンディアン・モードのプロセッサ用にコードをコンパイルする。必要となるライブラリが存在すると仮定する。
-G num: num バイト以下の大きさのグローバルなデータ項目と静的なデータ項目を、普通のデータセクションや bss セクションではなく、小データセクションや小 bss セクションに置く。これにより、アセンブラが、通常の 2 命令のメモリ参照の代わりに、グローバルポインタ(gp あるいは $28)に基づいた一命令のメモリ参照を生成することが可能になる。num のデフォルト値は、MIPS のアセンブラを使う場合には 8 で、GNU アセンブラを使う場合には 0 である。-G num オプションはアセンブラとリンカにも渡される。全てのモジュールは、同じ値の -G num でコンパイルしなければならない。
-nocpp: MIPS アセンブラに対し、ユーザのアセンブラソースファイル(サフィックスが.s のもの)をアセンブルするときに、アセンブラのプリプロセッサを実行しないように指示する。

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

Node:i386 Options, Next:HPPA Options, Previous:MIPS Options, Up:Submodel Options

Intel 386 オプション

以下の -m オプションが、i386 シリーズ向けに定義されている。

-mcpu=cpu type

命令スケジューリングを行う際の機種型のデフォルトを cpu type と想定する。cpu type に指定可能な値は以下の通りである。

i386 i486 i586 i686
pentium pentiumpro k6

ある特定の cpu type を選ぶとその特定のチップ向けに適切にスケジューリングを行う一方で、GCC は、-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 浮動小数点比較を使うかどうかを指定する。IEEE 浮動小数点比較を使うと、比較の結果が順序づけられない場合を正しく取り扱える。

-msoft-float

浮動小数点用ライブラリ呼び出しを含む出力を生成する。警告: 必要となるライブラリは GCC の一部ではない。であるわけではない。普通はその機種の通常の C コンパイラの機能が使われるが、クロスコンパイルの場合はこれをそのまま行なうことはできない。クロスコンパイルの場合は、適切なライブラリ関数を自分で用意しなければならない。

関数の浮動小数点の戻り値を 80387 のレジスタ・スタックに置く機種では、-msoft-float が指定された場合でも、いくらか浮動小数点オペコードが出力されることがある。

-mno-fp-ret-in-387

関数の戻り値に対し、FPU レジスタを使わない。

通常の呼出し規約では、FPU が無い場合でも、関数は float 型とdouble 型の値を FPU レジスタで返す。OS が FPU をエミュレートすべきであるという考え方である。

-mno-fp-ret-in-387 オプションを指定すると、代わりに、float 型とdouble 型の値を通常の CPU のレジスタに入れて返す。

-mno-fancy-math-387

387 のエミュレータの中には、387 の sin、cos、sqrt 命令をサポートしていないものがある。その場合は、このオプションを指定して、これらの命令を生成しないようにする。このオプションはFreeBSD ではデフォルトになっている。GCC のバージョン 2.6.1 以降は、-ffast-math オプションも指定しない限り、これらの命令は生成されない。

-malign-double

-mno-align-double

double 型、long double 型、long long 型の変数を二語境界に整列するか、一語境界に整列するかを指定する。double 型の変数を二語境界に整列させると、Pentium プロセッサではメモリを余分に食うものの、いくらか高速なコードを生成する。

注意。-malign-double を使った場合は、上記の型を含む構造体は、整列の仕方が、386 用アプリケーション・バイナリ・インターフェース仕様書のものとは異なる。

-msvr3-shlib

-mno-svr3-shlib

GCC が非初期化ローカル変数を bss に置くか data に置くかを制御する。-msvr3-shlib を指定すると bss に置く。この二つのオプションは、System V Release 3 でのみ意味がある。

-mno-wide-multiply

-mwide-multiply

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

-mrtd

異なる関数呼出し規約を使う。この規約では、決まった数の引数を取る関数はret num 命令で戻る。この命令は、戻るときに引数をポップする。これにより呼出し側で一命令節約できる。呼出し側で引数をポップする必要がないからである。

個々の関数がこの呼出し規約で呼ばれるようにするには関数属性 stdcall を指定すれば良い。また、関数属性 cdecl を使うとを-mrtd オプションを上書きできる。See Function Attributes。

注意。この呼出し規約は通常 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 を使うことができる。See Function Attributes.

警告:このオプションを指定し、かつ num がゼロでない場合は、どんなライブラリも含めて、全てのモジュールを同じ値で作らなければならない。システムのライブラリとスタートアップモジュールも例外ではない。

-malign-loops=num

ループを 2 の num 乗バイト境界に整列する。-malign-loops が指定されない場合、gas 2.8 以降を使わない限りデフォルトは 2 である。gas 2.8 以降の場合は、デフォルトは、8 バイトより離れていなければ、ループを 16 バイト境界に整列する。

-malign-jumps=num

命令のジャンプ先が 2 の num 乗境界になるように整列する。-malign-jumps を指定しないと、デフォルトは386 で最適化を行う場合は 2 であり、486 については gas 2.8 以降を使わない限り 4 である。gas 2.8 以降の場合は、デフォルトは、8 バイトより離れていなければ、ループを 16 バイト境界に整列する。

-malign-functions=num

関数の開始点を 2 の num 乗バイト境界に整列する。-malign-functions を指定しない場合、デフォルトは、386 用に最適化する場合は 2 で、486 用に最適化する場合は 4 である。

-mpreferred-stack-boundary=num

スタック境界を 2 の num 乗バイト境界に整列している状態を保つことを試みる。-mpreferred-stack-boundary を指定しない場合、デフォルトは 4(16バイトか 128 ビット)である。

スタックは 4 バイト境界に整列させる必要がある。Pentium と PentiumPro では、double と long double の値は8 バイト境界に整列するべきである。そうしないと、実行時に実行速度のペナルティが非常に大きくなる。Pentium III では、ストリーミング SIMD 拡張(SSE) データ型 __m128 は、16 バイト境界に整列しておかないと同様のペナルティを受ける。

スタック上のこれらの値のアラインメントが適切になることを保証するために、スタック境界は、スタックに格納された任意の値で必要になるだけの大きさのアライメントに整列させる必要がある。さらに、各関数は、スタックのアライメントを保つように生成しなければならない。スタック境界を高くしてコンパイルした関数をスタック境界を低くしてコンパイルした関数から呼び出すのは、ほとんどの場合スタックの整列が正しくなくなる。コールバックを使うライブラリは常にデフォルトの設定を使うことをお奨めする。

アライメントを余分に取れば、スタックスペースも余分に使う。スタックスペースの使用量に注意しなければいけないコード、例えば、組み込みシステムや OS のカーネル等は、-mpreferred-stack-boundary=2 と指定して、好ましいアラインメントを小さくするのが良いだろう。

Node:HPPA Options, Next:Intel 960 Options, Previous:i386 Options, Up:Submodel Options

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 のサポートは現在 GAS のスナップショットの 19990413 以降が必要である。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 文用の表に適したコードを生成する。このオプションは、アセンブラやリンカが switch 文用の表の範囲内の分岐先を越えているという文句を言った場合にのみ使うこと。
-mjump-in-delay: 関数呼びだしの遅延スロットを無条件ジャンプ命令で埋める。これは、その関数呼びだしの戻りアドレスポインタを条件ジャンプのターゲットになるように修正することで行なう。
-mdisable-fpregs: どんな形であれ、浮動小数点レジスタを使うのを避ける。これは、浮動小数点レジスタのコンテキスト切替えが遅いカーネルをコンパイルするときに必要になる。このオプションを指定して、かつ、浮動小数点演算を実行すると、コンパイラが異常終了する。
-mdisable-indexing: インデックス付きアドレッシングモードを使うのを避ける。これにより、MACH で MIG により生成されたコードをコンパイルするときの不明瞭な問題を回避できる。
-mno-space-regs: ターゲット機種にスペース・レジスタがないと想定したコードを生成する。これにより、GCC は、より高速な間接呼出しを生成し、スケーリングなしのインデックス付きアドレッシングモードを使えるようにする。
このようなコードは、レベル 0 の PA システムやカーネルに適している。
-mfast-indirect-calls: スペース境界を越えた呼出しはないと想定したコードを生成する。これにより、より高速な間接呼出しを行なうコードを生成するようになる。
このオプションは、共有ライブラリや関数内関数がある場合には正しく動作しない。
-mspace: 実行時間よりもメモリ空間を最適化する。現時点では、これは関数プロローグとエピローグをインライン展開しないようにするだけである。このオプションは、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: HP-UX リンカの最適化パスを有効にする。ただし、これによりシンボリックデバッグが出来なくなることに注意。また、HP-UX 8 と HP-UX 9 のリンカにあるバグを引き出してしまう。このバグは、何かのプログラムをリンクするときに正しくないエラーメッセージを出すというものである。
-msoft-float: 浮動小数点用ライブラリ呼び出しを含む出力を生成する。警告: 必要となるライブラリは全ての HPPA ターゲットで利用可能であるわけではない。普通はその機種の通常の C コンパイラの機能が使われるが、クロスコンパイルの場合はこれをそのまま行なうことはできない。クロスコンパイルの場合は、適切なライブラリ関数を自分で用意しなければならない。組み込みターゲット hppa1.1-*-pro は、ソフトウェアによる浮動小数点サポートを提供している。
-msoft-float を指定すると、出力ファイル中の呼び出し規約が変わる。このため、プログラム全体をこのオプションでコンパイルしないといけない。特に、GCC 付属のライブラリである、libgcc.a をコンパイルするときに、-msoft-float を指定してコンパイルしないとこのライブラリが正しく動作しない。

Node:Intel 960 Options, Next:DEC Alpha Options, Previous:HPPA Options, Up:Submodel Options

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 命令でも呼出し可能になるように末端プロシージャを修正することを試みる(試みない)。これは、bal 命令がアセンブラやリンカで置き換え可能な場合は明示的な呼出しについてはコードの効率が良くなる。しかし、それ以外の場合、例えば関数ポインタ経由の呼出しや、このような最適化をサポートしていないリンカを使う場合にはコードの効率が悪くなる。
-mtail-call
-mno-tail-call: 末尾再帰呼出しを分岐に最適化するのを追加で(GCC の機種独立部で行うもの以外に)試みる。読者はこれをやらない方が良いだろう。これが有効でない場合を検出するのがまだ完全ではないからである。デフォルトは -mno-tail-call である。
-mcomplex-addr
-mno-complex-addr: 複雑なアドレッシングモードを使うのは、使用している 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: 構造体のアラインメントについて、Intel 版 GCC のバージョン 1.3(gcc 1.37ベース) との互換性を有効にする。このオプションには、-mstrict-align も含まれる
-mlong-double-64: long double 型を 64 ビット浮動小数点数として実装する。このオプションを指定しない場合、long double は 80 ビット浮動小数点数で実装される。このオプションが存在する唯一の理由は、fp-bit.c にはまだ 128 ビットの long double サポートがないからである。このため、ソフトウェアによる浮動小数点演算を行うターゲットを使用する人にしか役に立たない。それ以外の場合は、使わないようにお奨めしなければならない。

Node:DEC Alpha Options, Next:Clipper Options, Previous:Intel 960 Options, Up:Submodel Options

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 付きでコンパイルしたコードから呼び出される関数で、浮動小数点引数や戻り値を持つものもまた、このオプションを指定してコンパイルしなければならない。

このオプションが使われるのは、普通は、浮動小数点レジスタを使わず、それゆえに浮動小数点レジスタをセーブ／リストアする必要のないカーネルを構築するときである。

-mieee

Alpha アーキテクチャは、浮動小数点用ハードウェアを最大の性能を出すように最適化して実装している。この実装は、IEEE 浮動小数点規格にほぼ準拠している。だが、完全に準拠するには、ソフトウェアによる補助が必要である。このオプションにより、inexact flag が保持されない(下記参照)という点を除いて、IEEE に完全に準拠したコードを生成する。このオプションが有効になっていると CPP マクロ _IEEE_FP がコンパイル時に定義される。このオプションは、

-D_IEEE_FP -mfp-trap-mode=su -mtrap-precision=i
-mieee-conformant

の省略形である。この結果生成されるコードは幾らか効率が落ちるが、非正規化数と、非数と正負の無限大のような IEEE の例外値を正しくサポートできる。他の Alpha 用コンパイラはこのオプションを -ieee_with_no_inexact と呼んでいる。

-mieee-with-inexact

これは -mieee と同様だが、生成されたコードは IEEE の inexact flag の維持も行う。このオプションを有効にすると、生成されたコードは完全に準拠した IEEE の数学演算を実装することになる。このオプションは、-D_IEEEFP -D_IEEE_FP_INEXACT に加えて、-mieee-conformant、-mfp-trap-mode=sui、-mtrap-precision=i の三つのオプションを指定したものの省略形である。Alpha の実装の中にはこうして得られたコードが、デフォルトで生成されるコードよりも非常に遅くなるものがある。inexact flag に依存するようなコードは滅多にないので、このオプションを普通は指定しなくて良いはずである。他の Alpha 用コンパイラはこのオプションを-ieee_with_inexact としている。

-mfp-trap-mode=trap mode

このオプションは、どの浮動小数点関係のトラップを有効にするかを扱う。他の Alpha 用コンパイラでは、-fptmtrap mode と言っているものである。trap mode には以下の四つの値のうち一つを設定可能である。

n: これはデフォルト(通常、normal)の設定である。有効になるトラップは、ソフトウェアでは無効にできないもの(例えば、ゼロによる除算)だけである。
u: n で有効になるトラップに加えて、アンダーフローによるトラップが有効になる。
su: u と同様だが、命令は、ソフトウェア補完(詳細については、Alpha のアーキテクチャマニュアルを参照のこと)に対して安全であるとの印がつけられる。
sui: su と同様だが、不正確なトラップも同じく有効になる。

-mfp-rounding-mode=rounding mode

IEEE の丸めモードを選択する。他の Alpha 用コンパイラでは、-fprmrounding mode と言っているものである。rounding mode は以下のどれか一つである。

n: 通常の IEEE 丸めモード。浮動小数点数は最近のハードウェアで表現できる数に向かって丸められる。二つの数のちょうど中間の場合は偶数の方に向かって丸められる。
m: 負の無限大に向かって丸める。
c: 切り捨て丸めモード。浮動小数点数はゼロに向かって丸められる。
d: 動的丸めモード。浮動小数点制御レジスタ(fpcr、Alpha アーキテクチャ参照マニュアルを参照のこと)中のあるフィールドが有効になる丸めモードを制御する。C ライブラリは、このレジスタを正の無限大に向かって丸めるモードに初期化する。このため、プログラムで fpcr を変更しない限り、d は正の無限大に向かっての丸めに対応する。

-mtrap-precision=trap precision

Alpha アーキテクチャでは、浮動小数点トラップは不正確である。これは、ソフトウェアの助けを借りなくては、浮動小数点トラップから回復するのが不可能であり、プログラムの実行は普通は終了させる必要があるといことを意味する。GCC は OS のトラップ・ハンドラを助けるコードを生成し、浮動小数点トラップが発生した正確な位置を特定することを可能にする。アプリケーションの要求に応じて、正確さのレベルを以下から選択することができる。

p: プログラム精度。このオプションはデフォルトであり、トラップハンドラはどのプログラムが浮動小数点例外を引き起こしたかしか特定できないことを意味する。
f: 関数精度。トラップハンドラは浮動小数点例外を引き起こした関数を決定することができる。
i: 命令精度。トラップハンドラは浮動小数点例外を引き起こした命令そのものを決定できる。

他の Alpha 用コンパイラは、これらに等価なオプション -scope_safe や-resumption_safe を用意している。

-mieee-conformant

このオプションは、生成されたコードに IEEE に適合しているとのマークを付ける。このオプションを使うときは、-mtrap-precision=iと、-mfp-trap-mode=su か -mfp-trap-mode=sui のどちらかを指定しなければならない。このオプションの効果は、生成されたアセンブリファイルの関数プロローグ部に .eflag 48 という行を一行加えるだけである。DEC Unix では、これには、 IEEE適合数学ライブラリルーチンがリンクされるという効果がある。

-mbuild-constants

通常 GCC は、32 ビットまたは 64 ビットの整数定数について、それがより小さな定数から二つまたは三つの命令で構築できるかどうかを調べる。それが出来ない場合は、その定数をそのまま出力し、実行時にデータ・セグメントからをロードするコードを生成する。

このオプションを使うと GCC は、たとえ、さらに命令数が増えることになっても(最大で6個)、全ての整数定数を命令コードで構築する。

このオプションを使う代表的な場合は、共有ライブラリの動的ローダを構築するときである。動的ローダはそれ自身共有ライブラリであり、変数や定数を自分自身のデータセグメントから見つけられるようになる前に、メモリ中で自分自身を再配置しなければならない。

-malpha-as

-mgas

ベンダ提供のアセンブラによりアセンブルされるコードを生成する(-malpha-as)か、GNU アセンブラ(-mgas)にアセンブルされるコードを生成するかを選択する。

-mbwx

-mno-bwx

-mcix

-mno-cix

-mmax

-mno-max

オプションの命令セット、BWX、CIX、MAX を使うコードを生成するようGCC に指示する。デフォルトは、-mcpu= オプションで指定したCPU 型でサポートされている命令セットか、何も指定されない場合はGCC の構築を行った CPU のものになる。

-mcpu=cpu_type

命令セット、レジスタセット、命令スケジューリング・パラメータを機種 cpu_type 用に設定する。EV 形式の名前を指定することもできるし、それに対応する CPU チップ番号を指定することもできる。GCC は、EV4 と EV5 シリーズのプロセッサ用のスケジューリング・パラメータをサポートしており、命令セットのデフォルト値はユーザが指定したプロセッサから選択する。プロセッサ型を指定しない場合は、GCC は、GCC の構築を行ったプロセッサをデフォルトにする。

cpu_type の値として使えるのは以下の通り。

ev4
21064: EV4 としてスケジューリングを行ない、命令セットの拡張はないものとする。
ev5
21164: EV5 としてスケジューリングを行ない、命令セットの拡張はないものとする。
ev56
21164a: EV5 としてスケジューリングを行ない、BWX 拡張をサポートする。
pca56
21164pc
21164PC: EV5 としてスケジューリングを行ない、BWX と MAX 拡張をサポートする。
ev6
21264: EV5 としてスケジューリングを行ない(DEC が EV6 用のスケジューリングパラメータを発表するまでは)、BWX、CIX、MAX 拡張をサポートする。

-mmemory-latency=time

アプリケーションから見える典型的なメモリ参照に対し、スケジューラが想定すべきレイテンシを設定する。この数は、アプリケーションが使うメモリアクセスパタンと外部キャッシュの大きさに非常に依存する。

time として有効な値は以下の通りである。

number: クロック数を表す 10進数。
L1
L2
L3
main: GCC は、「典型的な」 EV4 と EV5 のハードウェアについては、レベル1、2、3 のキャッシュを持つ場合についてのクロックサイクル数の見積値を、主記憶にたいするものと同様に保持している。L3 は EV5 に対してのみ有効であることに注意。

Node:Clipper Options, Next:H8/300 Options, Previous:DEC Alpha Options, Up:Submodel Options

Clipper オプション

以下の -m オプションが、Clipper の実装用に定義されている。

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

Node:H8/300 Options, Next:SH Options, Previous:Clipper Options, Up:Submodel Options

H8/300 オプション

以下の -m オプションが、H8/300 の実装用に定義されている。

-mrelax: リンク時に幾つかのアドレス参照を可能であれば短くする。リンカの -relax オプションを使う。より詳しい説明については、See 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 では何の効果もない。

Node:SH Options, Next:System V Options, Previous:H8/300 Options, Up:Submodel Options

SH オプション

以下の -m オプションが、SH の実装用に定義されている。

-m1: SH1 用のコードを生成する。
-m2: SH2 用のコードを生成する。
-m3: SH3 用のコードを生成する。
-m3e: SH3e 用のコードを生成する。
-mb: ビッグエンディアン・モードのプロセッサ用にコードをコンパイルする。
-ml: リトルエンディアン・モードのプロセッサ用にコードをコンパイルする。
-mdalign: double 型を 64 ビット境界に整列する。これは呼出し規約を変えてしまうので、標準 C ライブラリの中のいくつかの関数は、まず -mdalign を指定して再コンパイルしておかないと動作しないだろう。
-mrelax: リンク時に幾つかのアドレス参照を可能であれば短くする。リンカの -relax オプションを使う。

Node:System V Options, Next:TMS320C3x/C4x Options, Previous:SH Options, Up:Submodel Options

System V 向けオプション

以下のオプションが System V Release 4 では追加で使える。これらは、System V Relase 4 システムの他のコンパイラとの互換性のためにある。

-G: 共有オブジェクトを作る。代わりに -symbolic か -shared を使うことが推奨される。
-Qy: コンパイラが使用する各ツールのバージョンを、アセンブラ命令 .ident に入れて出力する。
-Qn: .ident 命令を出力ファイルに追加するのを止める(これがデフォルトである)。
-YP,dirs: -l で指定されたライブラリについてディレクトリ dirs だけを検索し、他の場所を検索しない。
-Ym,dir: プリプロセッサ M4 をディレクトリ dir から探す。アセンブラがこのオプションを使用する。

Node:TMS320C3x/C4x Options, Next:V850 Options, Previous:System V Options, Up:Submodel Options

TMS320C3x/C4x オプション

以下の -m オプションが、TMS320C3x/C4x の実装用に定義されている。

-mcpu=cpu_type: 機種型 cpu_type 用の命令セット、レジスタセット、命令スケジューリングのパラメータを設定する。cpu_type の値として使えるのは、c30、c31、c32、c40、c44 である。デフォルトは c40 であり、TMS320C40 用のコードを生成する。
-mbig-memory
-mbig
-msmall-memory
-msmall: ビッグ・メモリ・モデルあるいはスモール・メモリ・モデル向けのコードを生成する。スモール・メモリ・モデルでは、全てのデータが一個の 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: DP レジスタを、割り込みサービスルーチン(ISR) の入り口点でセーブし、データセクションを指すように再ロードし、ISR の出口点でリストアすることを強制する。これは、だれかが、例えばあるオブジェクトライブラリ内で、DP レジスタを変更することで小メモリモデルに違反しない限り、必要とすべきではない。
-mmpyi
-mno-mpyi: C3x に対しては、整数の乗算にはライブラリ呼出しの代わりに24 ビット MPYI 命令を使い、32ビットの結果を保証する。オペランドの一つが定数なら、この乗算はシフトと加算を使って実行されることに注意。C3X の場合に -mmpyi オプションを指定しないと、ライブラリ呼出しの代わりに、平方演算がインラインで行われる。
-mfast-fix
-mno-fast-fix: 浮動小数点値を整数値に変換する C3x/C4x の FIX 命令で、その浮動小数点値に最も近い整数ではなく、浮動小数点値以下の最も近い整数を選ぶ。このため、浮動小数点値が負なら、結果が不正に打ち切られるので、それを検出して補正するコードが追加で必要になる。このオプションを使うと、結果の補正に必要な追加コードの生成を無効にすることができる。
-mrptb
-mno-rptb: オーバヘッド無しのループ化のために、RPTB 命令を使った繰り返しブロック列を生成することを有効にする。RPTB 構文は、最内側のループで、関数呼出しやループ境界を越えるジャンプがない場合にだけ使われる。RPTB ループを入れ子にするのは、RC、RS、RE レジスタをセーブ／リストアするのに必要なオーバーヘッドがあるので、利点はない。これは、-O2 を指定した場合にデフォルトで有効になる。
-mrpts=count
-mno-rpts: 一個の命令を繰り返す命令 RPTS を使うことを有効にする(無効にする)。繰り返しを行うブロックに命令が一個あり、ループ回数が count 未満であることが保証可能なら、GCC は RPTB の代わりに RPTS 命令を生成する。値を指定しない場合は、ループ回数がコンパイル時に決定できなくてもRPTS が生成される。RPTS に続く繰り返される命令は、各繰り返しでメモリから再ロードする必要はないので、オペランドに対して CPU バスを解放する。ただし、割り込みはこの命令によりブロックされるので、デフォルトでは無効になっている。
-mloop-unsigned
-mno-loop-unsigned: RPTS と RPTB(それに C40 の場合は DBも)を使うときの最大の繰り返し回数は2^23 + 1 である。これらの命令は、繰り返し回数が負であるかどうかをテストして、ループを終了させるからである。繰り返し回数が符号無しであれば、最大繰り返し回数が 2~23 + 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 の生成を許す。これらの命令はレジスタの制約がきついので、大きな関数のコード生成をやりにくくする。

Node:V850 Options, Next:ARC Options, Previous:TMS320C3x/C4x Options, Up:Submodel Options

V850 オプション

以下の -m オプションが V850 の実装用に定義されている。

-mlong-calls
-mno-long-calls: 全ての呼出しを遠い(近い)呼出しとして扱う。呼出しが遠いと想定された場合、GCC は常に、関数のアドレスをレジスタにロードし、そのポインタを経由した間接呼出しを行なう。
-mno-ep
-mep: ポインタを ep レジスタにコピーするのに、同じインデックスポインタを、4回以上使っている基本ブロックの最適化を行なわない(最適化を行なう)。最適化を行なう場合は、デフォルトで -mep が有効になる。
-mno-prolog-function
-mprolog-function: 関数のプロローグとエピローグでレジスタをセーブ／リストアするのに、外部関数を使わない(使う)。外部関数は遅いが、複数の関数が同じ数のレジスタをセーブするなら、コードサイズは小さくなる。-mprolog-function オプションは、最適化を行なう場合はデフォルトで有効になる。
-mspace: 可能な限りコードを小さくすることを試みる。現時点では、これは-mep オプションと -mprolog-function オプションをオンにするだけである。
-mtda=n: static 変数またはグローバル変数のうち、大きさが n バイト以下のものを、ep レジスタが指し示す、微小データ領域に置く。この微小なデータ領域は、全部で 256 バイトまで保持できる(バイト参照毎に 128 バイトである)。
-msda=n: static 変数またはグローバル変数のうち、大きさが n バイト以下のものを gp レジスタが指し示す、小さなデータ領域に置く。この小さなデータ領域には、64Kバイトまで保持できる。
-mzda=n: static 変数またはグローバル変数のうち、大きさが n バイト以下のものをメモリの先頭の 32Kバイトの領域に置く。
-mv850: ターゲットプロセッサが V850 であることを指定する。
-mbig-switch: 大きな switch 文用の表に適したコードを生成する。このオプションは、アセンブラやリンカが、switch 文用の表内の分岐範囲を越えているというメッセージを出したときにのみ使うこと。

Node:ARC Options, Next:NS32K Options, Previous:V850 Options, Up:Submodel Options

ARC オプション

以下のオプションが ARC 実装用に定義されている。

-EL: リトルエンディアンモード用にコードをコンパイルする。これがデフォルトである。
-EB: ビッグエンディアンモード用にコードをコンパイルする。
-mmangle-cpu: CPU 名を全ての公開シンボル名の先頭に付加する。マルチプロセッサシステムでは、異なる命令とレジスタセット特性を持つ多数の ARC の変種が存在する。このフラグは一つの CPU 用にコンパイルされたコードが他の CPU 用にコンパイルされたコードとリンクするのを防ぐ。「ほとんど同じ」である変種を扱う機能は存在しない。これは、全てか全くなしかのオプションである。
-mcpu=cpu: ARC の変種 cpu 用のコードをコンパイルする。どの変種がサポートされるかはコンフィギュレーションに依存する。全ての変種が -mcpu=base をサポートしており、これがデフォルトである。
-mtext=text section
-mdata=data section
-mrodata=readonly data section: 関数、データ、読み出し専用データをデフォルトでそれぞれ、text section、data section、readonly data section に置く。これは、section 属性で上書き可能である。See Variable Attributes。

Node:NS32K Options, Previous:ARC Options, Up:Submodel Options

NS32K オプション

以下の -m オプションが 32000 シリーズ向けに定義されている。これらのオプションのデフォルト値は、GCC のコンフィギュレーション時に32000 のどの型が選択されたかに依存する。最も共通する選択向けのデフォルト値は以下に示されている。

-m32032

32032 用の出力を生成する。これは、GCC が 32032 や 32016 ベースのシステム用にコンフィギュレーションされたときのデフォルトである。

-m32332

32332 用の出力を生成する。これは、GCC が 32332 ベースのシステム用にコンフィギュレーションされたときのデフォルトである。

-m32532

32532 用の出力を生成する。これは、GCC が 32532 ベースのシステム用にコンフィギュレーションされたときのデフォルトである。

-m32081

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

-m32381

浮動小数点用の 32381 命令を含む出力を生成する。これは -m32081 も含む。32381 は、32332 と 32532 という CPU とのみ互換である。これは、 pc532-netbsd のコンフィギュレーションのデフォルトである。

-mmulti-add

乗算-加算浮動小数点命令 polyF と dotF を生成する。このオプションは、-m32381 オプションが有効になっている場合にのみ使用できる。これらの命令を使うには、一般には性能に悪い影響を与えるような、レジスタ割当の変更を必要とする。このオプションは、特に乗算-加算命令を大量に使いそうなコードをコンパイルするときにだけ有効にすべきだろう。

-mnomulti-add

乗算-加算浮動小数点命令 polyF と dotF を生成しない。これは全てのプラットフォームでのデフォルトである。

-msoft-float

浮動小数点ライブラリ呼出しを含む出力を生成する。注意。必要なライブラリが利用可能でない場合がある。

-mnobitfield

ビットフィールド命令を使わない。幾つかの機種では、シフト演算とマスク演算を使ったほうが高速である。これは pc532 のデフォルトである。

-mbitfield

ビットフィールド命令を使う。これは、pc532 以外の全てのプラットフォームでデフォルトである。

-mrtd

異なる関数呼出し規約を使う。この規約では、決まった数の引数を取る関数はret num 命令で戻る。この命令は戻る際に引数をポップする。

この呼出し規約は通常 Unix で使われているものとは互換性がない。このため、Unix のコンパイラでコンパイルされたライブラリを呼び出す必要があるときには使用できない。

さらに、引数がたくさんありすぎる関数を呼び出すと重大な誤りのあるコードが生成される。(普通、引数が余分にある場合は問題なく無視される。)

このオプションの名前は、680x0 の rtd 命令から取ったものである。

-mregparam

異なる関数呼出し規約を使う。この規約では、先頭の二つの引数をレジスタで渡す。

-mnoregparam

どの引数もレジスタでは渡さない。これは全てのターゲットでのデフォルトである。

-msb

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

-mnosb

sb レジスタは利用できないか、あるいは実行時システムでゼロに初期化されない。これは、pc532-netbsd 以外の全ての機種のデフォルトである。このオプションは、-mhimem か -fpic が指定されているときは常に暗黙に含まれる。

-mhimem

ns32000 シリーズのアドレッシングモードの多くは、512MB までの変位を使っている。アドレスが、512MB を越えると、ゼロからの変位は使えない。このオプションは、512MB を越えてロード可能なコードを生成させる。これは、OS や ROM コードで役に立つだろう。

-mnohimem

コードが、仮想アドレス空間の先頭の 512 MB 内にロードされると想定する。これは、全てのプラットフォームでのデフォルトである。

Node:Code Gen Options, Next:Environment Variables, Previous:Submodel Options, Up:Invoking GCC

コード生成規約についてのオプション

以下は、機種独立のオプションで、コード生成において使われるインターフェース規約を制御する。

以下のほとんどのオプションには肯定形と否定形の両方の形式がある。-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 が標準のコンパイラであるターゲットを除いて、-fpcc-struct-return をデフォルトとする。GCC が標準のコンパイラである場合には、我々に標準の規約を選ぶ権利があるので、効率の良い、レジスタで返すほうを選ぶ。

-fshort-enums

enum 型に対して、その型で宣言されている可能な範囲の値を表すのに必要なバイト数しか割り当てない。もっと正確に言えば、その場合の enum 型は、それを収めるのに充分で、かつ、最小の整数型に同じである。

-fshort-double

double のサイズとして float と同じサイズを使う。

-fshared-data

データおよび非const 変数を、プライベートなデータとするのでなく、共有データとすることを要求する。このことによる違いは、共有データは同一のプログラムを実行する複数のプロセス間で共有されるが、プライベートなデータは、プロセス毎にコピーを持つような、特定のOS の元でしか意味を持たない。

-fno-common

非初期化グローバル変数について、コモンブロックとして生成するのではなく、オブジェクトファイルの bss セクションに割り当てる。これにより、同じ変数が二つの異なるコンパイル単位で(extern なしで) 宣言されていると、リンク時にエラーとなる。これが唯一役に立つのは、常にこのような動作をする他のシステムでのプログラムの動作を検証したいときだろう。

-fno-ident

#ident 制御子を無視する。

-fno-gnu-linker

グローバルの初期化子(C++ のコンストラクタやデストラクタ等)をGNU リンカで使われている形式で出力しない(GNU リンカが初期化子を取り扱う標準の方法となっているシステムの場合)。GNU リンカでないリンカを使いたいときはこのオプションを指定する。このとき、collect2 プログラムを使って、システムのリンカがコンストラクタとデストラクタを取り込むようにすることも必要となる。(collect2 は GCC の配布物に含まれている。) collect2 を使わなければならないシステムに対しては、コンパイラドライバである gcc は自動的にそうするようにコンフィギュレーションされる。

-finhibit-size-directive

アセンブラ命令 .size や、あるいは関数が途中で分割され、分割された二つの部分がメモリ中で離れた場所に置かれた場合に問題となるようなものを出力しない。このオプションは crtstuff.c をコンパイルするときに使われる。その他の場合には必要ないはずである。

-fverbose-asm

生成されたアセンブリコードに余分の注釈情報を加えて、読みやすくする。このオプションは、一般に、生成されたアセンブリコードを実際に読む必要がある人向けのものである(おそらく、本コンパイラ自体をデッバグするときに...)。

デフォルトの -fno-verbose-asm は、余分の情報を出さず、二つのアセンブラファイルを比較するときは便利である。

-fvolatile

ポインタを経由する全てのメモリ参照を揮発性と考える。

-fvolatile-global

外部データとグローバルデータに対する全てのメモリ参照を揮発性と考える。GCC は、このオプションを指定しても、静的データ項目が揮発性であるとは考えない。

-fvolatile-static

静的データに対する全てのメモリ参照を揮発性と考える。

-fpic

共有ライブラリで使うのに適した位置独立コード(PIC)を、ターゲットがサポートしていれば、生成する。これで生成したコードは、全ての定数アドレスをグローバルオフセット表(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 というマクロで定義される。

このオプションには否定形がない。三つの選択肢のうちの一つを指定するからである。

-fcall-used-reg

reg で指定されたレジスタを関数呼び出しにより破壊される、割当可能なレジスタとして扱う。このレジスタは、一時的な作業用や関数呼び出しを越えて生存しない変数に割り当てられる可能性がある。このオプションを付けてコンパイルされた関数は、レジスタ reg のセーブとリストアを行なわない。

このフラグをフレームポインタやスタックポインタに対して使うのは誤りである。このフラグを、その他の、マシンの実行モデルにおいて固定した広く知られている役割を持つレジスタに対して使うと、破壊的な結果をもたらす。

このオプションには否定形がない。三つの選択肢のうちの一つを指定するからである。

-fcall-saved-reg

reg という名前のレジスタを関数によりセーブされる割当可能なレジスタとして取り扱う。一時的なものや呼び出しを越えて生存する変数に対しても割り当てられる。こうしてコンパイルされた関数は、もし reg を使っていれば、それをセーブ／リストアする。

このフラグを関数の戻り値を入れるレジスタに対して使うと、別の種類の破壊的な結果になる。

このオプションには否定形がない。三つの選択肢のうちの一つを指定するからである。

-fpack-struct

構造体のメンバを全て穴の無いように詰め込む。普通はこのオプションを使うことはないだろう。コードの効率が落ちるし、構造体メンバのオフセットがシステムライブラリのものと一致しなくなるからである。

-fcheck-memory-usage

各メモリ参照を検査するために余分なコードを生成する。GCC は、Checker のような、不正なメモリ参照を検知するプログラムに適したコードを生成する。

普通は、この全てのコードをこのオプションを付けてコンパイルするか、あるいは全く付けずにコンパイルする必要がある。

このオプションを付けてコンパイルしたコードと付けないでコンパイルしたコードを混ぜる場合は、副作用があり、かつ、このオプションを付けてコンパイルしたコードから呼び出される全てのコードは、それ自身、このオプションを付けてコンパイルされることを保証しなければならない。

ライブラリ関数のうち副作用のあるもの(例えば、read)を使うときは、このオプションを指定してそのライブラリ関数を再コンパイルする訳にはいかないこともあるだろう。その場合は、-fprefix-function-name オプションを指定して、読者のコードを包み込み、他の関数があたかも-fcheck-memory-usage オプションつきでコンパイルされたかのようにすることを GCC に要求する。これは、「スタブ」を呼び出すことによて行なわれる。スタブは検知器により提供される。読者の呼び出しているあらゆる関数に対してスタブを見つけたり、構築することが不可能な場合は、-fprefix-function-name オプションなしで -fcheck-memory-usage を指定する必要がある。

このオプションを指定するときは、メモリ検査を有効にした関数内でasm や __asm__ というキーワードを使うことはできない。GCC は asm 文が行うことを理解できず、そのため適切なコードが生成できないので、拒絶される。ただし、関数属性no_check_memory_usage を付けると関数内のメモリ検査が無効になり、asm 文をそういう関数内に置くことが可能になる。検査された関数内で検査無しの関数をインライン展開するのは許されている。インライン関数でのメモリアクセスは検査されないが、その結果検査される。

読者の asm 文を検査無しのインライン関数に移動するが、それらがメモリをアクセスするなら、インライン関数内のサポートコードの呼出しを追加して、任意の読み出し、書き出し、コピーが行われることを指示することができる。これらの呼出しは、上で説明したスタブで行われるものに似たものになるだろう。

-fprefix-function-name

関数名に対して生成されたシンボルにプレフィックスを付けることを 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 を指定するなら、インライン関数のアドレス取得可能版を提供しなければならない。(何はともあれ、これが普通の場合だが、最適化により常に関数がインライン展開されるなら、運が良ければ、static 版を提供しなくても済むかもしれない。)

関数に属性 no_instrument_function を指定すると、この特別処理は行われない。これは例えば、上に示したプロファイリング関数や、高優先度の割り込みルーチン、プロファイリング関数から安全に呼び出すことができない関数(プロファイリングルーチンが出力をおこなったり、メモリを確保するなら、おそらくシグナルハンドラが該当する)等に使われる。

-fstack-check

スタックの境界を越えないことを検証するコードを生成する。マルチスレッドの環境ではこのフラグを指定すべきだろう。シングルスレッドの環境では滅多に指定する必要がないだろう。スタックが一個しかなければ、ほぼ全てのシステムでスタックのオーバーフローを自動的に検出するからである。

-fargument-alias

-fargument-noalias

-fargument-noalias-global

仮引数間の依存関係および仮引数とグローバルデータの依存関係の可能性を指定する。

-fargument-alias は、引数(仮引数)がお互いに別名になっている可能性があること、それにグローバルデータの別名になっている可能性があることを指定する。-fargument-noalias は引数はお互いに別名になっていることはないが、グローバルデータの別名になっている可能性があることを指定する。-fargument-noaliase-global は、引数はお互いに別名になっていないし、グローバルデータの別名にもなっていないことを指定する。

それぞれの言語は、その言語の規格で必要とされるオプションはなんであれ、自動的に使うようになっている。そういうオプションを読者自身が使う必要はないはずである。

-fleading-underscore

このオプションとその反対のオプションである -fno-leading-underscore は、C のシンボルのオブジェクトファイル中での表現方法を強制的に変更する。使い道の一つは、古いアセンブリコードとリンクするのを助けることにある。

このオプションを指定するときは自分が何をしようとしているのかを理解している必要があるということ、それに全てのターゲットがこのオプションを完全にサポートしている訳ではないということに注意して欲しい。

Node:Environment Variables, Next:Running Protoize, Previous:Code Gen Options, Up:Invoking GCC

GCC に影響する環境変数

この節では、GCC の動作に関係する環境変数について説明する。これらの環境変数のうちのいくつかの仕事は、色々な種類のファイルを検索するときに使うディレクトリやプレフィックスを指定することである。またいくつかは、コンパイル環境の他の側面を指定するのに使われる。

また、検索場所を指定するのに -B、-I、-L (see Directory Options)等のオプションを使うことが出来ることに注意。これらのオプションは、環境変数で指定された場所よりも優先する。また、環境変数による指定は、GCC のコンフィギュレーションで指定された場所よりも優先する。See Driver。

LANG

LC_CTYPE

LC_MESSAGES

LC_ALL

これらの環境変数は、GCC が、地域化(localization)情報を、異なる国の習慣とともに動作することが可能になるように使う方法を制御する。GCC は、コンフィギュレーションで指定されていれば、ロケール・カテゴリ LC_TYPE と LC_MESSAGES を調べる。これらのロケール・カテゴリには、読者のインストールでサポートされている任意の値を設定できる。代表的な値は、英国(United Kingdom)の英語を表す en_UK である。

環境変数 LC_CTYPE は、文字の分類を指定する。GCC はこれを使って、文字列中の文字の境界を決定する。これは、いくつかのマルチバイトのエンコーディングで必要になる。これらのエンコーディングでは、文字の境界がわからないと、文字列の終了やエスケープとして解釈されてしまうような引用文字やエスケープ文字が含まれている。

環境変数 LC_MESSAGES は、診断メッセージで使うべき言語を指定する。

環境変数 LC_ALL が設定されていると、LC_CTYPE とLC_MESSAGES の値を上書きする。設定されていないと、LC_CTYPE と LC_MESSAGES のデフォルトは、環境変数 LANG の値となる。これらのどの変数も設定されていない場合は、GCC は伝統的な C の英語の動作をデフォルトにする。

TMPDIR

TMPDIR が定義されていれば、その値で一時ファイルを置くディレクトリを指定する。GCC は一時ファイルを使ってコンパイルの一つのステージの出力を保持する。それが次のステージの入力として使われる。例えば、プリプロセッサの出力は、コンパイラ本体への入力になる。

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 の値で)始まる名前の標準のディレクトリ毎に、その名前の始まりを指定されたプレフィックスに置き換えて、別のディレクトリ名を生成する。つまり、-Bfoo/ を指定すると、GCC は、普通なら /usr/local/lib/bar を探すところを、foo/bar を探すのである。この別のディレクトリは最初に検索される。標準のディレクトリが次に検索される。

COMPILER_PATH

COMPILER_PATH の値はコロンで区切ったディレクトリのリストであり、PATH に良く似ている。GCC は、GCC_EXEC_PREFIX を使ってサブプログラムを見つけられなかった場合に、これで指定されたディレクトリからサブプログラムを探す。

LIBRARY_PATH

LIBRARY_PATH の値はコロンで区切ったディレクトリのリストであり、PATH に良く似ている。ネイティブコンパイラとしてコンフィギュレーションを行なった場合は、GCC は、特別なリンカファイルを検索するときに、GCC_EXEC_PREFIX を使っても見つけられないときは、このように指定されたディレクトリを使う。GCC を使ってリンクを行なうときも、-l で指定された通常のライブラリを探すときに、これらのディレクトリを使う(ただし、-L で指定されたディレクトリがまず検索される)。

C_INCLUDE_PATH

CPLUS_INCLUDE_PATH

OBJC_INCLUDE_PATH

これらの環境変数は、特定の言語に関与する。各変数の値は、PATH のように、コロンで区切ったディレクトリのリストである。GCC がヘッダファイルを探すとき、使用している言語向けの変数に列挙されているディレクトリから探す。これは、-I で指定されたディレクトリの検索の後で、標準ヘッダファイルディレクトリの検索の前に行なわれる。

DEPENDENCIES_OUTPUT

この変数が設定されていると、その値が GCC により処理されるヘッダファイルに基づく、Make 用依存関係の出力方法を指定する。この出力は -M オプションによる出力に良く似ているが、独立したファイルに出力され、通常のコンパイル結果に追加される形で出力される。

DEPENDENCIES_OUTPUT の値は単なるファイル名でも良く、その場合は Make 用のルールはそのファイルに書かれる。Make のターゲット名はソースファイル名から推測する。あるいは、この変数の値はfile target という形でも良い。この場合、ファイル file に書き出されるルールは、ターゲット名としてtarget を使う。

LANG

この環境変数を使って、ロケール情報を GCC に渡す。この情報の一つの使い方としては、文字定数、文字列定数、コメントが C や C++ でパースされるときに使うべき文字セットを決定することがある。GCC をマルチバイト文字を許すようにコンフィギュレーションした場合は、LANG の値として以下のものが認識される。

C-JIS: JIS コード文字を認識する。
C-SJIS: SJIS コード文字を認識する。
C-EUCJP: EUCJP コード文字を認識する。

LANG が定義されていなかったり、上記以外の値になっている場合は、GCC はデフォルトのロケールで定義される mblen と mbtowc を使って、マルチバイト文字を認識し変換する。

Node:Running Protoize, Previous:Environment Variables, Up:Invoking GCC

protoize の実行

protoize プログラムは、GNU C の選択的な部分である。これを使ってプロトタイプ宣言をプログラムに追加することができ、一つの面でプログラムを ANSI C に変換する。仲間のプログラム unprotoize は、その逆を行なう。見つかったプロトタイプ宣言から引数型を取り除く。

このプログラムを実行するときは、コマンド行引数として一組のソースファイルを指定しなければならない。この二つの変換プログラムは、これらのファイルをコンパイルしてどんな関数が定義されているかを調べることから始める。foo というファイルについて集められた情報葉、foo.X という名前のファイルにセーブされる。

この走査の後に実際の変換を行なう。指定したファイルは全て変換対象の資格を持つ。それからインクルードされているファイル(ソースであれ単なるヘッダであれ)も同様に資格を持つ。

しかし、資格を持つファイルが全て変換されるわけではない。デフォルトでは、protoize と unprotoize は、カレントディレクトリにあるソースとヘッダだけを変換する。変換すべきファイルが置かれているディレクトリを追加するには、-d directory オプションを使えば良い。また、特定のファイルを除外するには、-x file オプションを使う。ファイルは、資格を持ち、そのディレクトリ名が指定されたディレクトリ名の一つにマッチし、そのディレクトリ内の名前が除外されていない場合に、変換される。

protoize が行なう基本的な変換は、ほとんどの関数定義と関数の宣言を、引数の型を指定するように書き換えることである。書き換えが行なわれないのは、varargs 関数だけである。

protoize はオプションでソースファイルの先頭にプロトタイプ宣言をまとめて挿入し、関数の定義の前に現れる呼び出しで利用できるようにする。あるいは、未定義の関数が呼び出されているブロック内でブロックスコープのプロトタイプ宣言を挿入することもできる。

unprotoize が行なう基本的な変換は、ほとんどの関数の宣言から、引数の型を取り除くように書き換えることと関数定義を ANSI 以前の古い形式に書き換えることである。

どちらの変換プログラムも、変換不可能な関数の宣言や定義があると警告を出す。-q を指定すると、この警告を出さないようにできる。

protoize や unprotoize からの出力は、元のソースファイルを置き換える。元のソースファイルは、.save で終わるファイル名に置き換えられる。既に .save がついたファイルが存在していれば、変更前のファイルは単に捨てられる。

protoize と unprotoize はどちらも、GCC 自身に依存している。GCC を使ってプログラムを走査し、関数についての情報を集めているのである。このため、GCC がインストールされてないと、どちらのプログラムも動作しない。

以下に、protoize と unprotoize で使えるオプションの表を示す。どのオプションも、特に述べていない限り、どちらのプログラムでも使える。

-B directory

ファイル SYSCALLS.c.X を、通常のディレクトリ(普通は/usr/local/lib)の代わりに、directory から探す。このファイルには、標準のシステム関数についてのプロトタイプ情報が入っている。このオプションは protoize にだけ適用される。

-c compilation-options

compilation-options を、gcc を実行して .X ファイルを生成するときのオプションとして使う。さらに特別なオプション -aux-info が常に渡され、gcc に .X ファイルを書き出すことを指示する。

コンパイル用のオプション群は、一個の引数として protoize やunprotoize に与えなければならないことに注意。gcc のオプションを複数指定したいときは、コンパイルオプション群全体を引用符で囲んで、シェルに一個の引数に見えるようにしなければならない。

使用できない gcc の特定のオプションがいくつかある。それを使うと出力の種類が正しくなくなる。そのオプションとは、-g、-O、-c、-S、-o である。これらのオプションを compilation-options に入れると、それは無視される。

-C

ファイル名が .c ではなく .C で終わるようにする。これは、C のプログラムを C++ に変換するときに使える。このオプションは protoize でのみ使用できる。

-g

明示的なグローバル宣言を追加する。これは、ソースファイルの中で呼び出されてはいるが宣言されていない関数について、ファイルの先頭にその関数の明示的な宣言を挿入するということを意味する。この宣言は、宣言されていない関数への呼び出しを含む最初の関数定義よりも前に置かれる。このオプションは protoize でのみ使用できる。

-i string

古い形式の仮引数宣言を文字列 string を使って字下げする。このオプションは protoize でのみ使用できる。

unprotoize は、関数のプロトタイプ形式の定義を古い形式の関数定義に変換する。古い形式では、引数は引数リストと最初の { の間で宣言される。デフォルトでは、unprotoize は空白5個でインデントする。代わりに空白一個でインデントしたい場合は、-i " " とする。

-k

.X ファイルを保存する。普通は、変換が終わった後に削除される。

-l

明示的なローカルの宣言を追加する。protoize に -l を指定すると、宣言無しで関数を呼び出しているブロック毎にその関数のプロトタイプ宣言を挿入する。このオプションは、protoize でだけ使える。

-n

実際の変更は行なわない。このオプションを指定すると、-n を指定しなかった場合に行なわれたであろう変換についての情報を表示するだけである。

-N

.save ファイルを作らない。元のファイル単に削除される。このオプションは注意して使うこと。

-p program

program というプログラムをコンパイラとして使う。普通は gcc という名前が使われる。

-q

黙って仕事をする。ほとんどの警告が抑止される。

-v

gcc の -v と同じように、バージョン番号を表示する。

ソースファイルのうちの一つだけ特別なコンパイラオプションを必要とする場合は、そのファイルに対する .X ファイルを特別に生成する必要がある。それには、そのソースファイルに対して、gcc に適切なオプションと -aux-infoオプションを付けて実行する。その後、protoize を全ファイルに対して実行する。protoize は既に存在する .X ファイルを使用する。それがソースファイルより新しいからである。例えば、以下のようにする。

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

protoize コマンドのその他の使い方の場合は、特別なファイルをインクルードする必要がある。これは、.X ファイルが既に存在している場合でも必要である。そうしておかないと、変換されないからである。

protoize をうまく使いこなすためのさらなる情報については、See Protoize Caveats.

以下の情報のほとんどは、古いもので、EGCS のインストール手順で置き換えられている。歴史的な参照目的でのみここに提供する。

Node:Installation, Next:C Extensions, Previous:Invoking GCC, Up:Top

GNU CC のインストール

Configuration Files: configure が作り出すファイル達
Configurations: GNU CC でサポートしているコンフィギュレーション
Other Dir: ソースディレクトリ以外のディレクトリでのコンパイル方法
Cross-Compiler: クロスコンパイラの構築とインストールの方法
Sun Install: Sun 上でのインストール
VMS Install: VMS 上でのインストール
Collect2: collect2 の仕組み
Header Dirs: ヘッダファイルの置かれるディレクトリ

ここでは、GNU CC を GNU システム、あるいは Unix システムにインストールするための手順を説明する。VMS の場合は、VMS Install を参照のこと。この節では、ソースの置かれているディレクトリでコンパイルを行なうことを仮定する。ソースディレクトリとは別のディレクトリでコンパイルする方法については、Other Dir を参照のこと。

MSDOS では、GNU C 自身をインストールすることはできない。GNU C 自身以外の MSDOS のコンパイラではコンパイルできないからである。このため、完全な DJGPP パッケージを入手する必要がある。DJGPP は、ソースだけでなくバイナリを含んでおり、さらに他に必要なツールやライブラリを全て含んでいる。

以前に、別のターゲットマシン向けに、同じディレクトリで GNU CC を構築したことがあるなら、make distclean を実行して正しくない可能性のあるファイルを全て消すようにする。この処理で消されるファイルの一つに Makefile がある。make distclean を実行して、Makefile が存在しないというエラーが出たら、恐らく、すでにファイルの消去が適切に行なわれていたことを意味する。
System V リリース4 では、PATH で、必ず /usr/bin が/usr/ucbの前に来るようにすること。/usr/ucb にある cc は、バグがあるライブラリを使ってしまうので。
パーザ生成プログラムである Bison がインストールされていることを確認する。(Bison の出力ファイルである c-parse.c と cexp.c がc-parse.y と cexp.y よりも新しく、.y ファイルを変更する予定がなければ、これは必要ない。)
"Sept 8, 1998" より古いバージョンの Bison は、c-parse.c を正しく生成できない。
GNU CC のコンフィギュレーションとして、システム標準のツールの代わりに他の GNU ツール(GAS や GNU リンカ等)を必要とするものを選んだ場合、その必要なツールを構築ディレクトリに as、ld 等の適切な名前でインストールする必要がある。これにより、GNU CC が enquire プログラムをコンパイルするのに適切なツールを見つけることができるようになる。
システム標準のツールよりも先に来るように設定したうえで、引き続くコンパイルを行なうこともできる。
ホスト、構築それにターゲットマシンのコンフィギュレーションを指定する。これは、configure というファイルを実行させるときに行なう。
ビルドマシンとは、読者が使っているシステムであり、ホストマシンとは、できたコンパイラを実行させたいシステム(普通はビルドマシン)であり、ターゲットマシンとはそれ向けにコンパイラにコードを生成させたいシステムのことである。
コンパイラ自身が動作するマシン向けのコードを生成するコンパイラ(ネイティブコンパイラ)を構築する場合は、普通は configure に何も引数を指定する必要はない。機種を推測し、それを構築マシンおよびホストマシン、ターゲットマシンとして使う。このため、configure が今フィギュレーションを推測できなかったり、推測が間違っていない限り、ネイティブコンパイラを構築するときにはコンフィギュレーションを指定する必要がない。
推測がうまくいかない場合は、構築マシンのコンフィギュレーション名を --host オプションで指定する。ホストとターゲットはデフォルトでホストマシンと同じになる。(クロスコンパイラを構築する場合は、Cross-Compiler。)
以下に例を示す。
```
./configure --host=sparc-sun-sunos4.1
```
コンフィギュレーション名は、正規名でも省略形でも良い。
コンフィギュレーションの正規名は三つの部分をダッシュで区切ったものからなる。cpu-company-system という形式になる。(三つの部分はさらにその中にダッシュを含んでも良い。configure は、どのダッシュがどの役割を果たすかを区別できる。) 例えば、m68k-sun-sunos4.1 は Sun 3 を指定する。
コンフィギュレーションの一部をニックネームまたは別名で置き換えることもできる。例えば、sun3 は m68k-sun を表すので、sun3-sunos4.1 としても Sun 3 を指定したことになる。これをさらに簡単にして sun3-sunos としても良い。なぜなら、SunOS のバージョンはデフォルトがバージョン 4 であると仮定されているからである。
システムタイプのどれにでも、そして CPU タイプの幾つかにはその後にバージョン番号を指定することができる。大部分の場合は、バージョンは関係なく、無視される。このため、知っている場合にはバージョンを指定しても良い。
サポートされているコンフィギュレーション名の一覧と多くのコンフィギュレーションについての注意書きについては、Configurations を参照のこと。
configure を実行するとき、ハードウェアとソフトウェアを記述する特定のオプションを追加で指定する必要があるかもしれない。コンフィギュレーションの一部を独立に指定できるようになっている。それは、--with-gnu-as、--with-gnu-ld、--with-stabs、--nfp である。
--with-gnu-as
GNU CC を GNU アセンブラ(GAS) と共に使うなら, configure の実行時に --with-gnu-as を指定することでその旨を宣言する必要がある。
このオプションを指定しても、GAS のインストールは行なわない。GNU CC の出力を GAS で処理できるように修正するだけである。GAS の構築とインストールは読者の責任である。
逆に、GAS を使うことを希望せず、構築時に --with-gnu-as を指定しないのであれば、GAS がインストールされていないことを確認するのは読者の責任である。GNU CC は、as という名前のプログラムを色々なディレクトリから探す。もし見つけたプログラムが GAS であれば、GAS が実行されることになる。GNU CC が使っているアセンブラがどこにあるのかわからない場合は、-v を指定して実行してみよう。
GAS を使うかどうかによって違いが生じるシステムは以下の通りである。hppa1.0-any-any、 hppa1.1-any-any、i386-any-sysv、 i386-any-isc、
i860-any-bsd、 m68k-bull-sysv、 m68k-hp-hpux、m68k-sony-bsd、
m68k-altos-sysv、 m68000-hp-hpux、 m68000-att-sysv、any-lynx-lynxos、mips-any)。これら以外のシステムでは、--with-gnu-as は何の効果もない。
上に列挙したシステムでは(HP-PA, i386 上の ISC、mips-sgi-irix5.* を除く)、GAS を使う場合には GNU リンカも使うべきである(--with-gnu-ld を指定する)。
--with-gnu-ld
GNU CC と一緒に GNU リンカを使う予定なら、--with-gnu-ld オプションを指定する。
このオプションでは、GNU リンカをインストールしようとはしない。単に、GNU CC の振るまいを GNU リンカと協調して動作するように修正するだけである。
--with-stabs
MIPS ベースのシステムと Alpha では、GNU CC が通常の ECOFF 形式のデバッグ情報を作るか、BSD形式の stabs を ECOFF のシンボルテーブルを通して使うかのどちらかを指定しなければならない。通常の ECOFF デバッグ情報形式は、C 以外の言語を完全には取り扱うことができない。BSD stabs 形式は、他の言語も扱えるが、GNU デバッガ GDB でしか使えない。
通常、GNU CC は、ECOFF 形式のデバッグ情報をデフォルトで使う。BSD stabs の方が良ければ、GNU CC をコンフィギュレーションする際に--with-stabs を指定する。
GNU CC をコンフィギュレーションするさいに、どちらをデフォルトとして選んだかに関わらず、ユーザは -gcoff オプションと -gstabs+ オプションを使って、特定のコンパイル毎にデバッグ情報形式を明示的に指定することができる。
--with-stabs は、i386 上の ISC システムでは、--with-gas も指定されたときに有効になる。このオプションにより、COFF 出力の中に埋め込む形の stabs デバッグ情報を使うことを選択する。この種類のデバッグ情報は C++ もサポートする。通常の COFF デバッグ情報はサポートしていない。
--with-stabs は、i386 上の SVR4 でも有効である。このオプションにより、ELF 出力の中に埋め込む形の stabs デバッグ情報を使うことを選択する。C++ コンパイラは現在(2.6.0)、i386 上の SVR4 プラットフォームで通常使われている DWARF デバッグ情報をサポートしていない。このため、stabs を動作する選択肢となる。このオプションは、gas と gdb を必要とする。通常の SVR4 のツールでは、stabs を生成したり、解釈できないからである。
--nfp
ある種のシステムでは、マシンに浮動小数点ユニットがあるかどうかを指定しなければならない。そういうシステムには、m68k-sun-sunosn や m68k-isi-bsd がある。他のシステムでは、今のところ --nfp は何の効果もないが、それを使って違いを出すと便利なシステムがおそらく他にもあるだろう。
--enable-haifa
--disable-haifa
--enable-haifa を指定すると、ある実験的な命令スケジューラ(IBM Haifa 提供)を使うようにする。これにより生成されるコードが良くなることもあれば、良くならないこともある。良くなることが分かっているいくつかの機種ではデフォルトでこの機能が有効になっている。その場合、無効にするには --disable-haifa オプションを使えば良い。configure を実行すると、Haifa スケジューラが有効になっているかどうかを表示する。
--enable-threads=type
ある種のシステム、特に Linux ベース GNU システムは、Objective C の実行時にスレッド機能を提供するには信頼が置けないので、デフォルトでシングルスレッド実行時になる。だが、これらのシステムにスレッドの実装が利用可能なライブラリがあるかもしれない。その場合、スレッド機能は、このオプションに適切な type、おそらく posix を指定することで有効になる。type の可能な値は、single、posix、win32、solaris、irix、mach である。
--enable-checking
このオプションを指定すると、GCC は、ツリー・ノード型の検査を、そのノードのフィールドを参照したときに、実行するように構築される。これは生成されるコードを変えることはしないが、GCC 内部のエラー検査を追加する。これにより、コンパイル速度は遅くなり、GCC を構築するのにGCC を使ったときにしか正しく動作しないだろう。
configure スクリプトは、GNU CC に統合される他のコンパイラを、ソースディレクトリのサブディレクトリから探す。例えば、C++ 向けの GNU コンパイラは、G++ と呼ばれており、cp というサブディレクトリにある。configure は Makefile にルールを挿入して、これらのコンパイラを全て構築するようにする。
以下に、configure が設定するファイルについて残らず説明する。普通は、以下のファイルに注意を払う必要はない。
- config.h という名前のファイルが作られる。このファイルは、読者がコンパイラを実行する機種の最上位のコンフィギュレーションファイルを #include で取り込む(see Config)。このファイルは、ホスト機種についての情報を定義する責任を持つ。tm.h をインクルードする。
  最上位レベルのコンフィギュレーションファイルはサブディレクトリconfig に置かれている。その名前は常に xm-something.h である。普通は xm-machine.h であるが、幾つか例外がある。
  シンボリックリンクのないシステムでは、config.h を適切なファイルを参照している #include 制御子を含むように設定する必要があるだろう。
- tconfig.h というファイルが作られる。このファイルは、ターゲット機種の最上位レベルのコンフィギュレーションファイルをインクルードする。このファイルは、その機種で動作すべきある種のプログラムをコンパイルするのに使われる。
- tm.h というファイルが作られる。このファイルは、ターゲットマシンのマシン記述マクロを定義するファイルをインクルードする。このファイルは、サブディレクトリ config に置く必要があり、そのファイル名は machine.h であることが多い。
--enable-nls
--disable-nls
--enable-nls オプションを指定すると母国語サポート(Native Language Support, NLS)を有効にする。NLS を使うと、GCC は、合衆国で使われている英語以外の言語で診断メッセージを出力する。メッセージを翻訳したものはまだ利用可能ではないので、このオプションの主なユーザは、GCC の診断メッセージを翻訳している人々であり、翻訳作業結果の確認に使っている。一度翻訳が揃えば、母国語サポートをデフォルトで有効にする予定である。--disable-nls オプションで NLS を無効にできる。
--with-included-gettext
NLS が有効になっていると、GCC の構築手順では普通、ホストマシンにあるgettext ライブラリを使うことをまず試み、それが充分なものでない場合にだけ、GCC に含まれている GNU gettext ライブラリを使う。--with-included-gettext オプションを指定すると、付属の GNU gettext を優先させる。
--with-catgets
NLS が有効になっていると、ホストに gettext はないが、やや劣る catgets インターフェースならあるという場合、GCC の構築手順では普通、catgets は無視して、代わりに GCC に付属のGNU gettext ライブラリを使う。--with-catgets オプションを指定すると、その場合にホストの catgets を使う。
ある特定の場合、configure を実行するときに他の特定のオプションを指定する必要がある。
- GNU CC のインストール先ディレクトリの標準は /usr/local/lib である。どこか別の場所にインストールしたいときは、configure を実行するときに --prefix=dir を指定する。ここで dir は、一つの例外を除く全ての目的について、/usr/local の代わりに使うディレクトリ名である。一つの例外とは、ディレクトリ /usr/local/include であり、コンパイラをどこにインストールしたかに関係なく、ヘッダファイルの検索をこのディレクトリに対して行なう。この名前を上書きしたいときは、以下の --with-local-prefix オプションを使う。ここで指定したディレクトリが存在する必要はないが、その親ディレクトリは存在しなくてはならない。
- ローカルにインストールしたヘッダファイルを検索するのに、/usr/local/include の代わりにに、dir/include を検索させたいときは、--with-local-prefix=dir を指定する。
  --with-local-prefix を指定するのは、読者のサイトが、サイト固有のファイルを置く場所について別の規約(/usr/local 以外)にしている場合にだけすべきである。
  --with-local-prefix のデフォルト値は --prefix の値によらずに /usr/local である。--prefix を指定しても、GNU CC がローカルのヘッダファイルを探しに行くディレクトリには影響がない。これは直観に反するようだが、論理に適っている。
  --prefix の目的は GNU CC をインストールする場所を指定することにある。/usr/local/include にあるローカルのヘッダファイルは--読者がそこに何か置いた場合-GNU CC の一部ではないのである。そこにあるものは他のプログラム--多分たくさんのプログラムの一部である。(GNU CC は自分自分のヘッダファイルは--prefix の値に基づく別のディレクトリにインストールする。)
  --with-local-prefix のデフォルト値は、--prefix の値に関わらず /usr/local である。--prefix を指定しても、GNU CC がローカルのヘッダファイルを検索するディレクトリには影響しない。これは一見すると変に思えるかもしれないが、実際には論理的な帰結である。
  --with-local-prefix として /usr を指定してはならない。--with-local-prefix で指定するディレクトリは、システムの標準ヘッダファイルを一切含んでいてはならないのである。もし含んでいると、ある種のプログラムは正しくコンパイルされない(あるターゲットでの GNU Emacs を含む)。これは、fixincludes スクリプトにより修正がなされるヘッダファイルを上書きし、中身を消してしまうからである。
  このオプションを使う人達は、何のためのオプションかを誤解して使っているという徴候がある。人々は、このオプションを、まるで GNU CC の一部をインストールする場所を指定するものであるかのように使っている。人々がそう考えるのは、おそらく、GNU CC をインストールするときにこのオプションで指定したディレクトリが実際に作られるからだろう。
コンパイラを構築する。ソースディレクトリで make LANGUAGES=c を実行する。
LANGUAGES=c は、C コンパイラのみコンパイルすることを指定する。特に指定しなければ通常は、サポートされている言語全てのコンパイラを構築する。現在サポートされているのは、C、C++、Objective C である。しかし、GNU C コンパイラ以外の他のコンパイラを使って構築する場合に、正しく動作することが保証されるのは C だけである。さらに付け加えるなら、C 以外のものをこのステージで構築するのは時間の無駄である。
一般に、構築したい言語を指定するには、引数 LANGUAGES="list" を追加する。ここで list は、c、c++、objective-c のうちから一つ以上選んで並べたものである。GNU CC のソースディレクトリのサブディレクトリに何か追加言語の GNU コンパイラのソースを持っているなら、その名前をリストに指定しても良い。
insn-emit.c で "statement not reached" という警告が出るかもしれないが、無視して良い。それで問題はない。それから、genopinit.c や、もしかするとそれ以外のファイルでも出るかも知れないが、"unknown escape sequence" という警告も問題がない。同様に、insn-emit.c と insn-recog. の"constant is so large that it is unsigned"、 enquire.o の比較が常に 0 になる旨の警告、それに cexp.y でのシフト回数が型の大きさを越えているというも無視して良い。それ以外のコンパイルエラーは問題の起きるマシンや OS への移植のバグの可能性があるので、調べて報告すべきである(see Bugs)。
コンパイラの中には、バグや制限のために GNU CC をコンパイルできないものがある。例えば、Microsoft のコンパイラはマクロスペースを使い切ってしまうと言われている。いくつかの Ultrix のコンパイラは、式空間を使い切ってしまい、問題が起きたところで文をいくつかに分割しなければならない。
クロスコンパイラを構築する場合は、ここで立ち止まること。See Cross-Compiler。
ステージ1のオブジェクトファイルと実行形式ファイルをサブディレクトリに移すのに、以下のコマンドを実行する。
```
make stage1
```
関連ファイルは stage1 という名前のサブディレクトリに移動される。インストールが完了したなら、ここに置かれたファイルをrm -r stage1 で消しても良い。
GNU CC のコンフィギュレーションとして、システム標準のツールではなく、GNU のツール(GAS や GNU リンカなど)を必要とするものを選んだ場合、その必要とするツールを下位ディレクトリ stage1 にインストールすること。その場合、ファイル名は as、ld 等適切なものにする。こうすることで、ステージ1 のコンパイラが続くステージで適切なツールを見つけられるようになる。
あるいは、後続のコンパイルを行なうのに、環境変数 PATH の値を、必要な GNU ツールがシステム標準のツールの前に来るように設定して行なっても良い。
コンパイラ自身を以下のように再コンパイルする。
```
make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O2"
```
この過程は、ステージ2 コンパイラの作成と呼ばれる。
上に示したコマンドは、サポートされている言語全てが使えるコンパイラを作成する。全部の言語は要らない場合は、作成したい言語を指定するには、引数に LANGUAGES="list" を追加する。list は、c、c++、objective-c、proto のどれか一つ以上の名前を指定する。名前は空白で区切る。proto は、protoize と unprototize プログラムを表す。これらは独立した言語ではないが、インストールするかどうかをLANGUAGES で指定できる。
ステージ3コンパイラを作成するなら、ステージ2 では C 言語のみ作成すれば充分である。
ステージ2 コンパイラが一旦出来てしまえば、ディスクスペースが不足するような場合は、ディレクトリ stage1 を削除しても良い。
68000 や 68020 のシステムで、浮動小数点ハードウェアがない場合は、デフォルトで浮動小数点ハードウェアが無いことを想定しているtm.h を選択しない限り、代わりに以下のようにコンパイルを行なうこと。
```
make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O2 -msoft-float"
```
GNU CC のテストのために、GNU CC 自身で複数回コンパイルする場合は、他に必要な GNU のツール(GAS や GNU リンカ等)を、stage1 でやったのと同じように、 stage2 ディレクトリにインストールしておき、以下を実行する。
```
make stage2
make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O2"
```
この過程はステージ3コンパイラの作成と呼ばれる。-B オプション以外は、ステージ2コンパイラを作ったときと同じオプションを使うようにする。ただ、LANGUAGES オプションは同じである必要はない。上で示したコマンド行は、サポートしている全言語用のコンパイラを構築する。全言語は要らない場合は、構築したい言語を、前述したように、引数LANGUAGES="list" を加えることで指定できる。
他に必要な GNU ツールをインストールしなくても良い場合は、stage1、stage2を作って、コンパイラを二回構築する代わりに、以下のコマンド行を使うことができる。
```
make bootstrap LANGUAGES=language-list BOOT_CFLAGS=option-list
```
最後のオブジェクトファイル群をステージ2のオブジェクトファイル群と比較する。両者は、タイムスタンプ(あれば)を覗いて、同等であるべきだ。
機種によっては、オブジェクトファイルの意味のある比較が不可能な場合がある。常に「異なってしまう」ように見える。これは、今のところ、Solaris と ELF オブジェクトファイル形式を使用している幾つかのシステムが当てはまる。SGI の Irix の幾つかのバージョンと、Alpha システム上の DEC Unix(OSF/1) では、-save-temps を指定しないとオブジェクトファイルを比較できないだろう。比較に失敗したなら、これらの個々のシステムの説明を見て欲しい。他のシステムでも同じような問題が起きるかもしれない。
ファイルの比較を行なうには次のコマンドを使う。
```
make compare
```
これは、ステージ2 とステージ3で異なるオブジェクトファイルについて知らせてくれる。何か違いがあれば、それが無害かどうかに関わらず、ステージ 2 のコンパイラが GNU CC を正しくコンパイルしなかったということを意味し、それゆえ潜在的に重大で、調査したうえで報告(see Bugs)を行なうべきバグが存在する可能性がある。
オブジェクトファイルにタイムスタンプを挿入しないシステムでは、以下のコマンドが比較を行なう速い方法である(Bourne シェルを使っている)。
```
for file in *.o; do
cmp $file stage2/$file
done
```
MIPS のマシンで -mno-mips-tfile オプションを指定してコンパイラを構築した場合は、ファイルを比較することはできない。
コンパイラドライバ、コンパイラの各パス、それに実行時のサポートファイルをインストールするには、make install を実行する。インストールされるファイルをコンパイルしたのと同じ値をCC と CFLAGS、LANGUAGES に対して使うようにする。同じ値にする理由の一つは、Make の中にはバグのために、この段階で不必要にファイルを再コンパイルするものがあるためである。これらの変数の値を同じにしておけば、適切に再コンパイルが行なわれる。
例えば、ステージ2 コンパイラを構築してあれば、以下のようなコマンド行を使えば良い。
```
make install CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O" LANGUAGES="list"
```
これは、ファイル cc1、cpp、libgcc.a をディレクトリ /usr/local/lib/gcc-lib/target/version にあるファイル cc1、cpp、libgcc.a にコピーする。このディレクトリは、コンパイラのドライバプログラムがこれらのファイルを探す場所である。ここで、target は、configure を実行したときに指定したターゲット機種のタイプの正規形であり、version は、GNU CC のバージョン番号である。この名前付の方法により、色々なバージョンやクロスコンパイラが共存可能になる。これはまた、他の言語のコンパイラの実行形式(例えば、C++ 用の cc1plus など)を同じディレクトリにコピーする。
これは、ドライバプログラム xgcc も /usr/local/bin/gcc にコピーするので、典型的なコマンド検索パス中に現れることになる。また、gcc.1 を /usr/local/man/man1 に、info ページを /usr/local/info にコピーする。
システムによっては、このコマンドを実行すると幾つかのファイルを再コンパイルしてしまう。これは普通は make のバグによるものである。これは無視するか、あるいは GNU Make を使えば良い。
注意: Sun のライブラリの alloca にはバグがある。このバグを回避するには、GNU CC でコンパイルされた GNU CC の実行形式をインストールするよう注意すること。(すなわち、stage1 ではなくて、stage2 か 3 で出来た実行形式をインストールする。) GNU CC は、組み込み関数の alloca を使い、ライブラリにあるものは決して使わない。
(通常でも、stage2 また 3 の GNU CC の実行形式をインストールしたほうが良い。というのは、他のコンパイラでコンパイルしたものよりも高速に動作するからである。)
C++ を使おうとしているなら、C++ 実行時ライブラリをインストールする必要がある。全ての入出力機能、特別なクラスライブラリなどを含む。
GNU CC 用の標準C++実行時ライブラリは libstdc++ というものである。旧版の libg++ も利用可能であるが、変換が済んでいない古いソフトウェアにしか必要のないものである。読者が libg++ を必要とするかどうかわからない場合は、おそらく必要としないだろう。
以下に GNU CC 用に libstdc++ を構築し、インストールする方法の一つを示す。
- GNU CC を構築、インストールし、gcc と打つと今作りたての GNU CC が起動されるようにする。
- GCC のバージョンに対応した libstdc++ の配布物を入手する。例えば、libstdc++-2.8.0.tar.gz は GCC 2.8.0 に対応しているはずである。GCC の配布者は普通 libstdc++ も配布している。
- 環境変数 CXX に gcc を指定して、libstdc++ の配布物にある configure コマンドを実行する。configure のオプションには、GCC の configure コマンドに指定したのと同じものを指定すること。
- make を実行して、C++ 実行時ライブラリを構築する。
- make install を実行して C++ 実行時ライブラリをインストールする。
まとめると、GNU CC を構築・インストールしたあと、以下のシェルコマンドをC++ ライブラリの配布物の最上位ディレクトリで実行することになる。configure-options には、GNU CC のコンフィギュレーションで使用したのと同じオプションを指定する。
```
$ CXX=gcc ./configure configure-options
$ make
$ make install
```
GNU CC には Objective-C の実行時ライブラリが含まれている。Objective-C 言語の不可欠な部分だからである。このライブラリに関連するファイルは objc というサブディレクトリに置かれている。GNU Objective-C Runtime Library をコンパイルするにはターゲットのC ライブラリのヘッダファイルが必要であり、スレッドサポートが必要ならターゲットのスレッドライブラリのヘッダファイルも必要である。クロスコンパイルの場合のヘッダファイルの問題については、See Cross-Compilers and Header Files。
configure を実行すると、ターゲットのプラットフォームに適したObjective-C のスレッド実装ファイルを選び出す。場合によっては、複数のスレッド実装をサポートしているプラットフォームがあったり、スレッドサポートを完全に無効にしたいなどの理由により、異なるバックエンドを選びたいこともあるだろう。それには、make の実行時に、コマンド行で Makefile 変数のOBJC_THREAD_FILE に値を指定すれば良い。例えば以下のようにする。
```
make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O2" OBJC_THREAD_FILE=thr-single
```
以下に現在利用可能なバックエンドの一覧を示す。
- thr-single スレッドサポートを無効にするもので、全てのプラットフォームで動作するはずである。
- thr-decosf1 DEC OSF/1 のスレッドサポートである。
- thr-irix SGI IRIX のスレッドサポートである。
- thr-mach 汎用の MACH スレッドサポートである。NEXTSTEP 上で動作することがわかっている。
- thr-os2 IBM OS/2 のスレッドサポートである。
- thr-posix 汎用の POSIX スレッドサポートである。
- thr-pthreads Linux ベースの GNU システム上の PCThreads。
- thr-solaris SUN Solaris のスレッドサポートである。
- thr-win32 Microsoft Win32 API のスレッドサポートである。

Node:Configuration Files, Next:Configurations, Up:Installation

`configure` が作り出すファイル達

configure により設定されるファイルを一つずつ挙げてみる。普通は、以下のファイルに注意を払う必要はない。

config.h という名前のファイルが作られ、GCC を実行する機種向けの、最上位のコンフィギュレーションファイルをインクルードする #include が入る。このファイルは、ホスト機種についての情報を定義する責任がある(see Config)。これは tm.h をインクルードする。
最上位のコンフィグレーションファイルは、サブディレクトリ config に置かれている。ファイル名は常に xm-something.h という形である。普通は xm-machine.h となるが、いくつか例外がある。
シンボリックリンクをサポートしていないシステムでは、config.h が適切なファイルを参照する #include を含むように設定する必要があるだろう。
tconfig.h という名前のファイルが作られ、ターゲット機種向けの最上位のコンフィギュレーションファイルをインクルードする。これは、その機種で動作する特定のプログラムをコンパイルするのに使われる。
tm.h という名前のファイルが作られ、ターゲット機種向けの機種記述マクロファイルをインクルードする。これは、サブディレクトリ config に置かれており、machine.h という名前になることが多い。
コマンドファイル configure は、また、テンプレートファイルMakefile.in にテキストを追加して Makefile を作成する。追加テキストは、config ディレクトリの、t-target ファイルと x-host ファイルから取られる。これらのファイルが存在しないと、指定されたターゲットまたはホストに関して追加されるものはないということを意味する。

Node:Configurations, Next:Other Dir, Previous:Configuration Files, Up:Installation

GNU CC でサポートしているコンフィギュレーション

以下はサポートしている CPU のタイプである。

1750a, a29k, alpha, arm, cn, clipper, dsp16xx, elxsi, h8300, hppa1.0, hppa1.1, i370, i386, i486, i586, i860, i960, m32r, m68000, m68k, m88k, mips, mipsel, mips64, mips64el, ns32k, powerpc, powerpcle, pyramid, romp, rs6000, sh, sparc, sparclite, sparc64, vax, we32k.

以下に、認識可能な企業名を示す。見て判るとおり、正式な名前ではなくて、良く使われる省略形を使っている。

acorn, alliant, altos, apollo, apple, att, bull, cbm, convergent, convex, crds, dec, dg, dolphin, elxsi, encore, harris, hitachi, hp, ibm, intergraph, isi, mips, motorola, ncr, next, ns, omron, plexus, sequent, sgi, sony, sun, tti, unicom, wrs.

企業名は、他に与えられた情報では充分でないときにだけ使われる。必要がなければ省略でき、cpu-system のように書いても良い。例えば、vax-ultrix4.2 は vax-dec-ultrix4.2 に同じである。

以下に、認識できるシステム名を示す。

386bsd, aix, acis, amigaos, aos, aout, aux, bosx, bsd, clix, coff, ctix, cxux, dgux, dynix, ebmon, ecoff, elf, esix, freebsd, hms, genix, gnu, linux-gnu, hiux, hpux, iris, irix, isc, luna, lynxos, mach, minix, msdos, mvs, netbsd, newsos, nindy, ns, osf, osfrose, ptx, riscix, riscos, rtu, sco, sim, solaris, sunos, sym, sysv, udi, ultrix, unicos, uniplus, unos, vms, vsta, vxworks, winnt, xenix.

システム名の指定は省略可能である。省略した場合は、configure がCPU と企業名からオペレーティングシステムを推測する。

システム名にバージョン番号を付け足すこともできる。これにより、違いが生じる場合もあるし、違いはない場合もある。例えば、bsd4.3 や bsd4.4 と書いて、BSD のバージョンを区別することができる。sysv3 と sysv4 の場合にはバージョン番号を必要とし、異なった扱いを受ける。

i860-dg-vms のようにありえない組合せを指定すると、configure はエラーメッセージを出すか、指定された情報の一部を無視して残りの部分だけで最善をつくして推測を行なう。configure は、使われる選択肢の正規名を常に出力する。GNU CC は、可能な選択肢の全てはサポートしていない。

ある機種の特定のモデルには名前がついていることがある。機種名の多くは、CPU と企業名の組合せの別名として認識される。例えば、上で述べた sun3 という機種名は、m68k-sun の別名である。企業名を機種名として受け付ける場合もある。この場合、その名前は特定の機種を指すのに広く使われている。以下に既知の機種名の表を示す。

3300, 3b1, 3bn, 7300, altos3068, altos, apollo68, att-7300, balance, convex-cn, crds, decstation-3100, decstation, delta, encore, fx2800, gmicro, hp7nn, hp8nn, hp9k2nn, hp9k3nn, hp9k7nn, hp9k8nn, iris4d, iris, isi68, m3230, magnum, merlin, miniframe, mmax, news-3600, news800, news, next, pbd, pc532, pmax, powerpc, powerpcle, ps2, risc-news, rtpc, sun2, sun386i, sun386, sun3, sun4, symmetry, tower-32, tower.

マシン名は、CPU タイプと会社名の両方を指定するということを覚えていて欲しい。読者が自作したコンフィギュレーションファイルをインストールしたい場合は、会社名として local を使ってそれにアクセスすることができる。コンフィギュレーション cpu-local を使うと、cpu プレフィックスのないコンフィギュレーション名が、コンフィギュレーションファイル名に使われる。

つまり、m68k-local と指定したとすると、このコンフィギュレーションはm68k.md、local.h、m68k.c、xm-local.h、t-local、x-local といったファイルを使う。これらは全てディレクトリ config/m68k に置かれる。

以下のリストは、知っていなければならない、特別な取扱いや特別な事項のあるコンフィギュレーションである。

1750a-*-*

MIL-STD-1750A プロセッサ。

MIL-STD-1750A のクロス・コンフィギュレーションはGNU Public License の元で利用可能な 1750A 向けアセンブラ／リンカであるas1750 用のコードを生成する。as1750 は、ftp://ftp.fta-berlin.de/pub/crossgcc/1750gals/ から入手可能である。同様のライセンスを持つ、1750A 向けシミュレータも同じ所から入手可能である。

libcc を構築中に出る致命的エラーは無視して良い(1750A 向けのlibgcc はまだ実装されていない。)

as1750 アセンブラは ms1750.inc というファイルを必要とする。このファイルはディレクトリ ms1750.inc にある。

GNU CC は、Fairchild F9450 C Compiler と同じセクションを生成する。すなわち、以下のものである。

Normal: プログラムのコード・セクション。
Static: 読み書き(RAM)データ・セクション。
Konst: 読み込み専用(ROM)定数セクション。
Init: 初期化セクション(KREL を SREL にコピーするためのコード)。

アドレス可能な最小単位は 16 ビット(BITS_PER_UNIT が 16)である。これは、`char' 型が、一文字につき 16 ビットの語で表現されるということを意味する。1750A の "Load/Store Upper/Lower Byte" 命令はGNU CC では使われない。

alpha-*-osf1

DEC Alpha アーキテクチャを実装したプロセッサを使い、DEC Unix (OSF/1) が走るシステムである。例えば、DEC Alpha AXP システム等である。

クロスコンパイラとして構築されない限り、GNU CC は .verstamp 疑似命令をアセンブラ出力ファイルに書き出す。これには、システムヘッダファイル /usr/include/stamp.h から取ったバージョンが入っている。DEC Unix の新しいバージョンをインストールするときには、GCC を再構築して、新しいバージョンスタンプを取り出すようにしないといけない。

Alpha は 64 ビットアーキテクチャなので、32ビットの機種で動作するAlpha をターゲットとするクロスコンパイラは、64ビットの機種で動作するコンパイラが生成するコードと同程度に効率の良いコードを生成することはできない。これは、多くの最適化が、ターゲットのワードをホスト上での整数値として表せるということに依存しており、32ビットの機種上では実行できないからである。Alpha 上で動作する、ターゲットを 32 ビット機種とするクロスコンパイラを構築するのは、ほんの2,3の場合しかテストされておらず、多分正しく動かないだろう。

古いバージョンの DEC Unix では、CFLAGS に -save-temps を追加しないと、make compare に失敗する。これらのシステムでは、アセンブラへの入力ファイル名がオブジェクトファイル内に収められているので、そのファイル名が stage1 と stage2 で異なると、比較に失敗してしまうのである。オプション -save-temps を指定すると、アセンブラへの入力ファイル名として、/tmp に置かれる、ランダムに選ばれた名前の代わりに、固定したファイル名を使う。-save-temps オプションは、これを指定しないと比較に失敗するのでない限り、追加しないこと。-save-temps を指定すると、各コンパイルの段階で、.i と .s で終わるファイルを自分で消さないといけない。

GNU CC は現在、DBX と GDB が使うネイティブ(ECOFF)デバッグ情報形式とGDB だけが使う埋め込み STABS 形式の両方をサポートしている。これらのデバッグ情報形式と選択方法についての詳細は、既出のconfigure の --with-stabs オプションの説明を参照のこと。

DEC のアセンブラにはバグがあり、.align 疑似命令を使ったときにECOFF 形式用の行番号情報が正しくないものを生成する。この問題を回避するために、GNU CC は、最適化を実行する場合でもECOFF 形式のデバッグ情報を書き出すときに、この疑似命令をださないようにしている。ただし、残念なことに、これには非常に困る副作用があり、-O を指定したときのコードのアドレスが、-g を合わせて指定するかどうかによって違ってきてしまう。

これを避けるには、-gstabs+ を指定して、DBX の代わりに GDB を使えば良い。DEC も今ではアセンブラのこの問題に気付いていて、早急に修正版を提供しようとしている。

arc-*-elf

Argonaut の ARC プロセッサである。このコンフィギュレーションは組み込みシステム向けである。

arm-*-aout

Advanced RISC Machines 社の ARM 一族のプロセッサである。埋め込みアプリケーションで良く使われている。標準の Unix 用コンフィギュレーションは存在しない。このコンフィギュレーションは基本的な命令列に対応し、a.out 形式のオブジェクトモジュールを生成する。

読者自身の特定のコンフィギュレーション向けには、arm.h の修正版を作る必要がある。

arm-*-linuxaout

a.out バイナリ形式を使う Linux ベース GNU システムの動作するARM プロセッサ(ELF はまだサポートされていない)。GNU/Linux binutils の2.8.1.0.7 以降を使わなければならない。これはsunsite.unc.edu:/pub/Linux/GCC や Linux ベース GNU システム向けの他のミラーサイトから入手することができる。

arm-*-riscix

ARM2 または ARM3 で動作する RISC iX。RISC iX は、Acorn による BSD Unix の移植である。バージョン 1.2 以前の RISC iX を使っている場合は、コンフィギュレーションの際にバージョン番号を明示的に指定しなければならない。RISC iX 付属のアセンブラは、stabs 形式のデバッグ情報をサポートしていないことに注意が必要である。現在、stabs 形式のサポートが入った新しいバージョンのアセンブラが Acorn から入手できる。ftp ではftp.acorn.com:/pub/riscix/as+xterm.tar.Z から入手できる。stabs デバッグ情報を有効にするには configure に--with-gnu-as を指定する。

configure を実行する前に GNU sed をインストールする必要がある。

a29k

AMD の Am29k シリーズのプロセッサである。通常、組み込みアプリケーションで使われる。標準のUNIX 向けのコンフィギュレーションは存在しない。このコンフィギュレーションは、AMD 標準の呼び出しシーケンスとバイナリインターフェースに対応しており、他の 29k 用のツールと互換性がある。

読者自身の特定のコンフィギュレーション向けには、a29k.h の修正版を作る必要がある。

a29k-*-bsd

BSD Unix のある版が動作するシステムで使われている場合のAMD Am29050 である。

decstation-*

MIPS ベースの DECstation は三つの異なるコンフィギュレーションをサポートしている。(Alpha ベースの DECstation 製品のコンフィギュレーション名は alpha-dec で始まる。) Ultrix、DEC OSF/1、OSF/rose である。これらのプラットフォーム向けには以下のようなコンフィギュレーションを使う。

decstation-ultrix: Ultrix のコンフィギュレーション
decstation-osf1: OSF/1 の DEC版。
decstation-osfrose: OSF/1 の Open Software Foundation の参照ポート。これは、オブジェクトファイル形式として、ECOFF の代わりにOSF/rose を使っている。普通、このコンフィギュレーションを選択することはないだろう。

MIPS の C コンパイラに対しては、cp/parse.c をコンパイルするために、オプション -Wf,-XNg1500 を指定して、スイッチ文のテーブルの大きさを大きくしておく必要がある。最適化オプションとして -O2 を使う場合は、-Olimit 3000 も使う必要がある。この二つのオプションはどちらも、configure が構築するMakefile には自動的に追加される。make の変数 CC を上書きして MIPS のコンパイラを使うには、-Wf,-XNg1500 -Olimit 3000 を追加する必要がある。

elxsi-elxsi-bsd

Elxsi の C コンパイラには、GNU C のコンパイルを妨げる制限があることが知られている。詳細については mrs@cygnus.com に連絡して欲しい。

dsp16xx

AT&T の DSP1610 シリーズのプロセッサへの移植である。

h8300-*-*

日立の H8/300 シリーズのプロセッサである。

呼びだし規約と構造体のレイアウトがリリース2.6 で変更された。全てのコードを再コンパイルする必要がある。新しい呼びだし規約では、関数の引数の最初の三つをレジスタで渡す。構造体は、大きさがもはや 2 の倍数のバイト数ではない。

hppa*-*-*

HP-PA プロセッサには色々な種類があり、色々な OS が動作する。GNU CC が正しいプロセッサ型とOSを使うようにコンフィギュレーションをしなければならない。正しくコンフィギュレーションあれていないと、GNU CC は正しく機能しない。この問題に対処する一番簡単な方法は GNU CC のコンフィギュレーションを行なう時にターゲットを指定しないことである。そうすると、configure スクリプトが自動的に正しいプロセッサ型とOSを決定してくれる。

HP-UX では -g は使えない。GNU CC の知らない、独特のデバッグ情報形式を使っているからである。だが、GCC に GAS と GDB を組み合わせて使うなら -g を使うことができる。全ての HP-PA のコンフィギュレーションで GAS を使うことを強くお勧めする。

その場合、GAS-2.6 以降と GDB_4.16 以降を使わなくてはならない。これらは、全ての伝統的 GNU ftp アーカイブサイトから取り寄せることができる。

HP-UX のいくつかのバージョンでは、GNU sed をインストールする必要がある。

コマンド検索パスに、/bin、/usr/bin、/usr/ccs/bin の現れる前に、GAS をインストールするディレクトリを置く必要がある。GNU CC を作る前に GAS をインストールしておく必要がある。

デバッグを可能にするには、構築を行なう前に --with-gnu-as オプションをつけて GNU CC のコンフィギュレーションを行なう。

i370-*-*

この移植はまだまだ予備的であり、たくさんバグがあることがわかっている。この機種向けの品質の良い移植を早急に求めている。

i386-*-linux-gnuoldld

gas/binutils のバージョン 2.5.2 以降をインストール済みでない場合に、Linux ベースの GNU システム上で a.out 形式のバイナリを生成するには、このコンフィギュレーションを使う。これは廃れたコンフィギュレーションである。

i386-*-linux-gnuaout

Linux ベースの GNU システム上でa.out 形式のバイナリを生成するには、このコンフィギュレーションを使う。このコンフィギュレーションは置き換えの途上にある。gas/binutils のバージョン 2.5.2 以降を使う必要がある。

i386-*-linux-gnu

Linux ベースの GNU システム上で ELF 形式のバイナリを生成するには、このコンフィギュレーションを使って。gas/binutils のバージョン 2.5.2 以降を使う必要がある。

i386-*-sco

RCC でコンパイルするのがお勧めである。また、システムに付いてくるmalloc ではなく GNU malloc をリンクするのが良いだろう。

i386-*-sco3.2v4

SCO のリリース 3.2 バージョン4 にはこのコンフィギュレーションを使う。

i386-*-sco3.2v5*

SCO OpenServe Release シリーズの 5.0.0、5.0.2、5.0.4、5.0.5、Internet FastStart 1.0、Internet FastStart 1.1 用である。

GNU CC は -mcoff を指定すると COFF バイナリを生成可能である。デフォルトは ELF バイナリである。ELF を構築する ELF コンパイラが生成されるように完全な make bootstrap を行うことをお勧めする。

TLS597 を ftp://ftp.sco.com/TLS から入手してインストールし、ELF C++ バイナリが 5.0.4 以前のリリースで正しく動作するようにしなければならない。

OS に無料で付いてくる SCO のネイティブ・アセンブラが普通は必要である。だが、GNU アセンブラも使えなくてはならないだろうから(読者が複雑な asm 文を使っているかもしれないから)、このパッケージを--with-gnu-as を指定してコンフィグレーションしなければならない。このためには、gcc/as として GNU アセンブラをインストール(cp か symlink) しておく。新しめの GNU binutils を使わなければならない。バージョン 2.9.1 はうまく動作するようだ。このオプションを選択した場合は、COFF イメージを構築するのは不可能になる。そうしようとすると、はっきりとした形で見えずに失敗に終わるだろう。一般に、"-with-gnu-as" オプションは、ネイティブのアセンブラ程良くはテストされていない。

注意: C++ を構築する場合は、make bootstrap を起動する手順を取る必要がある。ネイティブの OpenServer のコンパイラは、たくさんの正しい C プログラムを正しく構文解析できない cc1plus を作ってしまう可能性があるからである。ネイティブコンパイラで構築を行うときは、make bootstrap しなければならない。

i386-*-isc

システムに付いてくる malloc ではなく GNU malloc をリンクするのが良いだろう。

ISC バージョン 4.1 では、duduced.h を作るときに sed がコアダンプする。バージョン 4.0 の sed を使うこと。

i386-*-esix

システムに付いてくる malloc ではなく GNU malloc をリンクするのが良いだろう。

i386-ibm-aix

GAS のバージョン 2.1 かそれ以降、それに GNU LD の GNU binutils バージョン2.2 かそれ以降を使う必要がある。

i386-sequent-bsd

コンパイルする前に Berkeley 宇宙に行く。

i386-sequent-ptx1*

i386-sequent-ptx2*

configure を実行する前に GNU sed をインストールする必要がある。

i386-sun-sunos4

ブートストラップするには GNU CC の別のバージョンが必要である。これは、現在のバージョンをシステム標準のコンパイラで構築すると、libgcc2.c の一部をコンパイルするときに無限ループに陥るからである。GNU CC の任意のバージョンでコンパイルした GNU CC バージョン 2 にはこの問題はないようだ。

Sun のシステムに GNU CC をインストールする場合の情報については、Sun Install を参照のこと。

i[345]86-*-winnt3.5

このバージョンは、まだリリースされていない GAS を必要とする。それがリリースされるまでの間、前もって構築済みのバイナリ版を<ftp://cs.washington.edu/pub/gnat/> か cs.nyu.edu:pub/gnat から匿名 ftp で入手することができる。また、Windows NT 3.5 SDK の Microsoft のヘッダファイルを使わなければならない。9/4/94 付の CDROM の /mstools/h というディレクトリにこれらが置かれている。NT 3.5 用に特別に作られた、Microsoft リンカの修正版を使わなければならない。これもまた、NT 3.5 SDK CDROM に入っている。このリンカがないときは、Visual C/C++ 1.0 または 2.0 のリンカを使っても良い。

NT に GNU CC をインストールすると、ラッパーとしてのリンカが作られる。これは ld.exe という名前で、ライブラリの指定方法の点で(-L と -l) Unix の ld の動作のまねをする。ld.exe はライブラリの Unix 名と Microsoft 名の両方を探す。例えば、-lfoo と指定すると、ld.exe は最初に libfoo.a を探し、次に foo.lib を探す。

GNU CC を Windows にインストールするには二つの方法がある。どちらを取るかは、Unix 的なシェルと色々な Unix 的なツールが手元にあるかどうかによる。

Unix にあるようなシェルやユーティリティーがないときは、DOS のバッチスクリプト configure.bat を使う。これを、MSDOS のコンソールウィンドウかプログラムマネージャのダイアログボックスから configure winnt として起動する。configure.bat は、Unix にあるような sed プログラムがインストール済みであり、コマンド検索パスに入っていることを想定している。sed を使って、Makefile.in から Makefile を作るのである。
こうしてできる Makefile では、Microsoft の Nmake 保守ユーティリティと Visual C/C++ V8.00 コンパイラを使って GNU CC を構築する。この方法を使う場合には、必要なユーティリティは sed と touch だけであり、コンパイラ自体の構築までしか自動的に行なわない。この後、fixinc.winnt が何をしているのかを眺めて、ヘッダフィアルを編集し、libgcc.a を主動で作らなければならない。
二番目のインストール方法では、Unix にあるようなシェルが使えて、Unix にあるようなユーティリティが充分揃っていてコマンド検索パスに入っていて、かつ GNU CC の以前のバージョンがインストール済みであることを想定している。GNU CC の古いバージョンは、上記の方法でインストールしたものでも構わないし、事前に構築されたバイナリを使っても構わない。この場合は、ふつうと同じく configure スクリプトを使えば良い。

i860-intel-osf1

これは Paragon 用である。

バージョン 1.0 のオペレーティングシステムを使っている場合は、システムの癖に対処するために特別な手順が必要なので、Installation Problems を参照のこと。

*-lynx-lynxos

LynxOS 2.2 およびそれ以前。これらは、GNU CC 1.x が /bin/gcc としてインストールされてくる。/bin/cc ではなく /bin/gcc を使ってコンパイルすべきである。GNU CC に GNU アセンブラと GNU リンカを使うように指示するには、コンフィギュレーション時に --with-gnu-as --with-gnu-ld を指定すれば良い。これらは、COFF 形式のオブジェクトファイルと実行形式ファイルを生成する。GNU アセンブラとリンカを使わない場合は、GNU CC はインストールされているツールを使い、a.out 形式の実行形式ファイルを生成する。

m32r-*-elf

三菱 M32R プロセッサ。このコンフィギュレーションは組み込みシステム用である。

m68000-hp-bsd

BSD Unix が動作する HP 9000 シリーズ 200 である。このシステム付属の C コンパイラでは GNU CC をコンパイルできないことに注意。ブートストラップ用の GNU CC のバイナリを入手するにはlaw@cygnus.com に連絡して欲しい。

m68k-altos

Altos 3068 である。GNU アセンブラ、GNU リンカ、GNU デバッガを使わなければならない。詳細は、README.ALTOS というファイルを参照すること。

m68k-apple-aux

A/UX が稼働する Apple の Macintosh である。GCC をコンフィギュレーションするのに、システムのアセンブラとリンカを使っても良いし、GNU のアセンブラとリンカを使っても良い。出来れば GNU のものを使うべきである。特に GNU C++ も使いたい場合は。GNU のアセンブラとリンカを使うコンフィギュレーションにするには、configure にオプション --with-gnu-as と--with-gnu-ld を追加すれば良い。

システムに付属の C コンパイラでは GNU CC をコンパイルできないことに注意して欲しい。GNU CC をブートストラップするには jagubox.gsfc.nasa.gov にあるバイナリを使うことができる。また、同じところにあるパッチを当てたバージョンの /bin/ld を使うと、もともとのバージョンにある手前勝手な制限値をいくらか上げることができる。

m68k-att-sysv

AT&T 3b1、別名 7300 PC である。この機種で、標準の C コンパイラを使ってGNU CC をコンパイルするには特別な手順が必要である。これは標準のコンパイラのバグのせいである。GNU CC の以前のバージョンをインストールしてあるなら、もっと簡単にブートストラップできる。

GNU CC を 3b1 にインストールするのは、既に動作する GNU CC がないと困難である。これは、インストール済みの C コンパイラにバグがあるためである。しかし、以下のような手順でおそらくうまく行くだろう。我々には、この手順はテスト不可能である。

cccp.c の先頭付近の #include "config.h" をコメントアウトして、make cpp を行なう。これで、GNU cpp の準備版を作る。
古い /lib/cpp を退避し、GNU cpp の準備版をこのファイル名でコピーする。
cccp.c の変更を取り消すか、オリジナル版を再インストールし、もう一度 make cpp を行なう。
こうしてできた GNU cpp の最終版を /lib/cpp にコピーする。
ファイル tree.c に現れる obstack_free を全て_obstack_free に置き換える。
make を実行して、GNU CC のファーストステージを作る。
/lib/cpp をオリジナルのものに戻す。
これで、普通の手順で、GNU CC をそれ自身でコンパイルしたり、インストールすることが可能になった。

m68k-bull-sysv

Bull DPX/2 のシリーズ 200 と 300 で、BOS-2.00.45 から BOS-2.01 を使っているもの。GNU CC は、システム付属のアセンブラとでもGNU アセンブラとでも使うことができる。configure スクリプトに対し --with-gnu-as を指定することで GNU アセンブラとシステムのCOFF 形式の組合せで使うこともできるし、--with-gnu-as --stabs を指定することで GNU アセンブラとDBX 形式を COFF 形式に包み込んだ形との組合せで使うこともできる。システムアセンブラの問題や DPX/2 用の GAS の入手方法については、F.Pierresteguy@frcl.bull.fr に問い合わせて欲しい。

m68k-crds-unox

Unos で構築するには configure unos とする。

Unos のアセンブラは、as ではなく casm という名前である。何らかの変な理由により、/bin/as を /bin/casm にリンクすると、動作が代わってしまうのでうまく行かない。このため、GNU CC をインストールする際には、GCC の各パスがインストールされるサブディレクトリに以下のようなスクリプトを as という名前でインストールする必要がある。

#!/bin/sh
casm $*

デフォルトの Unos のライブラリは、libc.a ではなく、libunos.a という名前である。GNU CC を機能させるためには、gcc.c の中の -lc への全ての参照を -lunos に変えるか、/lib/libc.a を /lib/libunos.a にリンクするかのどちらかを行なう。

GNU CC をシステム標準のコンパイラでコンパイルするには、alloca のバグを避けるため、ステージ 2 を作るときに-O を使わないようにすること。そうしておいて、ステージ 3 のコンパイラは、ステージ 2 コンパイラに -O を指定して作る。こうして出来るステージ 3 のコンパイラは、他のシステムでの通常のステージ 2 のコンパイラと同じ性格を持つものである。これを使って、ステージ 4 のコンパイラを作り、ステージ 3 のコンパイラと比較して、コンパイルが正しく行なわれたかどうかを検査すること。

(恐らく、x-crds にあるコメントにあるように、単に x-crds でALLOCA を定義すれば、上のパラグラフの話は不要になると思われる。うまく行った人がいたら、是非とも教えて欲しい。)

Unos は、要求時ページングではなくてメモリセグメンテーションを使っているので、メモリがたくさん必要になる。他のタスクが走っていなければ、5Mb でぎりぎり足りる。cc1 をリンクするのに失把したら、オブジェクトファイルをライブラリに入れたうえで、そのライブラリとリンクしてみて欲しい。

m68k-hp-hpux

HP-UX が動作する HP 9000 シリーズの 300 か 400 である。HP-UX バージョン 8.0 のアセンブラにはバグがあり、GNU CC をコンパイルできない。このバグを修正するには、HP からパッチ PHCO_4484 を入手して欲しい。

また、--with-gnu-as を指定して GAS を使いたい場合には、GAS のバージョン 2.1 以降と GNU リンカのバージョン 2.1 を使わなければならない。初期のバージョンの GAS は、GAS の出力を HP-UX のネイティブ形式に変換するプログラムに依存していた。だが、そのプログラムが更新されていないのである。GDB は HP-UX のネイティブ形式を理解しないので、GDB を使いたい場合も GAS を使う必要がある。

m68k-sun

Sun 3 である。デフォルトでは Sun FPA を使うコンフィギュレーションファイルは提供していない。浮動小数点トラップ向けのシグナルハンドラを設定するプログラムは、本質的に FPA と一緒には動作不可能だからである。

Sun のシステムでの GNU CC のインストールに関する情報については、Sun Install を参照のこと。

m88k-*-svr3

AT&T/Unisoft/Motorola V.3 のリファレンスポートが動作する、モトローラ m88k である。これらのシステムでは、標準の C コンパイラとしてGreen Hills C リビジョン 1.8.5 が使われることが多い。このコンパイラには明らかにバグがあり、そのため、ステージ 2 とステージ 3 のオブジェクトファイルが異なるものになってしまう。そうなった場合、ステージ 4 のコンパイラを作って、ステージ 3 と比較するようにして欲しい。その結果、ステージ 3 とステージ 4 のオブジェクトファイルが同じであったら、標準の C コンパイラのバグに遭遇した可能性が高い。こうして出来たステージ 3 とステージ 4 のコンパイラは使えると思う。

だがしかし、ブートストラップするのに一番良いのは、もしあるなら古いバージョンの GNU CC を使うことである。

m88k-*-dgux

DG/UX の動作するモトローラの m88k である。DG/UX 上の 88open BCS のネイティブコンパイラまたはクロスコンパイラを構築するには、コンフィギュレーション名として m88k-*-dguxbcs を指定し、88open BCS のソフトウェア開発環境で構築を行なう。DG/UX 上の ELF のネイティブコンパイラまたはクロスコンパイラを構築するには、mm8k-*-dgux を指定し、DG/UX ELF 開発環境で構築を行なう。ソフトウェア開発環境を設定するには、sde-target コマンドを使い、引数として m88kbcs かm88kdguxelf を指定する。

コンフィギュレーション名を指定しないと、configure が、現在のソフトウェア開発環境に基づいたコンフィギュレーションを推測する。

m88k-tektronix-sysv3

UTekV 3.2e の動作する Tektronix XD88 である。バグの多い Green Hills のコンパイラでブートストラップを行なうときは、ステージ 1 を作るとき最適化を行なわないこと。また、付属の LAI System V NFS もバグが多いので、NFS マウントされたディレクトリで構築する場合は、一回リブートしてから行なうこと。あるいは、NFS は全く使わないほうが良いだろう。さもないと、ステージ間の比較で問題が起きる可能性がある。

mips-mips-bsd

MIPS のオペレーティングシステムを BSD モードで実行しているMIPS のマシンである。このシステムの古いバージョンには、memcpy、memcmp、memset といった関数がないものがある。読者のシステムにこれらの関数がない場合は、mips-bsd.h 中の TARGET_MEM_FUNCTIONS の定義を削除するか未定義にする必要がある。

MIPS の C コンパイラは、switch 文用の表の大きさを-Wf,-XNg1500 オプションで増加させておかないと、cp/parse.c をコンパイルできないと言われている。最適化オプション -O2 を使うには、-Olimit 3000 も必要である。この二つのオプションは両方とも、configure が作る Makefile には自動的に追加される。make の変数 CC を上書きして MIPS のコンパイラを使うには、-Wf,-XNg1500 -Olimit 3000 を追加する必要がある。

mips-mips-riscos*

RISC-OS の動作する MIPS のマシンでは、4つの異なる個性をサポートする。デフォルトと BSD 4.3、System V.3、System V.4 である。(RISC-OS の古いバージョンでは V.4 はサポートしていない)。これらのプラットフォーム用に GCC をコンフィギュレーションするには、次のコンフィギュレーションを使う。

mips-mips-riscosrev: リビジョン rev の RISC-OS 用のデフォルトのコンフィギュレーション。
mips-mips-riscosrevbsd: リビジョン rev の RISC-OS 用の BSD 4.3 のコンフィギュレーション。
mips-mips-riscosrevsysv4: リビジョン rev の RISC-OS 用の System V.4 のコンフィギュレーション。
mips-mips-riscosrevsysv: リビジョン rev の RISC-OS 用の System V.3 のコンフィギュレーション。

ここでリビジョン rev は、RISC-OS のリビジョンである。RISC-OS のリビジョン 4 からリビジョン 5 に移るときはGCC を再コンフィギュレーションしなければならない。これは、リンカのバグ(詳細については Installation Problems) を回避する効果がある。

mips-sgi-*

SGI IRIX 4 で GCC をコンパイルするには、Silicon Graphics 提供のCD-ROM から "c.hdr.lib" というオプションをインストールする必要がある。これは、リリース 4.0.1 の二枚目の CD に入っている。

SGI IRIX 5 で GCC をコンパイルするには、Silicon Graphics 提供のIDO CD-ROM から "compiler_dev.hdr" というサブシステをインストールする必要がある。

IRIX 5 では、CFLAGS に -save-temps を追加しないと、make compare に失敗する。このシステムでは、アセンブラに対する入力ファイル名がオブジェクトファイルに格納されるので、そのファイル名が stage1 と stage2 で違っているとオブジェクトファイルの比較に失敗する。オプション -save-temps を指定すると、アセンブラに対する入力ファイル名として、/tmp に置かれるランダムに選ばれた名前ではなくて、決まった名前を使う。-save-temps は、これなしでは比較に失敗するのでない限り、指定しないこと。これを指定してしまうと、各コンパイル段階の後で.i ファイルと .s ファイルを自分で削除しなければならなくなる。

MIPS の C コンパイラの場合は、switch 文用の表の大きさを-Wf,-XNg1500 というオプションを指定することで大きくしておかないとcp/parse.c がコンパイルできないと報告されている。最適化オプション -O2 を指定するときは、-Olimit 3000 も指定する必要がある。このどちらのオプションも、シェルスクリプト configure が作るMakefile では自動的に生成される。 make の変数 CC を上書きして、MIPS のコンパイラを使うときは、-Wf,-XNg1500 -Olimit 3000 というオプションを指定する必要がある。

Irix のバージョン 4.0.5F、それに多分その他のバージョンでも同じだが、アセンブラにバグがあり、命令の並べ替えが正しく行なわれない。これを回避するには、ターゲットのコニフィギュレーションをmips-sgi-irix4loser と指定する。このコンフィギュレーションは、アセンブラによる最適化を抑止する。

ターゲット mips-sgi-irix4 でコンフィギュレーションした場合は、アセンブラの最適化は -noasmopt オプションで抑止できる。このオプションはアセンブラには -O0 として渡り、命令の並べ替えを行なわない。

-noasmopt オプションを使うと、問題がアセンブラによる命令並べ替えに間違っているために起きるかどうかを調べることができる。-noasmopt を指定しても問題がなくならない場合でも、なおアセンブラによる命令並べ替えの問題のせいである可能性がある。この問題のために、GNU CC 自体が正しくコンパイルされていない恐れがある。

Irix 5 でデバッグを出来るようにするためには、GNU as の 2.5 以降を使わなければならず、gcc をコンフィギュレーションするときに configure のオプションに --with-gnu-as を指定しなければならない。GNU as は、binutils パッケージの一部として配布されている。

mips-sony-sysv

Sony MIPS NEWS である。これは NEWSOS 5.0.1 ではうまくいくが、5.0.2 ではうまくいかない(5.0.2 では COFF ではなく ELF が使われている)。5.0.2 は恐らくボランティアの手ですぐにサポートされるだろう。特に、共有ライブラリをリンクするときに GCC で生成されたコードをリンカが嫌う。

ns32k-encore

Encore ns32000 システムである。Encore システムは BSD の場合のみサポートされている。

ns32k-*-genix

National Semiconductor の ns32000 システムである。Genix の alloca と malloc にはバグがあるので、GNU Emacs からコンパイル済みの版を取ってきて使う必要がある。

ns32k-sequent

コンパイルを行なう前に Berkley 宇宙に移行する。

ns32k-utek

UTEX の ns32000 システム("merlin") である。システム付属の C コンパイラでは GNU CC をコンパイルできない。tektronix!reed!mason に連絡を取って、ブートストラップに必要な GNU CC のバイナリを入手して欲しい。

romp-*-aos

romp-*-mach

IBM RT PC をサポートしている OS は、AOS と MACH だけである。GNU CC は RT 上の AIX をサポートしていない。GNU CC をコンパイルするには、GNU CC 自体の古いバージョンlを使うことをお勧めする。Metaware のコンパイラである hc でコンパイルするのは、一応動作するが、ステージ 2 とステージ 3 のオブジェクトの比較で、色々なファイルが一致しないだろう。これらの問題は、幾つかの浮動小数点定数のわずかな差異によるもので、安心して無視できるものである。ステージ 3 のコンパイラが正しいものである。

rs6000-*-aix

powerpc-*-aix

IBM XLC コンパイラの各リリースの色々な初期バージョンでは、GNU CC のブートストラップができない。症状としては、stage2 と stage3 のオブジェクトファイルの差異と、libgcc.a あるいは enquire をコンパイルするときのエラーがある。問題があることが判明しているリリースは以下の通り。xlc-1.2.1.8、xlc-1.3.0.0 (AIX3.2.5 と共に配布されている)、xlc-1.3.0.19 である。xlc-1.2.1.28 と xlc-1.3.0.24 (PTF 432238) はどちらも正しく動作するGNU CC を生成できることがわかっているが、より最近のリリースの方がGNU CC を正しくブートストラップできる。

リリース 4.3.0 の AIX と AIX 3.2.4 以前のリリースに含まれる IBM のアセンブラは、デバッグ情報疑似命令を受け付けない。このアセンブラに対する修正はPTF として入手可能である。さらに、AIX 3.2.5 以降および GNU アセンブラを使う場合は、GNU C コンパイラを構築するためには、1995年10月16日以降に修正されたバージョンの GNU アセンブラが必要である。以上の問題の詳細については README.RS6000 というファイルを参照のこと。

GNU CC は、まだ 64ビットの PowerPC 命令をサポートしていない。

このアーキテクチャでは Objective C は動作しない。呼び出し規約と互換性のない仮定をしているからである。

RS/6000 上の AIX では、合衆国以外の環境をサポートしている(NLS)。コンパイラとアセンブラは NLS を使って、浮動小数点数(浮動小数「点」として「.」と「,」のどちらを使うか)を含む様々なオブジェクトのロケール固有の表現をサポートしている。GNU CC でリンクしたライブラリが、アセンブラが受け付けるのと同じ浮動小数点形式を生成しないという問題が報告されている。この問題に出会ったら、環境変数 LANG を"C" か "En_US" に設定してみて欲しい。

AIX 4.1 用では、GNU CC がバインダ(リンカ)を起動する方法が変わったので、リンク時に、以前は出なかった、シンボルが二重定義されているという警告がでるかもしれない。AIX 用の GNU CC で生成されたアセンブリファイルは、元のプログラムに存在する、ある種のグローバル変数と関数の宣言について、シンボルの複数定義を含んでいる。警告が出ても、リンカは正しいライブラリや実行可能な実行形式を生成するはずである。

デフォルトでは、AIX 4.1 は Power でも PowerPC でも使えるコードを生成する。

-mcpu=cpu_type オプションに対するデフォルトをconfigure のオプション --with-cpu-cpu_type オプションで指定することができる。

powerpc-*-elf

powerpc-*-sysv4

System V.4 の動作する、ビッグエンディアンモードのPowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトをconfigure のオプション --with-cpu-cpu_type オプションで指定することができる。

powerpc-*-linux-gnu

Linux ベースの GNU システムの動作する、ビッグエンディアンモードのPowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトをconfigure のオプション --with-cpu-cpu_type オプションで指定することができる。

powerpc-*-eabiaix

-mcall-aix がデフォルトで選択された、ビッグエンディアンモードの組み込み PowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトをconfigure のオプション --with-cpu-cpu_type オプションで指定することができる。

powerpc-*-eabisim

PSIM シミュレータの下で動作させるのに使われる、ビッグエンディアンモードの組み込み PowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトをconfigure のオプション --with-cpu-cpu_type オプションで指定することができる。

powerpc-*-eabi

ビッグエンディアンモードの組み込み PowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトをconfigure のオプション --with-cpu-cpu_type オプションで指定することができる。

powerpcle-*-elf

powerpcle-*-sysv4

System V.4 の動作する、リトルエンディアンモードのPowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトをconfigure のオプション --with-cpu-cpu_type オプションで指定することができる。

powerpcle-*-solaris2*

Solaris 2.5.1 以降の動作する、リトルエンディアンモードの PowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトをconfigure のオプション --with-cpu-cpu_type オプションで指定することができる。Sun 4.0 コンパイラのベータ版では GNU CC を正しく構築できないようだ。また、ホストアセンブラとリンカにも問題がある。この問題はGNU 版でこれらのツールを置き換えることで対処できる。

powerpcle-*-eabisim

PSIM シミュレータの下で動作させるのに使われる、リトルエンディアンモードの組み込み PowerPC システム。

powerpcle-*-eabi

リトルエンディアンモードの組み込み PowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトをconfigure のオプション --with-cpu-cpu_type オプションで指定することができる。

powerpcle-*-winnt

powerpcle-*-pe

Windows NT の動作する、リトルエンディアンモードの PowerPC システム。

-mcpu=cpu_type オプションに対するデフォルトをconfigure のオプション --with-cpu-cpu_type オプションで指定することができる。

vax-dec-ultrix

Vax C(vcc) でコンパイルしてはいけない。(例えば、alloca が使われた場合に)正しくないコードを生成することがある。

一方、pcc で cp/parse.c をコンパイルするのは、pcc の内部テーブルの大きさの制限のため、うまくいかない。この問題を避けるには、GNU C コンパイラだけをまずコンパイルし、それを使って、必要な全ての言語フロントエンドを再コンパイルするのが良い。

sparc-sun-*

Sun のシステムでの GNU CC のインストールに関する情報については、Sun Install を参照のこと。

vax-dec-vms

VMS への GNU CC のインストール方法の詳細については、VMS Install を参照のこと。

we32k-*-*

この計算機は、3b2、3b5、3b20、その他類似の名前でも知られている。(ただし、3b1 は実際には 68000 である。Configurations 参照。)

システムのコンパイラでコンパイルするときは -g を使わないこと。システムのリンカが、デバッグ情報がついた、このような大きなプログラム扱えないようである。

システムのコンパイラは、GNU CC の stmt.c をコンパイルするときに、能力を越えてしまう。これを回避するには、GNU CC にある cpp をまず構築し、システムのプリプロセッサの代わりに、システムの C コンパイラと組み合わせて stmt.c をコンパイルすることである。以下にその方法を示す。

mv /lib/cpp /lib/cpp.att
cp cpp /lib/cpp.gnu
echo '/lib/cpp.gnu -traditional ${1+"$@"}' > /lib/cpp
chmod +x /lib/cpp

システムのコンパイラは、GNU CC の最適化ファイルの幾つかについて正しくないコードを生成する。このため、ステージ 2 コンパイラは最適化なしで構築しなければならない。その後、ステージ 3 コンパイラを最適化付きで構築する。それで出来上がった実行形式は動作するはずである。以下に実行すべきコマンドを示す。

make LANGUAGES=c CC=stage1/xgcc CFLAGS="-Bstage1/ -g"
make stage2
make CC=stage2/xgcc CFLAGS="-Bstage2/ -g -O"

C++ コンパイラを構築するには ULIMIT の設定を上げる必要があるかもしれない。出来上がった cc1puls は、1メガバイトを越えるので。

Node:Other Dir, Next:Cross-Compiler, Previous:Configurations, Up:Installation

別ディレクトリでのコンパイル方法

オブジェクトファイルと実行形式ファイル、ソースのあるディレクトリとは別のディレクトリに作りたい場合は、以下の部分で手順が異なる。

VPATH の機能をサポートしている Make が必要である。(GNU Make はサポートしている。大抵の BSD システムの Make もサポートしている。)
ソースディレクトリで configure を実行したことがあるなら、そのコンフィギュレーションを取り消さなければならない。そのためには以下のコマンドを実行する。
```
make distclean
```
configure を実行する前に、コンパイラを作成するディレクトリに移動する。
```
mkdir gcc-sun3
cd gcc-sun3
```
シンボリックリンクのないシステムでは、このディレクトリはソースコードのあるディレクトリと同じファイルシステムになければならない。
configure がどこにあるのかを実行時に指定してやる。
```
../gcc/configure ...
```
これでも configure にコンパイラのソースがどこにあるのかを教えたことになる。configure は、自分が起動されたときのファイル名からディレクトリを取り出すからである。この指定を確実にしたければ、--srcdir オプションを使ってソースディレクトリを指定することもできる。例えば、以下のようにすれば良い。
```
../gcc/configure --srcdir=../gcc other options
```
--srcdir で指定したディレクトリが、configure の存在するディレクトリと同じである必要はない。

これで、make を実行することができる。普通のソースファイルに変更があっても、上記のコンフィギュレーションの手順を繰り返す必要はない。しかし、コンフィギュレーションファイルを変更した場合は、シンボリックリンクがないシステムでは、configure を再実行する必要がある。

Node:Cross-Compiler, Next:Sun Install, Previous:Other Dir, Up:Installation

クロスコンパイラの構築とインストールの方法

GNU CC は、多くの機種に対してクロスコンパイラとして機能するが、全部の機種に対してというわけではない。

Mips をターゲットとするクロスコンパイラは、 Mips のアセンブラを使うと現時点では動作しない。mips-tdump.c と mips-tfile.c という補助プログラムが、Mips 上でないとコンパイルできないからである。GNU アセンブラとリンカを使えば Mips 用にクロスコンパイルが行なえる。
浮動小数点形式が異なるマシン間でのクロスコンパイラは、正しく動作するようにはなっていない。GNU CC には、今では、これらのクロスコンパイラと協調して動作する浮動小数点エミュレータがあるが、それを利用するためには各ターゲットのマシン記述を更新する必要がある。
ワード長が異なるマシン間でのクロスコンパイルはいくらか問題があり、動作しない場合もある。

GNU CC はアセンブラコードを生成するので、オブジェクトファイルを作るには、おそらく、GNU CC が実行させることのできるクロスアセンブラが必要になる。ターゲット機種以外のマシンでリンクを行ないたければ、同様にクロスリンカも必要になる。また、ホストマシンにインストール可能なターゲット機種用のヘッダファイルとライブラリも必要になる。

Steps of Cross: クロスコンパイラを使うには、別のマシンで実行すべきステップがいくつかある。
Configure Cross: クロスコンパイラのコンフィギュレーション
Tools and Libraries: リンカとアセンブラ、C ライブラリの位置
Cross Headers: クロスコンパイラ用のヘッダファイルの検索とインストール
Cross Runtime: 算術演算実行時ルーチン(libgcc1.a)の準備
Build Cross: クロスコンパイラを実際にコンパイルするには

Node:Steps of Cross, Next:Configure Cross, Previous:Cross-Compiler, Up:Cross-Compiler

クロスコンパイルのステップ

クロスコンパイラを使って、プログラムをコンパイル、実行するには以下のような段階を経る必要がある。

クロスコンパイラをホストマシンで走らせ、ターゲットマシン向けのアセンブラファイルを生成する。これには、ターゲットマシン向けのヘッダファイルが必要である。
クロスコンパイラが生成したファイルをアセンブルする。これはターゲットマシン上のアセンブラでやることも可能だし、ホストマシン上のクロスアセンブラを使う方法も可能である。
アセンブルしたファイルをリンクして実行形式を作る。これはターゲットマシン上のリンカでやることも可能だし、ホストマシン上のクロスリンカを使って方法もある。どちらのマシンで実行するにしても、ターゲットマシン向けのライブラリやスタートアップファイル(普通は crt....o) が必要だ。

大体の場合は、同じホストマシン上で全部やってしまうのが簡単である。というのは、GNU CC を一回起動するだけで済んでしまうからである。このためには、適当なクロスアセンブラやクロスリンカが必要である。幾つかのターゲットでは、GNU アセンブラと GNU リンカが用意されている。

Node:Configure Cross, Next:Tools and Libraries, Previous:Steps of Cross, Up:Cross-Compiler

クロスコンパイラのコンフィギュレーション

GNU CC をクロスコンパイラとして構築するには、configure を実行することから始める。--target=target を使ってターゲットを指定する。configure が使っているシステムを正しく認識しないときは、--build=build も合わせて指定する。以下の例では、HP の 68030 を使った BSD システム向けのコードを生成するクロスコンパイラのコンフィギュレーションを行なっている。これは、configure を実行しているシステムが正しく認識される場合である。

./configure --target=m68k-hp-bsd4.3

Node:Tools and Libraries, Next:Cross Runtime, Previous:Configure Cross, Up:Cross-Compiler

クロスコンパイラ用のツールとライブラリ

クロスアセンブラとクロスリンカが利用できるのであれば、ここでインストールする。/usr/local/target/bin というディレクトリにこれらを置く。このディレクトリに置くべきツールの一覧を以下に示す。

as: クロスアセンブラ。
ld: クロスリンカ。
ar: クロスアーカイバ。ターゲットマシンの形式でアーカイブファイル(ライブラリ) を操作することができるプログラムである。
ranlib: アーカイブファイルのシンボルテーブルを作るプログラム。

GNU CC をインストールするとき、上記のプログラムをこのディレクトリから探し、クロスコンパイラが後で実行するときに探す適切な場所にコピーするかリンクを張る。

これらのファイルを用意する一番簡単な方法は、Binutils パッケージとGAS を構築することである。これらのツールを、GNU CC をコンフィギュレーションするのに使ったのと同じ --host オプションと --target オプションを使ってコンフィギュレーションするようにし、構築とインストールを行なう。このインストールで、Binutils や GAS の実行形式が自動的に適切なディレクトリに置かれる。ただ、残念なことに、Binutils や GAS は、GNU CC がサポートしているターゲットの全てでサポートされているわけではない。

標準 C ライブラリのような、クロスコンパイラと共に使うライブラリをインストールする場合は、それらを /usr/local/target/lib に置くこと。GNU CC をインストールすると、このディレクトリに置かれている全てのファイルが、GNU CC が検索してリンクを行なう正しい場所にコピーされる。以下に、ターゲット機種からライブラリを幾つかコピーする例を示す。

ftp target-machine
lcd /usr/local/target/lib
cd /lib
get libc.a
cd /usr/lib
get libg.a
get libm.a
quit

必要になるライブラリの正確な組と、ターゲットマシン上での位置は、オペレーティング・システムに非常に依存する。

多くの機種では、crt0.o や crtn.o のような、各実行形式ファイルにリンクされる「開始ファイル」を必要とする。この二つのファイルは、/usr/local/target/lib に存在しなければならない。crt0.o には複数の変種が存在する可能せいがある。これは、プロファイリングや他のコンパイルオプションに応じて使われる。ターゲットの STARTFILE_SPEC の定義を見て、どういう開始ファイルを使っているかを見て欲しい。以下に、これらのファイルをターゲットマシンからコピーする方法の例を示す。

ftp target-machine
lcd /usr/local/target/lib
prompt
cd /lib
mget *crt*.o
cd /usr/lib
mget *crt*.o
quit

Node:Cross Runtime, Next:Cross Headers, Previous:Tools and Libraries, Up:Cross-Compiler

`libgcc.a` とクロスコンパイラ

GNU CC でコンパイルしたコードは、決まった実行時サポート関数を暗黙に使う。このうちの幾つかの関数は、GNU CC 自身で問題なくコンパイルできるのだが、幾つかできないものがある。問題となる関数はソースファイル libgcc1.c にあるものである。このファイルから作られるライブラリは libgcc1.a と呼ばれる。

ネイティブコンパイラを構築するときは、これらの関数は何か他のコンパイラでコンパイルされる。そのコンパイラとはGNU CC をブートストラップするのに使っているものである。おそらく、そのコンパイラは、これらの演算を開かれたコードで書く方法を知っているだろうし、あるいは、その機種に付いてくるはずの実行時のエミュレーション機能を呼び出す方法を知っているだろう。だが、この方法はクロスコンパイラを構築する場合には使えない。構築に使うコンパイラはホストシステムについては知っているが、ターゲットシステムのことは知らないからである。

このため、クロスコンパイラを構築する際には、期待される仕事を行なう適切なライブラリ libgcc1.a を用意する必要がある。

libgcc1.c をクロスコンパイラ自体でコンパイルするのはうまくいかない。このファイルにある関数群は、GNU CC が読者のターゲット機種用にはどうやって開かれた形でコードを書けば良いか知らないような算術演算を実装するものであると想定されている。これらの関数を GNU CC 自体でコンパイルしたなら、無限に再帰的なコンパイルになってしまう。

任意の与えられたターゲットで、これらの関数のほとんどは必要ではない。GNU CC が、算術演算を開いたコードに書けるなら、これらの関数を呼び出さない。読者のターゲット機種で、これらの関数を一切必要としないというのも可能である。その場合は、libgcc1.a として空のライブラリを与えれば良い。

多くのターゲットでは、サポートが必要なライブラリは、乗算と除算用のもののみである。乗算と除算を行う関数を含むライブラリとリンクするのなら、MULSI3_LIBCALL 等のマクロを定義することで、GNU CC に直接呼出しを行わせることが可能である。これらのマクロは、ターゲット記述マクロファイルで定義する必要がある。幾つかのターゲットについては、既に定義済みである。これで libgcc1.a を不要とするのには充分である可能性がある。もしそうなら、空のライブラリを指定することが可能である。

ターゲットによっては、浮動小数点命令がないものがある。これらの機種では libgcc1.a 内の別の関数が必要になる。それは、浮動小数点算術演算を行うものだえる。GNU CC の最近のバージョンには、浮動小数点演算をエミュレートするファイルが含まれている。ある程度作業を行えば、libgcc1.a として使える浮動小数点エミュレータを作り上げることが出来るはずである。おそらく、将来のバージョンでは、この作業を自動的に簡単に行うコードが入るだろう。入るかどうかは、実装したいという人が誰かいるかどうかに依る。

組み込みターゲットの中には、 libgcc1.a の必要な全てのルーチンを C またはアセンブラで書いたものが付いてくるものがある。これらのターゲットでは、libgcc1.a を自動的に構築するので、読者は何も特別なことをする必要がない。その他の組み込みターゲットは、なんら libgcc1.a を必要としない。なぜなら、必要な演算は全てハードウェアによりサポートされているからである。

読者のターゲットシステムに何か別の C コンパイラがあるなら、GNU CC をその機種でのネイティブ・コンパイラとしてコンフィギュレーションし、make libgcc1.a で libgcc1.a を構築することが可能であり、その結果得られるファイルをクロスコンパイラと共に使うことができる。このためには、ターゲット機種で以下の手順を実行する。

cd target-build-dir
./configure --host=sparc --target=sun3
make libgcc1.a

次に以下をホスト機種で実行する。

ftp target-machine
binary
cd target-build-dir
get libgcc1.a
quit

libgcc1.a で必要とされる関数を提供するもう一つの方法として、それらの関数に対して perform_... マクロを適切に定義する方法がある。これらのマクロ定義で、これから実装しようとしているまさにその C の算術演算子を使っていなければ、読者が構築中のクロスコンパイラでコンパイルできるはずである。(これらの定義が読者のターゲットファイルに既に存在するなら、必要なものは揃ったことになる。)

perform_... マクロを使って libgcc1.a を構築するには、GNU CC を構築するときに LIBGCC1=libgcc1.a OLDCC=./xgcc とする。そうしない場合は、make を実行する前に、クロスコンパイラを構築するディレクトリに、代わりのライブラリをlibgcc1.a という名前で置く必要がある。

Node:Cross Headers, Next:Build Cross, Previous:Cross Runtime, Up:Cross-Compiler

クロスコンパイラとヘッダファイル

単体のプログラムや組み込みシステム向けのプログラムをクロスコンパイルする場合は、GNU CC の一部(それに読者のプログラムの一部)であるものを除いて、ヘッダファイルは何も必要ないだろう。しかし、読者のプログラムを libc.a のような標準 C ライブラリとリンクしたいのであれば、そのライブラリに付属するはずのヘッダファイルを使ってコンパイルする必要があるだろう。

GNU C コンパイラにはこういうヘッダファイルは付いていない。何故なら、(1) システムに依存するものであり、(2) C ライブラリに所属するものであって、コンパイラに所属するものではないからである。

GNU C ライブラリが読者の対象機種をサポートしているなら、そこからヘッダファイルを入手できる(読者のプログラムをリンクするときに実際に GNU ライブラリを使うことを想定した場合)。

読者の対象機種に C コンパイラが付いているなら、おそらく適切なヘッダファイルも付いてくるはずである。このヘッダファイルをホストマシンからアクセスできるようにすれば、クロスコンパイラからも使える。

そうなっていない場合は、クロスコンパイルを行なうには読者自身がヘッダファイルを用意しなければならない。

適当なヘッダファイルが見つかったなら、それをクロスコンパイラを構築する前に、ディレクトリ /usr/local/target/include に置く。そうしておくと、インストールの際に fixincludes が正しく実行され、ヘッダファイルの修正版を GNU CC が使用する場所にインストールされる。

ヘッダファイルはクロスコンパイラを構築する前に用意しなければならない。構築の段階で、実際にクロスコンパイラを実行して libgcc.a の一部を生成するからである。(これらは、GNU CC でコンパイル可能な一部である。) この一部は適切なヘッダファイルを必要とする。

以下にヘッダファイルをターゲット機種からコピーする方法の例を示す。ターゲット機種上でまず以下を実行する。

(cd /usr/include; tar cf - .) > tarfile

次にホストマシンで以下を実行する。

ftp target-machine
lcd /usr/local/target/include
get tarfile
quit
tar xf tarfile

Node:Build Cross, Previous:Cross Headers, Up:Cross-Compiler

クロスコンパイラ構築の実際

ようやく、一個の機種向けのコンパイラをコンパイルするのに、ステージ 1 を構築する段階に進むことができる。読者が何らかの libgcc1.a を用意していなければ、そのファイルを必要とする時点でコンパイルが止まり、適切なエラーメッセージを出すだろう。libgcc1.a を用意していれば、コンパイラを構築すると、libgcc1-test というテストプログラムをコンパイル、リンクするはずである。このリンクの際に、エラーが出たなら、libgcc1.a の中に必要なルーチンが全部は揃っていないということである。

読者はヘッダファイル float.h を提供しなければならない。そのための一つの方法は、ターゲット機種で enquire をコンパイルし、実行することである。enquire がやることは、ターゲット機種上で実行して、実験により、ターゲット機種の浮動小数点表現の性質を明らかにすることである。enquire は発見した結果をヘッダファイルfloat.h に記録する。ターゲット機種で enquire を実行してこのファイルを生成できない場合は、何か別の手段で適切な float.h を用意する必要が出てくるだろう。さもないと、プログラムの中でfloat.h を使わないようにしなければならなくなる。

クロスコンパイラの場合は、ステージ2 を作らないように。クロスコンパイラを使って、GNU CC をクロスコンパイラとして構築することはできない。何故なら、そうすると、ホストではなくて、ターゲット機種上で動作するプログラムができるからである。例えば、386から68030へのクロスコンパイラをそれ自身でコンパイルした場合、その結果は 386 にとっても(68030のコードにコンパイルされるので)、68030 にとっても(386 をホストとしてコンフィギュレーションされているので) 正しくない。GNU CC 自身を 68030 のコードにコンパイルしたいのであれば、68030 上でコンパイルしようとも、386 上でクロスコンパイラとしてコンパイルしようとも、コンフィギュレーションジに 68030 をホストとして指定しなければならない。

クロスコンパイラをインストールするには、普通と同じに、make install とする。

Node:Sun Install, Next:VMS Install, Previous:Cross-Compiler, Up:Installation

GNU CC を Sun にインストール

Solaris では、GNU CC を作るときに、/usr/ucb にある、リンカやその他のツールを使わないこと。代わりに、/usr/ccs/bin にあるものを使うようにする。

アセンブラが、ブートストラップの際に Error: misaligned data と報告してきたら、おそらく GNU アセンブラの古いバージョンを使っているせいである。GNU binutils の最新版に更新するか、Solaris のアセンブラを使うこと。

libgcc.a をコンパイルするときに、環境変数 FLOAT_OPTION が設定されていないことを確認すること。libgcc.a をコンパイルするときにこの環境変数が f68881 に設定されていると、コンパイルした結果のコードが特別な開始ファイルとリンクすることを要求し、特別な苦労をしないと正しくリンクできないだろう。

Sun のライブラリの特定のバージョンの alloca にはバグがある。このバグを避けるには、GNU CC でコンパイルした GNU CC のバイナリをインストールする。こうしてインストールしたバイナリは、allocaを組み込み関数として使い、ライブラリ中のものを使うことはない。

Sun のコンパイラの幾つかのバージョンは、GNU CC をコンパイルしているときに落ちてしまう。問題は、cpp がセグメンテーション違反を起こすことにある。この問題は、環境変数に大量のデータが設定されていることに起因するように思える。この問題を回避するには、以下のコマンド行を使い、Sun CC でGNU CC をコンパイルする。

make CC="TERMCAP=x OBJS=x LIBFUNCS=x STAGESTUFF=x cc"

SunOS 4.1.3 と 4.1.3_U1 には、GNU CC をコンパイルしている時に不定期にコアダンプするというバグがある。共通する症状は再現性のない内部コンパイラエラーである。この問題を直すには、Sun の推奨パッチ 100726(SunOS 4.1.3 用) か 101508(SunOS 4.1.3_U1) をインストールするか、あるいはもっと新しい SunOS のリリースに更新することである。

Node:VMS Install, Next:Collect2, Previous:Sun Install, Up:Installation

GNU CC を VMS にインストール

VMS 版の GNU CC は、ソースコードとコンパイル済みバイナリの双方を含むバックアップ・セーブセットで配布されている。

gcc コマンドを、VMS C コンパイラと同じ方法で、簡単に使えるようにインストールするには、GNU CC 用の VMS CLD ファイルを以下のようにインストールしなければならない。

VMS の論理名 GNU_CC と GNU_CC_INCLUDE を定義し、GNU CC の実行形式(gcc-cpp.exe、gcc-cc1.exe、等)とC のインクルードファイルが置かれているディレクトリをそれぞれ指すようにする。これには、
```
$ assign /system /translation=concealed -
  disk:[gcc.] gnu_cc
$ assign /system /translation=concealed -
  disk:[gcc.include.] gnu_cc_include
```
というコマンドに適切なディスク名とディレクトリ名を指定する。これらのコマンドを読者のシステム起動ファイルに入れておけば、リブート時に常に実行されるようにすることができる。読者が望むなら、[GCC] ディレクトリに置いたGCC_INSTALL.COM スクリプトを経由して行なうことも出来る。

GCC コマンドを以下のコマンド行でインストールする。

$ set command /table=sys$common:[syslib]dcltables -
  /output=sys$common:[syslib]dcltables gnu_cc:[000000]gcc
$ install replace sys$common:[syslib]dcltables

以下のようにして、ヘルプファイルをインストールする。
```
$ library/help sys$library:helplib.hlb gcc.hlp
```
これで、GNU CC を gcc /verbose file.c のようなコマンド行で起動できるようになったはずである。これは Unix の場合のgcc -v -c file.c というコマンドに同じである。

GNU C++ を使う場合には、まず GNU CC をインストールしておいてから、以下の段階を踏まなければならない。

This can be done with the command: VMS 論理名 GNU_GXX_INCLUDE を定義し、プリプロセッサが C++ のヘッダファイルを検索するディレクトリを指すようにする。このためには以下のコマンドを実行する。
```
$ assign /system /translation=concealed -
  disk:[gcc.gxx_include.] gnu_gxx_include
```
ここで適切なディスク名とディレクトリ名を指定する。C++ 実行時ライブラリを使うなら、ここがそのライブラリのインストール手続によりヘッダファイルがインストールされる場所である。
gcc-cc1plus.exe というファイルを入手し、gcc-cc1.exe が置かれているディレクトリにこれを置く。
これで GNU C++ コンパイラは gcc /plus /verbose file.cc のようなコマンドで起動できるようになる。これは Unix の場合のg++ -v -c file.cc と同じである。

我々は、バージョンが対応しているバイナリとソースを VMS 用の配布テープに入れるようにしている。だが、時々バイナリがソースよりも古いバージョンになってしまうことがある。常に更新するようにする時間がないためである。(/version オプションを使ってバイナリのバージョンを知ったうえで、ソースファイルの中の version.c と比較すると、バイナリとソースの同期が取れているかどうかが判る。) バイナリの方が古い場合は、そのバイナリを使って、ソースコードから再コンパイルした方が良い。再コンパイルしなければならないようなら、以下の手順に従うこと。

コマンド・プロシージャ vmsconfig.com を実行して、tm.h、config.h、aux-output.c、md. というファイルを設定し、tconfig.h と hconfig.h を作る。また、このプロシージャは、make-cc1.com が使用するたくさんのリンカ・オプション・ファイルと、make-l2.com が使用する一個のデータファイルを作成する。
```
$ @vmsconfig.com
```
上で定義された論理名とコマンドテーブルを設定する。さらに、VMS 論理名 GNU_BISON を定義し、Bison の実行形式が置かれているディレクトリを指すようにする。このためには以下のコマンドを実行する。
```
$ assign /system /translation=concealed -
  disk:[bison.] gnu_bison
```
読者が選ぶなら、BISON ディレクトリにある INSTALL_BISON.COM スクリプトを使っても良い。

BISON コマンドを以下のコマンド行でインストールする。

$ set command /table=sys$common:[syslib]dcltables -
  /output=sys$common:[syslib]dcltables -
  gnu_bison:[000000]bison
$ install replace sys$common:[syslib]dcltables

全てを再コンパイルするために @make-gcc と打つ(あるいは、ファイル make-gcc.com をバッチ・キューに投入する)。GNU CC コンパイラだけでなく GNU C++ コンパイラも構築したければ、最初に make-gcc.com を編集して、コメントに書かれている操作に従う必要がある。
GCC を使うためには、GCC でコンパイルされたコードから呼び出され、ある特定の作業を行う関数ライブラリが必要である。これをコンパイルするには、コマンド・プロシージャ make-l2.com を使う必要がある。これを使うとライブラリ libgcc2.olb を生成する。libgcc2.olb は、libgcc2.c の出所と同じディストリビューションから構築された GCC を使って構築する必要がある。make-gcc.com は、このために必要なことを全て自動的に行う。
このライブラリをインストールするには、以下のコマンドを使う。
```
$ library gnu_cc:[000000]gcclib/delete=(new,eprintf)
$ library gnu_cc:[000000]gcclib/delete=L_*
$ library libgcc2/extract=*/output=libgcc2.obj
$ library gnu_cc:[000000]gcclib libgcc2.obj
```
最初のコマンドは、別のモジュール名で置かれる libgcc2 から来るモジュールで置き換えられる古いモジュールを単に消去する。モジュール new と eprintf は、読者の gcclib.olb には実際には存在しないかもしれない。VMS のライブラリアンがこれらのモジュールが存在しないと文句を言った場合は、単にそのメッセージを無視して、次のコマンドを続けること。第二のコマンドは、libgcc2.c ライブラリの以前のバージョンから来るモジュールを消去する。
読者のシステムの GNU CC を更新したときはいつでも、このライブラリも上記のプロシージャで更新しなければならない。
GCC を構築するのに、ソースファイルのあるディレクトリには何もファイルを作りたくないこともあるだろう。例えば、ソースファイルが読みだし専用ディスク上にある場合が該当するだろう。そう言う場合は、以下の DCL コマンドを実行する(読者のところの実際のパス名に置き換えること)。
```
$ assign dua0:[gcc.build_dir.]/translation=concealed, -
         dua1:[gcc.source_dir.]/translation=concealed  gcc_build
$ set default gcc_build:[000000]
```
ここで、ディレクトリ dua1:[gcc.source_dir] にはソースコードが置かれており、ディレクトリ dua0:[gcc.build_dir] は生成されるオブジェクトファイルと実行形式を全て置くディレクトリである。一度こうしておけば、上に記述したように GCC の構築を進めることができる。(gcc_build はルート起点の論理名であり、そのため検索リストの各要素に入っているデバイス名は、何か別のルート起点論理名ではなく実際の物理デバイス名でなくてはならないことに注意。)
GNU CC を以前のバージョン GNU CC で作ろうとしているなら、GNU アセンブラの最新版を使っているかどうかも確かめなければならない。特に、GNU CC バージョン 2 はグローバル定数変数の取扱いが、GNU CC バージョン 1 と微妙に異なり、GAS バージョン 1.38.1 には、GCC バージョン 2 と共に動作させるのに必要なパッチが存在しない。GAS 1.38.1 を使うと、extern const 宣言された変数には、読みだし専用ビットが設定されず、リンカが、そういう変数に対し、psect 属性が一致しないという警告メッセージを出す。この警告メッセージは単に邪魔なだけであり、無視して良い。
GNU CC の 1.33 以前のバージョンでコンパイルする場合は、全てのコンパイルでオプションとして /DEFINE=("inline=") を指定すること。このためには、make-cc1.com に現れる全ての gcc コマンドを編集する必要がある。(古いバージョンには inline のサポートに問題があったのである。)一度 1.33 以降の GNU CC が動くようになれば、このファイルを元に戻すことが出来る。
GNU CC を VAX C コンパイラで構築したい場合は、make-cccp.com とmake-cc1.com にちょっと変更を加えて、CC、CFLAGS、LIBS の別の定義を選ぶ必要がある。これらのファイル中のコメントを参照のこと。ただし、GNU アセンブラ(GNU as, 別名 GAS)の正しく動作するバージョンが、GNU CC のバックエンドとして、バイナリのオブジェクトモジュールを生成するのに必要である。GAS は GNU CC のソースには含まれていない。GAS は、libgcc2 をコンパイルして gcclib を作るのにも必要である(上記参照)。make-l2.com では、GAS が gnu_cc:[000000]gnu-as.exe として使える事を想定している。
GNU CC を VMS で使うには、VMS 用ドライバプログラム gcc.exe、gcc.com、gcc.cld が必要である。これらは、GNU CC のソースではなくて VMS 用バイナリ(gcc-vms) に入って配布されている。GAS、Bison も gcc-vms に含まれている。
VAX C で GNU CC を構築するのに一度成功すれば、できたコンパイラを使って自分自身を再構築した方が良い。その前に、make-cccp.com とmake-cc1.com の中の CC、CFLAGS、LIBS の定義を元に戻すのを忘れないこと。二代目のコンパイラは、他のコンパイラで構築しているときには抑止しなくてはならなかった多数の最適化の利点を享受することができる。

以前のバージョンの GNU CC では、生成されたコードを共有可能なVAXCRTL ライブラリとリンクするとおかしな結果になることがときどきあった。現在のバージョンでは正しく動作するはずである。

ただし、現在のバージョンでも、GNU CC 自体は共有可能な VAXCRTL とリンクすべきではない。VAXCRTL にあるバージョンの qsort にはバグがあり(VMS バージョン V4.6 から V5.5 にかけて存在するのが知られている)、GNU CC が正しく動作しない。

実行形式は、make-cc1.com と make-cccp.com により、VAXCRTL のバージョンのオブジェクトライブラリを使って生成されることで、gcclib.olb にある qsort ルーチンを使うようになる。GCC の実行形式を共有可能な VAXCRTL とリンクしたければ、ファイル tm.h(vmsconfig.com により作られる)を編集して、マクロ QSORT_WORKAROUND を定義する必要がある。

QSORT_WORKAROUND は GNU CC を VAX C でコンパイルする場合は常に定義されて、gcclib.olb がまだ利用可能でない場合の問題を回避するようになっている。

Node:Collect2, Next:Header Dirs, Previous:VMS Install, Up:Installation

`collect2`

GNU CC は、ほぼ全てのシステムで collect2 というユーティリティを使って、プログラムの開始時に様々な初期化関数を呼び出すような設定を行なう。

collect2 の仕組みは、まず一度プログラムのリンクを行ない、リンカの出力ファイルを調べてコンストラクタ関数であることを示す名前を持つシンボルを探す。そのようなシンボルが一つでもあれば、シンボルのテーブルを含む一時 .c ファイルを作り、コンパイルし、そのオブジェクトファイルを追加して二回目のリンクを行なう。

コンストラクタ群の実際の呼び出しは、__main というサブルーチンにより実行される。__main は、main 関数本体の先頭で自動的に呼び出される(main 関数は GNU CC でコンパイルしておく必要がある)。__main の呼び出しは、C プログラムをコンパイルするときにも必要である。というのは、C と C++ のオブジェクトを両方リンクするのに必要になるからである。(-nostdlib オプションを使うと、__main の参照が解決されない。__main が標準 GCC ライブラリで定義されているからである。その場合は、コンパイルのコマンド行の最後に -lgcc を付け加えれば、解決できる。)

collect2 は、コンパイラの各パスがインストールされるディレクトリに、ld という名前でインストールされる。collect2 が本当の ld を探す必要があるときは、次のようなファイルを探す。

GNU CC の検索ディレクトリに列挙されているディレクトリにある real-ld。
環境変数 PATH に列挙されているディレクトリにある real-ld。
指定されていれば、コンフィグレーションマクロ REAL_LD_FILE_NAME で指定されたファイル。
GNU CC の検索ディレクトリにある ld。ただし、collect2 は自分自身を再帰的に実行することはない。
PATH にある ld。

「GNU CC の検索ディレクトリ」とは、GNU CC がコンパイラの各パスのコマンドを検索する全てのディレクトリを意味する。-B で指定したディレクトリも含む。

クロスコンパイラの場合の検索は若干異なる。

GNU CC の検索ディレクトリにある real-ld。
PATH にある target-real-ld。
指定されていれば、コンフィグレーションマクロ REAL_LD_FILE_NAME で指定されたファイル。
GNU CC の検索ディレクトリにある ld。
target-ld in PATH. PATH にある、target-ld。

collect2 は、collect2 自身が起動されたときのファイル名を使って ld を実行することを明示的に回避している。実際に、そういうファイル名のリストを記憶している。例えば、collect2 の一つのコピーが、検索パスの二番目の場所に ld としてインストールされた collect2 の別のコピー(またはバージョン)を見つけたと言うような場合である。

collect2 は、nm と strip をld に対する上記のと同じアルゴリズムを使って検索する。

Node:Header Dirs, Previous:Collect2, Up:Installation

標準ヘッダファイルのディレクトリ

GCC_INCLUDE_DIR は、ネイティブとクロスで同じものを意味する。GNU CC が私的なインクルードファイルを格納する場所であり、また GNU CC が修正版インクルードファイルを格納する場所でもある。クロスコンパイルされた GNU CC は、$(tooldir)/include にあるヘッダファイルに対して fixincludes を実行する。(クロスコンパイル用ヘッダファイルを修正する必要があるなら、それを GNU CC を構築する前にインストールしておかなくてはならない。クロスコンパイル用ヘッダファイルが既に ANSI C と GNU CC に適切なものになっているのであれば、何も特別な処理は必要ない。)

GPLUSPLUS_INCLUDE_DIR は、ネイティブとクロスで同じものを意味する。g++ が最初にヘッダファイルを探す場所である。C++ ライブラリは、このディレクトリにはターゲット独立のヘッダファイルしかインストールしない。

LOCAL_INCLUDE_DIR は、ネイティブコンパイラだけが使う。通常は、/usr/local/include になる。GNU CC はこのディレクトリを検索するので、ユーザはヘッダファイルを/usr/local/include にインストールして置くことができる。

CROSS_INCLUDE_DIR は、クロスコンパイラだけが使う。GNU CC はここには何もインストールしない。

TOOL_INCLUDE_DIR は、ネイティブとクロスコンパイラの両方で使われる。GNU CC が使うであろう他のパッケージのヘッダファイルをインストールする場所である。クロスコンパイラの場合は、これは /usr/include に等価である。クロスコンパイラを構築するときに、fixincludes は、このディレクトリに置かれているヘッダファイルを全て処理する。

Node:C Extensions, Next:C++ Extensions, Previous:Installation, Up:Top

C 言語に対する拡張

GNU C は、ANSI C 言語標準規格には無い機能を多数提供している。(-pedantic オプションを使うと、これらの機能をどれか使っている場合に、警告メッセージを出してくれる。) 条件付きコンパイルを行う場合に、これらの拡張機能が使えるかどうかテストするには、予約済マクロ __GNUC__ が定義されているかどうかを調べれば良い。このマクロは、GNU CC では常に定義される。

これらの拡張機能は、C と Objective C で利用できる。その大部分は、C++ でも利用可能である。C++ にのみ適用可能な拡張については、See Extensions to the C++ Language.

Statement Exprs: 式中に文(文式)と宣言を置くには
Local Labels: 局所ラベル
Labels as Values: ラベルへのポインタと計算形 goto
Nested Functions: Algol や Pascal にある、関数のレキシカルスコープ
Constructing Calls: 別の関数への呼び出しのディスパッチ
Naming Types: 式の型に名前を与える
Typeof: typeof: 式の型を取得する
Lvalues: 左辺値で ?:、,、キャストを使うには
Conditionals: ?: 式の中間オペランドを省くには
Long Long: 倍語整数---long long int
Complex: 複素数型
Hex Floats: 16進浮動小数点定数
Zero Length: 大きさゼロの配列
Variable Length: 実行時に大きさの決まる配列
Macro Varargs: 可変数引数を持つマクロ
Subscripting: 左辺値でない配列の添え字を取ることが可能
Pointer Arith: voidポインタと関数へのポインタに対する演算
Initializers: 非定数による初期化
Constructors: 構造体、共用体、配列の値を与えるコンストラクタ式
Labeled Elements: 初期化子の要素にラベルを付ける
Cast to Union: 共用体の任意のメンバから共用体型へのキャスト
Case Ranges: `case 1 ... 9' 等.
Function Attributes: 副作用のない関数や戻らない関数の宣言
Function Prototypes: プロトタイプ宣言と古い形式の定義
C++ Comments: C++ 形式のコメントが可能
Dollar Signs: ドル記号を識別子の中で使うことが可能
Character Escapes: \e は文字 <ESC> を表す
Variable Attributes: 変数の属性の指定
Type Attributes: 型の属性の指定
Alignment: 型あるいは変数のアラインメントを問い合わせる
Inline: インライン展開関数の定義(マクロと同程度の速度)
Extended Asm: オペランドとして C の式を使えるアセンブラ命令 (これにより「組み込み」関数が定義可能)
Asm Labels: C のシンボルのアセンブラでの名前を指定するには
Explicit Reg Vars: 指定したレジスタに置かれる変数の定義
Alternate Keywords: ヘッダファイル向けの __const__, __asm__, 等
Incomplete Enums: 詳細な定義が後で現れる enum foo;
Function Names: 現在の関数名を持つ表示可能な文字列
Return Address: 関数の戻りアドレスやフレームアドレスを得るには
Other Builtins: その他の組み込み関数
Deprecated Features: g++ から消えた機能について

Node:Statement Exprs, Next:Local Labels, Previous:C Extensions, Up:C Extensions

式中の文と宣言

複文を小括弧で囲むと、GNU C では式として使用できる。これにより、式の中でループや switch 文や局所変数を使用できる。

さて、複文とは中括弧で囲まれた文の列であった。この拡張構文では、中括弧のまわりを小括弧が囲むことになる。例えば、

({ int y = foo (); int z;
   if (y > 0) z = y;
   else z = - y;
   z; })

は、foo () の絶対値を取る正しい式である。(必要以上に複雑だが。)

複文の最後には、セミコロン付きの式を置く必要がある。この最後の式の値が複文全体の値の役割を果たす。(中括弧の最後に他の種類の文を使うと、複文全体の型は void になり、有効な値を持たないことになる。

この機能は、マクロを安全に定義する場合に特に有効である。安全にというのは、マクロの引数の評価を一度だけ行うように出来るという意味である。例えば、最大値を取る関数は、標準規格 C のマクロとして以下のように定義するのが普通である。

#define max(a,b) ((a) > (b) ? (a) : (b))

しかし、この定義は a か b のどちらかを二回評価してしまい、引数が副作用を持つ場合は予期しない結果を生じる。GNU C では、引数の型を知っていれば、マクロを安全に定義できる。int 型の場合は以下のようになる。

#define maxint(a,b) \
  ({int _a = (a), _b = (b); _a > _b ? _a : _b; })

複文式は、定数式が要求される場面では使えない。例えば、列挙定数の値や、ビットフィールドの幅、静的変数の初期値等には使えない。

引数の型が判らない場合でも、typeof (see Typeof) または型名付を使うことによって、上記の手法が使用可能である。

Node:Local Labels, Next:Labels as Values, Previous:Statement Exprs, Up:C Extensions

局所的に宣言されたラベル

局所ラベルは、複文式のスコープで宣言することができる。局所ラベルは単なる識別子である。普通の goto 文を使ってそこにジャンプすることが出来るが、ジャンプ元は局所ラベルの属する複文式の中に限られる。

局所ラベルの宣言は以下のように行う。

__label__ label;

または、

__label__ label1, label2, ...;

局所ラベルの宣言は、複文式の先頭、つまり、({ の直後で、他の通常の宣言の前になければならない。

局所ラベルの宣言はラベル名を定義するが、ラベル自体を定義するわけではない。局所ラベル自体の定義は、通常のラベルと同じく label: を使って、複文式中で行う必要がある。

局所ラベルの機能は、複文式が使われるのがマクロ定義中であることが多いので、重宝する。マクロが入れ子になったループを含んでいる場合、goto を使ってループから脱出することが可能になる。しかし、通常の、関数内のスコープのラベルはこの目的には使えない。一個の関数の中でマクロは何度も使われる可能性があり、その場合、何度もマクロが展開され、同じラベルが一つの関数内で複数回定義されることになってしまうからである。局所ラベルを使えば、この問題は回避できる。以下に例を上げる。

#define SEARCH(array, target)                     \
({                                               \
  __label__ found;                                \
  typeof (target) _SEARCH_target = (target);      \
  typeof (*(array)) *_SEARCH_array = (array);     \
  int i, j;                                       \
  int value;                                      \
  for (i = 0; i < max; i++)                       \
    for (j = 0; j < max; j++)                     \
      if (_SEARCH_array[i][j] == _SEARCH_target)  \
        { value = i; goto found; }              \
  value = -1;                                     \
 found:                                           \
  value;                                          \
})

Node:Labels as Values, Next:Nested Functions, Previous:Local Labels, Up:C Extensions

ラベルの値

関数内で定義されたラベルのアドレスは、同じ関数内であれば、単項演算子 && を使って取得することが出来る。ラベルのアドレス値の型は void * になる。ラベルのアドレス値は、定数であり、この型の定数が有効なところならどこでも使うことが出来る。例を挙げよう。

void *ptr;
...
ptr = &&foo;

ラベルのアドレス値を使うためには、そのラベルをジャンプすることが出来なければならない。このためには、計算形 goto 文¹、 goto *exp; を使う。例えば以下のようにする。

goto *ptr;

void * 型であれば、任意の式を使うことが出来る。

これらの定数の使い道の一つは、ジャンプテーブルの静的配列を初期化することである。

static void *array[] = { &&foo, &&bar, &&hack };

こうすれば、以下のように、添え字でラベルを選ぶことが出来る。

goto *array[i];

添字の範囲についての検査は行なわないことに注意すること。C 言語では、配列の参照においては添字の範囲の検査は行ない。

この様なラベル値の配列は、switch 文と同様の機能を提供する。もちろん、switch 文を使ったほうがきれいなので、対象とする問題が switch 文にうまく当てはまらない場合以外は、switch 文を使うべきである。

もうひとつの、ラベル値の使い道は、スレッドを使ったコードのインタプリタにある。インタプリタ関数内のラベルは、超高速ディスパッチ用の素レッドコードに格納することができる。

この機構を使って、異なる関数中のコードにジャンプすることができる。それをやると、全く予測できない事が発生するだろう。これを避けるのに一番良い方法は、ラベルのアドレスを自動変数にだけ格納し、引数としては渡さないことである。

Node:Nested Functions, Next:Constructing Calls, Previous:Labels as Values, Up:C Extensions

入れ子関数

ネストした関数とは、なにか別の関数のなかで定義された関数である。(GNU C++ ではネストした関数はサポートしていない。) ネストした関数の名前は、定義されたブロック内で有効である。以下の例では、square という名前のネストした関数を定義し、二回呼び出している。

foo (double a, double b)
{
  double square (double z) { return z * z; }

  return square (a) + square (b);
}

ネストした関数からは、それを含む関数の変数のうち、ネストした関数が定義されている点で見えるものは全部参照可能である。これは、レキシカル・スコーピングと呼ばれている。例えば、以下の例では、ネストした関数が offset という名前の変数を親関数から継承している。

bar (int *array, int offset, int size)
{
  int access (int *array, int index)
    { return array[index + offset]; }
  int i;
  ...
  for (i = 0; i < size; i++)
    ... access (array, i) ...
}

ネストした関数は、関数内の、変数の定義が出来る場所で定義出来る。つまり、任意のブロック中の最初の文の前になる。

ネストした関数をその名前のスコープの外側から呼び出すのは、そのアドレスを格納したり、別の関数にアドレスを渡したりすることで可能である。

hack (int *array, int size)
{
  void store (int index, int value)
    { array[index] = value; }

  intermediate (store, size);
}

ここで、関数 intermediate は、引数として store のアドレスを受け取る。intermediate が store を呼び出すなら、その時に store に与えられる引数が、array に格納するのに使われる。だが、この方法は、そのネストした関数を包含する関数(この例では、hack) が終了しない間だけ、機能する。

ネストした関数を、そのアドレスを使って、その包含関数が終了した後で呼び出そうとすると、大変なことになる。包含しているスコープレベルを抜けた後に呼び出しを行なうとした場合、もはやスコープにない変数を何か参照していると、運が良ければうまくいくかもしれないが、危険を犯すことになる。だが、ネストした関数がスコープから出てしまったものを何も参照していない場合は、安全である。

GNU CC はネスト関数のアドレスを取るのに、トランポリンと呼ばれる方法を使って実装している。これについて説明している論文が http://master.debian.org/~karlheg/Usenix88-lexic.pdf から利用できる。

ネスト関数は、包含関数内でラベルが明示的に宣言されていれば、包含関数から継承したそのラベルにジャンプすることができる(see Local Labels)。そういうジャンプは直ちに包含関数に戻り、goto を実行したネスト関数と中間の関数を終了する。以下に例を示す。

bar (int *array, int offset, int size)
{
  __label__ failure;
  int access (int *array, int index)
    {
      if (index > size)
        goto failure;
      return array[index + offset];
    }
  int i;
  ...
  for (i = 0; i < size; i++)
    ... access (array, i) ...
  ...
  return 0;

 /* Control comes here from access
    if it detects an error.  */
 failure:
  return -1;
}

ネスト関数は常に内部リンケージとなる。extern 付きで宣言するのは誤りである。ネスト関数を、その定義の前に宣言する必要があるときは、auto を使うこと(これは、この場合以外の関数宣言では意味がない。)

bar (int *array, int offset, int size)
{
  __label__ failure;
  auto int access (int *, int);
  ...
  int access (int *array, int index)
    {
      if (index > size)
        goto failure;
      return array[index + offset];
    }
  ...
}

Node:Constructing Calls, Next:Naming Types, Previous:Nested Functions, Up:C Extensions

関数呼び出しの構築

以下に示す組み込み関数を使うと、関数が受け取った引数を記録することができたり、また、引数の数や型を知らなくても、同じ引数を別の関数に渡すことができる。

また、関数呼び出しの戻り値を記録し、後でその値を返すこともできる。これは、その関数が返そうとしているデータ型を知らなくても可能である。(ただし、呼び出し側の関数がそのデータ型が返ってくることを想定している場合に限られるが。)

__builtin_apply_args ()

この組み込み関数は、現在の関数に渡されたのと同じ引数を付けての呼び出しをどのように行なうかを記述するデータへの void * 型のポインタを返す。

この関数は引数ポインタレジスタ、構造体値アドレス、関数へ引数を渡すのに使われる可能性のある全てのレジスタを、スタック上に割り当てられたメモリブロックにセーブする。次に、そのブロックのアドレスを返す。

__builtin_apply (function, arguments, size)

この組み込み関数は、function(void (*)() 型)を、arguments (void * 型) と size (int 型) で記述される仮引数のコピーを引数として呼び出す。

arguments の値は、__builtin_apply_args が返す値とすべきである。引数 size は、スタックの引数データの大きさをバイト単位で指定する。

この関数は、function が返す値をどのように返すかを記述するデータへの、void * 型のポインタを返す。このデータは、スタック上に割り当てられたメモリブロック中にセーブされる。

size の適切な値を計算するのはいつでも簡単というわけではない。この値は __buitin_apply によって、スタック上にプッシュされ、入力引数領域からコピーされるデータ量を計算するのに使われる。

__builtin_return (result)

この組み込み関数は、それを含む関数から result で記述される値を返す。result には、__builtin_apply が返す値を指定すべきである。

Node:Naming Types, Next:Typeof, Previous:Constructing Calls, Up:C Extensions

式の型に名前を与える

初期化式の形式の typedef 宣言を使うことで、ある式の型に名前を付けることができる。以下に、exp の型に name という型名を定義する例を示す。

typedef name = exp;

これは、式文と共に使うと有効である。以下に、式文と共に使っている、どの算術型にでも適用できる、安全な最大値マクロの定義例を示す。

#define max(a,b) \
  ({typedef _ta = (a), _tb = (b);  \
    _ta _a = (a); _tb _b = (b);     \
    _a > _b ? _a : _b; })

ローカル変数名をアンダースコアで始まる名前にするのは、a と b が置き換えられた式内で発生する変数名の衝突を避けるためである。将来的には、新しい宣言構文の形式を考えて、変数を宣言するのに、そのスコープが、その変数に対する初期化子以降にのみ開始するようにしたいと考えている。これは、衝突を避けるのにより信頼性の高い方法となるだろう。

Node:Typeof, Next:Lvalues, Previous:Naming Types, Up:C Extensions

`typeof` による型の参照

式の型を参照するには、typeof を使う方法もある。このキーワードの構文は、sizeof に良く似ているが、意味的にはtypedef で定義される型名に似ている。

typeof の引数には、二通りの書き方がある。式を与える方法と型を与える方法である。以下に式を指定する例を示す。

typeof (x[0](1))

ここでは、x が関数の配列であることを仮定している。この構文で記述される型は、関数の戻り値の型になる。

次に、引数に型名を指定した例を示す。

typeof (int *)

これで記述される型は、int へのポインタという型になる。

ANSI C プログラムからインクルードされたときに正しく動作しなければならないヘッダファイルを書く場合は、typeof の代わりに __typeof__ を使うこと。See Alternate Keywords.

typeof構文は、typedef 名が書けるところならどこにでも置ける。例えば、宣言や、キャストや、sizeof や typeof の中で使うことができる。

次の例は、y の型を、x が指しているものの型として宣言している。
```
typeof (*x) y;
```
次のは、y をその様な値の配列として宣言している。
```
typeof (*x) y[4];
```
次のは、y を文字へのポインタ配列として宣言している。
```
typeof (typeof (char *)[4]) y;
```
これは、以下のようなおなじみの C の宣言と同じである。
```
char *y[4];
```
typeof を使った宣言の意味を知るために、そして何故便利な書き方なのかを知るために、以下のマクロを使って書き直してみる。
```
#define pointer(T)  typeof(T *)
#define array(T, N) typeof(T [N])
```
こうしておくと、以下のように宣言を書き換えることができる。
```
array (pointer (char), 4) y;
```
つまり、arrray (pointer (char), 4) は、char への4 個のポインタの配列の型である。

Node:Lvalues, Next:Conditionals, Previous:Typeof, Up:C Extensions

拡張左辺値

複文式、3項演算式、それにキャストは、そのオペランドが左辺値であれば、左辺値として許される。つまり、これらのアドレスを取ったり、値を格納出来る。

C++ の標準は、複文式と3項演算子式を左辺値として使うこと、それから参照型へのキャストを許しているので、C++ のコードではこの拡張を使う意味はあまりない。

例えば、複文式は題入可能である。列の最後の式が左辺値となる。以下の二つの式は等価である。

(a, b) += 5
a, (b += 5)

同様に、複文式のアドレスを取ることができる。以下の二つの式は等価である。

&(a, b)
a, &b

条件式は、その型が void でなくて、真の分岐と偽の分岐がどちらも有効な左辺値なら、やはり有効な左辺となる。例えば、以下の二つの式は等価である。

(a ? b : c) = 5
(a ? b = 5 : (c = 5))

キャストも、そのオペランドが左辺値であれば、有効な左辺値である。左辺がキャストである単純な代入の場合、まず右辺がキャストで指定されるタイプに変換され、次にキャストなしの左辺式の型に変換される。それが格納された後、その値はキャストで指定された型に戻されて、代入自体の値となる。つまり、a の型が char * という場合、以下の二つの式は等価である。

(int)a = 5
(int)(a = (char *)(int)5)

+= のように算術演算と組み合わされた代入演算をキャストに適用すると、キャストの結果の型を使って算術演算を行ない、次に前述の場合と同じように続行される。つまり、以下の二つの式は等価になる。

(int)a += 5
(int)(a = (char *)(int) ((int)a + 5))

左辺値のキャストのアドレスを取ることはできない。そのアドレスを使うと一貫性がなくなるからである。&(int)f という書き方が許されるとしよう。f の型は float 型とする。そうすると、以下の文は、整数のビットパターンを浮動小数点数が属する場所に格納しようとすることになる。

*&(int)f = 1;

これは、(int)f = 1 が行なうことと全く違う。(int)f = 1 は、1 を浮動小数点に変換し、それを格納する。この一貫性のなさを発生させるよりも、キャストに & を使うのを禁止したほうが良いだろうと我々は考えている。

f のアドレスを int * 型のポインタとして本当に必要なら、単に (int *)&f と書けば良い。

Node:Conditionals, Next:Long Long, Previous:Lvalues, Up:C Extensions

三項演算子のオペランドの省略

三項演算子の式で、二番目のオペランドを省略することができる。省略した場合は、最初のオペランドの値が 0 でなければその値が式の値となる。

つまり、以下のような場合、

x ? : y

式の値は、x の値が 0 でなければその値となり、x が 0 ならy の値となる。

これは以下の式と全く等価である。

x ? x : y

上記のような簡単なケースでは、二番目のオペランドを省略できる有り難みが良くわからないかもしれない。これが役に立つのは、最初のオペランドが副作用が持っているか、副作用を持つ可能性がある(マクロの引数の場合)時である。その場合、中間項でそのオペランドを繰り返し使うと、副作用が二回実行される。中間項のオペランドを省略すると、既に計算済みの値を使い、再計算による望ましくない作用を伴わない。

Node:Long Long, Next:Complex, Previous:Conditionals, Up:C Extensions

倍語整数

GNU C は、int の二倍の大きさの整数型をサポートしている。この型は、符号付きの場合は long long int、符号無しの場合はunsigned long long int と書く。long long int 型の定数を作るには、整数にサフィックス LL を付ける。unsigned long long int 型の整数の場合には、ULL である。

他の整数型同様、これらの型を算術演算で使用することができる。これらの型についての、加算、減算、ビット毎のブール演算は、全ての機種で開かれた形で書かれている。乗算は、機種が全語から倍語への拡幅乗算命令をサポートしているなら、開かれた形で書かれている。除算とシフトは、特別なサポートを提供している機種でのみ開かれた形で書かれている。開かれた形で書かれていない演算は、GNU CC 付属の特別なライブラリルーチンを使う。

long long 型を関数の引数に使うときは、関数のプロトタイプ宣言なしの場合は、落とし穴に注意すること。ある関数が引数として int 型を想定している場合、long long int 型の値を渡すと、呼び出し側と呼び出される側で想定している引数のバイト数が違うので、混乱が生じる。関数が long long int を想定し、それに対し、int 型を渡す場合も同じである。このような問題を避ける最も良い方法は、プロトタイプ宣言を使うことである。

Node:Complex, Next:Hex Floats, Previous:Long Long, Up:C Extensions

複素数

GNU C は複素数型をサポートしている。整数の複素数型も浮動小数点数の複素数型もどちらも使うことができる。これには、__complex__ という予約語を使う。

例えば、__complex__ double x; と宣言すると、x は、実数部も虚数部も double 型の変数になる。__complex__ short int y; と宣言すると y は、実数部も虚数部も short int 型になる。後者の方はあまり役にたちそうもないが、複素数型は一通り全部揃っていることを表している。

複素数型の定数は、サフィックス i か j をつけて書く(どちらか一つで、どちらでも同じである)。例えば、2.5fi という定数は __complex__ float 型で、3i は __complex__ int 型になる。このように書いた整数は、常に純虚数値になるが、これを実定数に足せば、望みの複素数値を作ることができる。

複素数値を持つ式 exp から実数部を取り出すには、__real__ exp と書く。同様に、虚数部を取り出すには、__imag__ を使う。

演算子 ~ を複素数型の値に使うと、複素共役を取る。

GNU CC は複素数型の自動変数は連続的には確保しない。実数部はレジスタに取り、虚数部の方はスタック上に取る(あるいはその逆) ことさえ可能である。GNU CC が現在サポートしているデバッグ情報形式で、このような非連続的な確保を表現する手段を持っているものはない。このため、GNU CC は非連続的に確保された複素変数を、あたかも複素数型でない二つの独立した変数であるかのように記述する。実際の変数名が foo であれば、疑似的な二つの変数名は、foo$real と foo$imag になる。このような疑似的な変数は、デバッガから値を調べたり設定したりすることが可能である。

GDB は将来、このような変数の組を認識し、一個の複素数型変数として扱えるようになるだろう。

Node:Hex Floats, Next:Zero Length, Previous:Complex, Up:C Extensions

16進浮動小数

GNU CC は 1.55e1 のような普通の10進表記で書かれた浮動小数点数だけでなく、0x1.fp3 のように16進表記で書かれた数も認識する。この表記では、16進接頭辞 0x と指数フィールド p またはP は必須である。指数は、仮数部に掛けられる 2 の冪乗数を表す10進数である。すなわち、0x1.fp3 は 1 15/16 を、p3 により、8 を掛けたものになり、結局 0x1.fp3 の値は 1.55e1 と同じになる。

10進表記の浮動小数点数と違い、16進表記では指数は常に必要である。指数を書かないと、例えば 0x1.f にあるような曖昧さを解決できない。この数は 1.0f とも取れるし、あるいは f は float 型の浮動小数点定数の拡張形式でもあるので 1.9375 とも取れるのである。

Node:Zero Length, Next:Variable Length, Previous:Hex Floats, Up:C Extensions

大きさゼロの配列

GNU C では長さが 0 の配列を使うことができる。これを構造体の最後の要素として置き、実際には可変長となるオブジェクトのヘッダとして使うことができる。

struct line {
  int length;
  char contents[0];
};

{
  struct line *thisline = (struct line *)
    malloc (sizeof (struct line) + this_length);
  thisline->length = this_length;
}

C の標準では、長さ 0 の配列は許されないため、上記の contents の長さを 1 にしなければならない。このため、スペースが無駄になったり、malloc の引数が複雑になったりする。

Node:Variable Length, Next:Macro Varargs, Previous:Zero Length, Up:C Extensions

可変長配列

GNU C では可変長の自動変数配列を使うことができる。この配列は、普通の自動配列と同じように宣言するが、長さ指定が定数式でないところが違う。メモリは宣言のある場所で確保され、それが属するブロックを抜けるときに解放される。以下に例を示す。

FILE *
concat_fopen (char *s1, char *s2, char *mode)
{
  char str[strlen (s1) + strlen (s2) + 1];
  strcpy (str, s1);
  strcat (str, s2);
  return fopen (str, mode);
}

配列名の有効範囲から、ジャンプや break で抜けると、配列名に割り当てられているメモリは解放される。配列名の有効範囲にジャンプしてくるのは許されず、エラーになる。

関数 alloca を使えば、可変長配列と同じような効果を得ることができる。alloca は、多くの C の処理系で利用可能である(が、全ての処理系で利用可能なわけではない)。一方、可変長配列の方がエレガントである。

この二つの方法には他にも違いがある。allocal で確保した領域はその関数がリターンするまで存在し続ける。可変長配列の領域の方は、配列名のスコープを抜けた瞬間に解放される。(ある一つの関数で、可変長配列とalloca の両方を使った場合、ある可変長配列を解放すると、その可変長配列の確保以後に alloca で確保された領域も全て解放される。)

可変長配列を関数の引数として使うこともできる。

struct entry
tester (int len, char data[len][len])
{
  ...
}

配列の長さは、メモリが確保されるときに一回だけ計算され、その配列の有効範囲内では記憶されており、sizeof で参照することができる。

最初に配列を渡し、長さは後から渡したい場合は、仮引数のリストで前方宣言を行なえば良い。これももう一つ別の GNU の拡張機能である。

struct entry
tester (int len; char data[len][len], int len)
{
  ...
}

セミコロンの前の int len が仮引数の前方宣言である。これは、data の宣言をパースするときに len という名前を既知のものとする役割を果たす。

仮引数リストには、こういう前方宣言を幾つ書いても良い。前方宣言は、カンマまたはセミコロンを使って区切る。ただし、最後の前方宣言はセミコロンで終わっていなければならず、その後に「本物の」仮引数リストが続く。どの前方宣言も、「本物の」仮引数宣言の名前とデータ型に一致しなければならない。

Node:Macro Varargs, Next:Subscripting, Previous:Variable Length, Up:C Extensions

改変数引数を持つマクロ

GNU C では、関数と同じように、マクロも可変数の引数を取ることができる。その場合のマクロの定義構文は関数の場合に使われるものに良く似ている。次に例を示す。

#define eprintf(format, args...)  \
 fprintf (stderr, format , ## args)

args は残りの引数である。呼び出し側と同じだけの、ゼロ個以上の引数を取る。これら全ての引数とその間にカンマを加えたものが、args の値となり、args が使われるマクロ本体に代入される。結局、この例は以下のように展開される。

eprintf ("%s:%d: ", input_file_name, line_number)
==>
fprintf (stderr, "%s:%d: " , input_file_name, line_number)

文字列定数の直後のカンマは eprintf の定義から来たものであるのに対し、最後のカンマは args の値から来たものであることに注意。

## を使う理由は、args に全く引数がない場合を扱うためである。その場合、args の値は空となる。そうすると、マクロ定義中の二番目のカンマが邪魔になる。マクロをそのまま展開すると、以下のようになる。

fprintf (stderr, "success!\n" , )

これは、C の文法として誤ったものになる。## を使うとこの場合のカンマを取り除くので、代わりに以下のようになる。

fprintf (stderr, "success!\n")

これは、GNU C プリプロセッサの特別な機能である。## の後の残りの引数が空の場合の、先行する、マクロ定義から来る非空白文字の列を捨てさる。(もう一つ別のマクロ引数が先行する場合は、何も捨てない。)

最後の先行する非空白文字の列の代わりに、最後のプリプロセッサ・トークンを捨て去ったほうが良いのかもしれない。実際、いつかはこの機能をそのように変えたいと思う。我々としては、マクロ定義を書くときは、先行する非空白文字の列をちょうど一個のトークンとなるように書いて、我々がこの機能の定義を変えたときにも意味が変わらないようにすることをお勧めする。

Node:Subscripting, Next:Pointer Arith, Previous:Macro Varargs, Up:C Extensions

左辺値でない配列の添え字を取ることが可能

左辺値でない配列の添え字を取ることが、単項の & 演算子が許されない場合でも、可能である。例えば、以下は GNU C では有効だが他の C の方言では有効でない。

struct foo {int a[4];};

struct foo f();

bar (int index)
{
  return f().a[index];
}

Node:Pointer Arith, Next:Initializers, Previous:Subscripting, Up:C Extensions

`void`ポインタと関数へのポインタに対する演算

GNU C では、加算と減算の演算が、void へのポインタと関数へのポインタに対しても使うことができる。これは、void と関数の大きさを1 として扱うことにより行なわれる。

この結果、sizeof を void 型と関数型に使うこともでき、どちらも 1 を返す。

オプション -Wpointer-arith を指定すると、この拡張が使われている場合に警告するように要求する。

Node:Initializers, Next:Constructors, Previous:Pointer Arith, Up:C Extensions

非定数による初期化

C++ の標準と同様に、GNU C では、自動変数である集合体の初期化子の要素は定数式でなくても良い。以下に、実行時に変化する要素を持つ初期化子の例を挙げる。

foo (float f, float g)
{
  float beat_freqs[2] = { f-g, f+g };
  ...
}

Node:Constructors, Next:Labeled Elements, Previous:Initializers, Up:C Extensions

コンストラクタ式

GNU C はコンストラクタ式をサポートしている。コンストラクタは、キャストと初期化子を組み合わせたように見える。その値は、キャストにより指定された型のオブジェクトであり、初期化子で指定された要素を持つ。

普通、型として指定するのは構造体である。struct foo と structure が以下のように宣言されているとしよう。

struct foo {int a; char b[2];} structure;

次の例では、struct foo をコンストラクタで構築している。

structure = ((struct foo) {x + y, 'a', 0});

これは、以下のように書いたのと同じである。

{
  struct foo temp = {x + y, 'a', 0};
  structure = temp;
}

また、配列をも構築することができる。コンストラクタの全要素が、単純な定数式からなっており、初期化子として使うのに適していれば、そのコンストラクタは左辺値であり、強制的にその先頭の要素へのポインタとすることができる。以下に例を示す。

char **foo = (char *[]) { "x", "y", "z" };

要素が単純な定数でない配列コンストラクタはあまり役に立たない。その場合、コンストラクタは左辺値ではないからである。有効な使い方は二つだけである。それを添え字で参照すること、あるいは、それで配列変数を初期化することである。前者はおそらく switch 文を使うより遅くなる。一方、後者は通常の C の初期化子と同じことをする。以下に、配列コンストラクタの添え字参照の例を示す。

output = ((int[]) { 2, x, 28 }) [input];

スカラ型と共用体型に対するコンストラクタ式も許されるが、その場合コンストラクタ式はキャストと等価になる。

Node:Labeled Elements, Next:Case Ranges, Previous:Constructors, Up:C Extensions

初期化子のラベル付要素

標準の C では、初期化子の要素は決まった順番で現れることを要求する。この順番は、配列や構造体の要素が初期化される順番と同じである。

GNU C では、要素を任意の順番で指定することができる。これには要素毎に、それが適用される配列の添え字や構造体のフィールド名を指定する。この拡張は、GNU C++ では実装されていない。

配列の添え字を指定するには、要素の値の前に、[index] か[index] = と書く。例えば、

int a[6] = { [4] 29, [2] = 15 };

は、

int a[6] = { 0, 0, 15, 0, 29, 0 };

と等価である。添え字の値は、初期化される配列が自動変数であっても、定数式でなければならない。

ある範囲の要素を同じ値で初期化するには、[first ... last] = value と書く。例えば、以下のように書く。

int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };

この場合、配列の大きさは、最も大きな添え字の値に 1 を加えたものであることに注意。

構造体初期化子においては、要素の値の前に、初期化するフィールドの名前をfieldname: で指定する。例えば、以下の構造体があるとする。

struct point { int x, y; };

以下の初期化は

struct point p = { y: yvalue, x: xvalue };

次のと等価である。

struct point p = { xvalue, yvalue };

同じ意味を持つ別の書き方は .fieldname = である。以下に例を示す。

struct point p = { .y = yvalue, .x = xvalue };

また、要素ラベル(コロン形式かピリオド = 形式で)を使って共用体を初期化し、共用体のどの要素が使われるべきかを指定することができる。例えば、

union foo { int i; double d; };

union foo f = { d: 4 };

は、4 を double に変換し、二番目の要素として共用体に格納する。対照的に、4 を union foo 型に変換すると、整数 i として共用体に格納する。何故なら、4 が整数だからである。(See Cast to Union.)

この要素に名前をつける方法と、通常の C の連続する要素を初期化する方法を組み合わせることができる。初期化子の要素でラベルのないものはそれぞれ、配列あるいは構造体の次の連続する要素に適用される。例えば、

int a[6] = { [1] = v1, v2, [4] = v4 };

は、以下のものと等価である。

int a[6] = { 0, v1, v2, 0, v4, 0 };

配列初期化子の要素にラベルを付けるのは、添え字が文字だったり、enum 型に属する場合に特に便利である。例えば、以下のように書くことができる。

int whitespace[256]
  = { [' '] = 1, ['\t'] = 1, ['\h'] = 1,
      ['\f'] = 1, ['\n'] = 1, ['\r'] = 1 };

Node:Case Ranges, Next:Cast to Union, Previous:Labeled Elements, Up:C Extensions

case の範囲指定

一個の case ラベルにある範囲の連続する値を以下のように指定することができる。

case low ... high:

これは、適切な数の case ラベルを用意し、その一つ一つがlow から high の範囲の各整数値を持つようにするのと同じ効果が得られる。ここで、low と high も含まれる。

この機能は、ASCII 文字コードの範囲に使うととりわけ便利である。

case 'A' ... 'Z':

注意。... の両側には空白を置くこと。そうしないと、それを整数値として使うときに間違って解釈される。例えば、

case 1 ... 5:

と書くようにして、以下のようにはしないこと。

case 1...5:

Node:Cast to Union, Next:Function Attributes, Previous:Case Ranges, Up:C Extensions

共用体型へのキャスト

共用体型へのキャストは、指定された型が共用体型であることを除けば他のキャストと同じである。型を指定するには、union tag かtypedef 名で可能である。だが、共用体へのキャストは実際にはコンストラクタであり、キャストではない。このため、通常のキャストのような左辺値は生じない。(See Constructors.)

共用体型にキャスト可能な型は、共用体のメンバの型である。すなわち、以下のような共用体と変数が与えられていると、

union foo { int i; double d; };
int x;
double y;

x と y はどちらも union foo 型にキャスト可能である。

キャストを共用体型変数への代入の右辺として使うのは、共用体のメンバに格納するのと同じことである。

union foo u;
...
u = (union foo) x  ==  u.i = x
u = (union foo) y  ==  u.d = y

また、共用体のキャストを関数の引数として使うこともできる。

void hack (union foo);
...
hack ((union foo) x);

Node:Function Attributes, Next:Function Prototypes, Previous:Cast to Union, Up:C Extensions

関数属性の宣言

GNU C では、読者のプログラムで呼び出している関数について一定の宣言を行うと、GNU CC が関数呼出しを最適化したり、読者のコードをさらに注意深く検査することの手助けとなる。

キーワード __attribute__ を使うことにより、宣言を書くときに特別な属性を指定することができる。このキーワードの後に、二重の括弧で囲んだ属性の指定を置く。関数に対しては現在 9 個の属性、noreturn、const、format、no_instrument_function、section、constructor、destructor、unused、weak が定義されている。section を含むその他の属性は、変数宣言(see Variable Attributes)や型(see Type Attributes) に対してサポートされている。

また、各キーワードの前後に __ を付けた属性を指定しても良い。これにより、同じ名前のマクロがある可能性を心配することなく、ヘッダファイルの中でこれらの属性を使うことができる。例えば、noreturn の代わりに __noreturn__ を使うことができる。

noreturn

標準ライブラリ関数のうち幾つかは、abort や exit のように戻ることが不可能な関数がある。GNU CC はこのことを既に知っている。プログラムの中には、決して戻らない関数を自分で定義することもあるだろう。読者は、そういう関数を noreturn と宣言することで、その事実を GNU CC に知らせることができる。例えば、以下のように書いたとする。

void fatal () __attribute__ ((noreturn));

void
fatal (...)
{
  ... /* Print error message. */ ...
  exit (1);
}

キーワード noreturn を付けると、GNU CC は関数 fatal が戻りえないことを想定する。そうすると、fatal が戻った場合に何が起きるかを考えることなしに最適化を行うことができる。これによりちょっとだけ良いコードになる。もっと重要なのは、変数が初期化されていないという見せ掛けの警告を押さえることができる点にある。

呼出し側関数によりセーブされるレジスタが、noreturn 関数を呼び出す前にリストアされると想定してはいけない。

nonreturn と指定された関数に void 型以外の戻り値型を持たせるのは意味がない。

noreturn 属性は、GNU C のバージョン 2.5 以前では実装されていない。戻ることのない関数を宣言するもう一つの方法は、次のようになる。この方法は、現在のバージョンでも使えるし、古いバージョンの幾つかでも使える。

typedef void voidfn ();

volatile voidfn fatal;

const

多くの関数は引数以外の値を見ないし、戻り値以外の値に影響を与えない。このような関数は、単なる算術演算子と同じように、共通部分式削除とループ最適化の適用を受ける。こういう関数は属性 const を付けて宣言すべきだろう。例えば、

int square (int) __attribute__ ((const));

とすると、架空の関数 square は、プログラムが示すよりも呼び出す回数が少なくても安全であることを表す。

const 属性は、GNU のバージョン 2.5 以前では実装されていない。関数に副作用が無いことを宣言する別の方法としては、以下の方法がある。これは現在のバージョンと幾つかの古いバージョンで動作する。

typedef int intfn ();

extern const intfn square;

この方法は GNU C++ 2.6.0 以降では使えない。言語仕様で const は、戻り値に付けなければならないからである。

ポインタの引数があり、それにより指し示されるデータを参照している関数は、const と宣言してはならないことに注意。同様に、非 const 関数を呼び出している関数は普通は const であってはならない。void 型の関数に const を付けるのは意味がない。

format (archetype, string-index, first-to-check)

属性 format は、関数が printf や scanf、strftime 形式の引数を取り、その引数をフォーマット指定文字列に対して型検査を行うことを指定する。例えば、

extern int
my_printf (void *my_object, const char *my_format, ...)
      __attribute__ ((format (printf, 2, 3)));

と宣言すると、GNU CC は、my_printf への呼出しの引数を、 printf 形式のフォーマット指定文字列である引数 my_format との一貫性について検査を行わせる。

パラメータ archetype は、フォーマット文字列がどのように解釈されるかを決め、printf、scanf、strftime のどれかにしないといけない。パラメータ string-index はどの引数がフォーマット指定文字列の引数かを指定する(1 から始める)。一方、first-to-check はフォーマット指定文字列に対して検査を行うべき最初の引数の番号である。検査に使える引数がない関数(例えば vprintf)に対しては、3番目のパラメータをゼロと指定すること。この場合、フォーマット文字列についてだけ一貫性があるかどうかの検査が行われる。

上の例で言うと、フォーマット文字列 (my_format) は関数 my_print の二番目の引数であり、検査すべき引数は3番目の引数から始まるので、format 属性の正しいパラメータは2 と 3 になる。

format 属性を使うと、フォーマット文字列を引数として取る読者自身の関数を認識して、GNU CC がこれらの関数への呼出しに誤りがないかどうか検査させることができる。GCC は ANSI ライブラリ関数 printf、fprintf、sprintf、scanf、fscanf、sscanf、strftime、vprintf、vfprintf、vsprintf については、警告を要求したとき(-Wformat を指定したとき)は、常にフォーマットを検査するので、ヘッダファイル stdio.h を修正する必要はない。

format_arg (string-index)

format_arg 属性は、関数が、 printf あるいは scanf 形式の引数を取り、それを変更し(例えば別の言語へ翻訳する)、さらにprintf あるいは scanf 形式の関数に渡すということを指定する。例えば、

extern char *
my_dgettext (char *my_domain, const char *my_format)
      __attribute__ ((format_arg (2)));

と宣言すると、GCC は、結果が printf、scanf、strftime 形式の関数に渡される my_dgettext への呼出しに現れる引数を、printf 形式のフォーマット文字列引数 my_format と比べて、一貫性があるかどうかを検査する。

パラメータ string-index は、どの引数がフォーマット文字列引数であるかを指定する(1から始まる)。

format-arg 属性を使うと、フォーマット文字列を修正するような読者自身の関数を認識して、引数が、読者自身の関数の一つへの呼出しであるような printf、scanf、strftime関数の呼出しを検査できるようにする。GCC は、gettext、dgettext、dcgettext を常にこのように取り扱う。

no_instrument_function

-finstrument-functions を指定すると、プロファイリングを行う関数への呼出しが、ほとんどのユーザがコンパイルした関数の入り口と出口に生成される。この属性を指定した関数については、それが行われない。

section ("section-name")

GCC は、普通、生成したコードを text セクションに置く。だが、時によっては、追加のセクションが必要になったり、ある特定の関数を特別なセクションに置く必要が出てくる。section 属性は、関数を特定のセクションに置くことを指定する。例えば、

extern void foobar (void) __attribute__ ((section ("bar")));

と宣言すると、関数 foobar は bar セクションに置かれる。

ファイル形式によっては、勝手にセクションを作ることをサポートしていないので、section 属性は全てのプラットフォームで使えるわけではない。あるモジュールの内容全部をある特定のセクションに移したい場合は、リンカの機能を使うことを考えてみて欲しい。

constructor

destructor

constructor 属性は、指定した関数が、プログラムの実行がmain () に入る前に自動的に呼び出されるようにする。同じように、destructor 属性を指定すると、その関数が、main () が終了した後か exit () が呼ばれた後に、自動的に呼び出されるようにする。これらの属性を指定した関数は、プログラムの実行の間に暗黙に使われるデータを初期化するのに使える。

これらの属性は Objective C については現在実装されていない。

unused

この属性は、関数につけると、その関数は使われない可能性があるということを表す。GNU CC はこの関数に対して警告を出さないようになる。GNU C++ は現在、パラメータが C++ で有効でない定義としては、この属性をサポートしていない。

weak

weak 属性を使うと、それを指定した宣言は、グローバルシンボルではなくウィークシンボルとして生成される。これは主にユーザコードで上書き可能なライブラリ関数を定義するのに使われるが、関数でない宣言でも使うことができる。ウィークシンボルは ELF ターゲットでサポートされている。GNU アセンブラとリンカを使う場合は a.out ターゲットでもサポートされる。

alias ("target")

alias 属性を指定すると、その宣言は何か別のシンボルの別名として生成される。別のシンボルはかならず指定しなければならない。例えば、

void __f () { /* do something */; }
void f () __attribute__ ((weak, alias ("__f")));

とすると、f を __f のウィークな別名として宣言する。C++ では、元の名前にはエンコードされた名前を使わなければならない。

全てのターゲット機種でこの属性がサポートされているわけではない。

no_check_memory_usage

-fcheck-memory-usage を指定すると、サポート・ルーチンの呼出しがほとんどのメモリアクセスの前に生成され、サポートコードが使用状況を記録できるようにし、かつ非初期化また未割当のメモリ領域を使ったのを検知できるようにする。GCC が正しく扱えないので、asm 文は許されない。関数にこの属性を付けて宣言すると、その関数に対するメモリ検査コードを出さないようにし、異なるオプションを使って別個にコンパイルせずともasm 文が使えるようになり、さらに、このオプションを使ってコンパイルしても無限再帰になることなく、望むなら読者自身のサポートルーチンを書けるようになる。

regparm (number)

Intel 386 では、regparm 属性を指定すると、number 個の整数引数を、スタックの代わりにレジスタ EAX、EDX、ECX で渡すようになる。可変数引数を取る関数は、依然として全部の引数がスタックで渡される。

stdcall

Intel 386 では、stdcall 属性を指定すると、可変数引数を取るのでない限り、呼ばれた関数が、引数を渡すのに使われたスタックをポップすると想定する。

Windows NT 向け PowerPC コンパイラは、現在、stdcall 属性を無視する。

cdecl

Intel 386 では、cdecl 属性を指定すると、可変数引数を取るのでない限り、呼びだし側関数が、引数を渡すのに使われたスタックをポップすると想定する。これは、-mrtd オプションの効果を打ち消すのに使える。

Windows NT 向け PowerPC コンパイラは、現在、cdecl 属性を無視する。

longcall

RS/6000 と PowerPC では、longcall 属性を指定するとGCC はその関数を常にポインタ経由で呼び出すようにする。これにより、現在位置から 64 メガバイト(67,108,864バイト)以上離れた位置にある関数も呼び出せるようになる。

dllimport

PowrPC で Windows NT を稼働している場合、dllimport 属性を指定すると、GCC は、その関数を、Windows NT dll ライブラリにより設定される関数ポインタへのグローバルポインタ経由で呼び出す。このポインタ名は、__imp_ とその関数名を組み合わせて作られる。

dllexport

PowrPC で Windows NT を稼働している場合、dllexport 属性を指定すると、GCC は、関数ポインタへのグローバルポインタを提供する。これにより、その関数は dllimport 属性を指定することで呼び出せるようになる。このポインタ名は、__imp_ とその関数名を組み合わせて作られる。

exception (except-func [, except-arg])

PowrPC で Windows NT を稼働している場合、exception 属性を指定すると GCC は、宣言された関数に対し生成される構造化例外テーブルのエントリを修正する。文字列または識別子 except-func が、構造化例外テーブルの 3番目のエントリに置かれる。これは、ある関数を表す。この関数は、例外が発生したときに例外処理機構から呼び出される。指定されていれば、文字列あるいは識別子 except-arg が、構造化例外テーブルの4番目のエントリに置かれる。

function_vector

このオプションは、H8/300 と H8/300H において、指定した関数が関数ベクタを経由して呼び出される必要があることを示すのに使う。関数ベクタ経由して関数を呼び出すと、コードサイズが小さくなる。ただし、関数ベクタ大きさに制限があり(H8/300 では最大 128 エントリ、H8/300H では最大 64 エントリである)、割り込みベクタとスペースを共有する。

このオプションを正しく動作させるには、GNU binutils バージョン 2.7 以降の GAS と GLD を使わなければならない。

interrupt_handler

このオプションは、H8/300 と H8/300H において、指定した関数が割り込みハンドラであることを示すのに使う。GCCは、この属性が指定されていると、割り込みハンドラの中で使うのに適した、関数入り口点と出口点の命令列を生成する。

eightbit_data

このオプションは、H8/300 と H8/300H において、指定した変数が8ビットデータセクションに置かれるべきであることを示すのに使う。GCC は、8ビットデータ領域にあるデータについては、特定の操作に対しより効率の良いコードを生成する。8ビットデータ領域は、合計 256 バイトのデータに制限されていることに注意。

このオプションを正しく動作させるには、GNU binutils バージョン 2.7 以降の GAS と GLD を使わなければならない。

tiny_data

このオプションは、H8/300 と H8/300H において、指定した変数が小(tiny)データセクションに置かれるべきであることを示すのに使う。GCC は、小データ領域にあるデータについてのロードとストアに対しより効率の良いコードを生成する。小データ領域は、合計32キロバイトよりちょっと下回る大きさに制限されていることに注意。

interrupt

このオプションは、M32R/D において、指定した関数が割り込みハンドラであることを示すのに使う。GCCは、この属性が指定されていると、割り込みハンドラの中で使うのに適した、関数入り口点と出口点の命令列を生成する。

model (model-name)

このオプションは、M32R/D において、オブジェクトのアドレス可能性と関数に対して生成されるコードを設定するのに使う。識別子 model-name は、small、medium、large のうちのどれか一つである。これらはそれぞれコード・モデルを表す。

small モデルオブジェクトは、メモリの下位 16MB に置かれ(これにより、それらのアドレスは ld24 命令によりロード可能になる)、bl 命令で呼びだし可能である。

medium モデルオブジェクトは、32ビットアドレス空間のどこに置いても良く(GCC は、これらのアドレスをロードするのに seth/add3 命令列を生成する)、bl 命令で呼びだし可能である。

large モデルオブジェクトは、32ビットアドレス空間のどこに置いても良く(GCC は、これらのアドレスをロードするのに seth/add3 命令列を生成する)、bl 命令では到達可能でない可能性がある(GCC は、さらに遅い seth/add3/jl 命令列を生成する)。

複数の属性を一個の宣言の中で指定するには、二重括弧の中にカンマで区切って並べるか、一つの属性宣言の直後に属性宣言を続けて書けば良い。

__attribute__ 機能に反対する人達もいて、代わりにANSI C の #pragma を使うべきだと主張している。#pragma を使わないのには理由が二つある。

#pragma コマンドをマクロから生成するのは不可能である。
他のコンパイラで同じ #pragma がどんな意味を持つかわからない。

この二つの理由は、#pragma を使えば良いのではないかと提案されているほとんど全てのアプリケーションに対して適用される。#pragma は何に対して使っても基本的に誤りなのである。

Node:Function Prototypes, Next:C++ Comments, Previous:Function Attributes, Up:C Extensions

プロトタイプ宣言と古い形式の定義

GNU C は ANSI C を拡張して、関数のプロトタイプがその後に現れる古い形式の、非プロトタイプ的定義を上書きすることを許している。以下の例を考えてみよう。

/* Use prototypes unless the compiler is old-fashioned.  */
#ifdef __STDC__
#define P(x) x
#else
#define P(x) ()
#endif

/* Prototype function declaration.  */
int isroot P((uid_t));

/* Old-style function definition.  */
int
isroot (x)   /* ??? lossage here ??? */
     uid_t x;
{
  return x == 0;
}

uid_t 型がたまたま short になる場合を考えてみよう。ANSI C ではこの例は許されない。なぜなら、古い形式の非プロトタイプ的な定義においては、ワードより小さいサイズの引数は格上げされるからである。このため、この例では、関数の定義での引数は実際には int になるので、引数の型が short であるプロトタイプと一致しないのである。

ANSI C のこの制限により、旧来の C コンパイラでも動作するコードを書くのが難しくなっている。プログラマは、uid_t 型が、short なのか、int なのか、あるいは long なのか知らないからである。このため、GNU C ではこういう場合、プロトタイプで後続の古い形式の定義を上書きするようになっている。もっと正確に言うと、GNU C では、関数のプロトタイプの引数型が、後に現れる古い形式の定義で指定される型を、前者の型が格上げ前の後者の型と同じである場合には、上書きするのである。このため、GNU C では上の例は、以下のように書いたのと同じである。

int isroot (uid_t);

int
isroot (uid_t x)
{
  return x == 0;
}

GNU C++ では古い形式の関数定義をサポートしていないので、この拡張は関係ない。

Node:C++ Comments, Next:Dollar Signs, Previous:Function Prototypes, Up:C Extensions

C++ 形式のコメント

GNU C では、C++ 形式のコメント、すなわち、// で始まり、行末までとなるコメントを使うことができる。他の多くの C の実装でもこのコメント形式を許しており、将来 C の規格に取り入れられそうである。しかし、-ansi か -traditional を指定した場合はC++ 形式のコメントを認識しない。それらは、dividend//*comment*/divisor のような古い形の構文と互換でないからである。

Node:Dollar Signs, Next:Character Escapes, Previous:C++ Comments, Up:C Extensions

識別子名中のドル記号

GNU C では、普通、ドル記号を識別子名の中で使うことができる。これは、多くの古い C の実装でそういう識別子を許しているからである。しかし、2,3のターゲット機種では識別子名の中にドル記号が使えない。これは、そのターゲットのアセンブラが識別子名中のドル記号を許していないためであることが多い。

Node:Character Escapes, Next:Alignment, Previous:Dollar Signs, Up:C Extensions

定数中の <ESC> 文字

文字列や文字定数中で、文字シーケンス \e を使って ASCII 文字<ESC> を表すことが可能である。

Node:Alignment, Next:Variable Attributes, Previous:Character Escapes, Up:C Extensions

型や変数のアラインメントの問い合わせ

キーワード __alignof__ をオブジェクトに対して使うと、そのオブジェクトのアラインメントを返し、型に対して使うとその型で通常必要とされる最小のアラインメントを返す。構文は sizeof と同じである。

例えば、ターゲット機種が double の値が 8 バイト境界に揃うことを要求している場合には、__alignof__ (double) は 8 になる。これは、多くの RISC 機種で実際に正しい。それよりは古目の設計の機種では、__alignof__ (double) は 4 だったり、2 ということさえある。

機種によってはアラインメントを全く必要としないものもある。そういう機種では、どんな型に対する参照も、たとえ奇数アドレスにあっても許される。こういう機種に対しては、__alignof__ は、型の推奨アライメントを報告する。

__alignof__ のオペランドが型ではなくて左辺値の時は、その左辺値が取ることが知られているうちの最大のアラインメントが、__alignof__ の値となる。このアラインメントはそのデータ型自体による場合もあるし、それが構造体の一部であり、その構造体のアラインメントを継承していることによる場合もある。例えば、以下のように宣言したとする。

struct foo { int x; char y; } foo1;

__alignof__ (foo1.y) の値はおそらく 2 か 4 になり、それは__alignof__ (int) と同じになる。これは、foo1.y のデータ型はそれ自体はなんらアラインメントを要求しないとしてもである。

オブジェクトのアラインメントを指定する関連する機能としては、__attribute__ ((aligned (alignment))) がある。次のセクションを参照のこと。

Node:Variable Attributes, Next:Type Attributes, Previous:Alignment, Up:C Extensions

変数の属性の指定

キーワード __attribute__ を使うと、変数や構造体のフィールドの特別な属性を指定することができる。このキーワードの後ろに属性の指定を二重括弧の中に入れて書く。現在、変数用には 8 個の属性が定義されている。aligned、mode、nocommon、packed、section、transparent_union、unused、weak である。その他に、関数(see Function Attributes) と型(see Type Attributes) で使える属性がある。

また、各キーワードの前後に __ を付けた属性を指定しても良い。これにより、同じ名前のマクロがある可能性を心配することなく、ヘッダファイルの中でこれらの属性を使うことができる。例えば、aligned の代わりに __aligned__ を使うことができる。

aligned (alignment)

この属性は変数や構造体のフィールドの最小のアラインメントをバイト単位で指定する。例えば、

int x __attribute__ ((aligned (16))) = 0;

と宣言すると、GCC はグローバル変数 x を 16 バイト境界に割り当てる。68040 では、これをasm 式と組み合わせることで、オペランドが16バイト境界に整列している必要がある move16 命令を使えるようになる。

また、構造体のフィールドのアラインメントを指定することもできる。例えば、倍語境界に整列した int の対を作るには以下のように書けば良い。

struct foo { int x[2] __attribute__ ((aligned (8))); };

これは、double 型のメンバを入れた共用体を作って、その共用体を倍語境界に整列させるという通常の手段の代替方法である。

関数に対してはアラインメントを指定することはできない。関数のアラインメントは機種によって決まっており、変更不可能である。typedef 名に対してもアラインメントを指定することはできない。typedef 名は新たな型ではなくて、単なる別名に過ぎないからである。

上の例のように、与えられた変数や構造体フィールドに対して GCC に使って欲しいと思うアラインメントを明示的に指定することが可能である。もう一つの方法として、アラインメント因子を書かずに、コンパイルのターゲット機種の意味のある最大のアラインメントを変数やフィールドに与えるようコンパイラに任せることもできる。例えば、以下のように書くことができる。

short array[3] __attribute__ ((aligned));

aligned 属性の指定で、アラインメント因子を書かないと、GCC は、宣言された変数やフィールドに、読者のコンパイルのターゲットである機種で任意のデータ型に対して使われる最大のアラインメントを自動的に設定する。こうすると、コピー操作の効率が良くなることが多い。GCC は、このようにアラインメントを設定した変数やフィールドとの間のコピーを行うときに、最大のメモリの塊をコピーする命令を使うことができるからである。

aligned 属性ができるのはアラインメントを大きくすることだけである。だが、小さくするには packed 属性を指定すれば良い。

aligned 属性の効果は、リンカの持つ制限により制限を受ける可能性があることに注意して欲しい。多くのシステムでは、リンカは、変数のアラインメントを、ある決まった最大のアラインメントまでしか調整できない。(リンカの中には、可能なアラインメントの最大値が非常に小さいものがある。) 読者のところのリンカが、変数を最大で 8 バイト境界にまでしか整列できないのであれば、__attribute__ で aligned(16) と指定しても、8 バイトのアラインメントしか提供されない。詳細な情報についてはリンカのドキュメントを見て欲しい。

mode (mode)

この属性は、宣言に対するデータ型を指定する。この型はモード mode に対応するどんな型でも良い。これは実質的には、その幅に対応した整数型か浮動小数点型を要求したことになる。

また、モード byte または __byte__ を指定して、一バイト整数に対応するモードであることを指示することもできる。同様に、word または __word__ で一語長の整数モードを、pointer または __pointer__ でポインタを表現するのに使われるモードを指示する。

nocommon

この属性は、GNU CC に対し、変数をコモン領域に置かずに、直接メモリ割当を行なうよう要求する。オプション -fno-common オプションを指定すると、全ての変数に対しこれを行なう。

変数に対し nocommon 属性を指定すると、ゼロによる初期化が行なわれることになる。ある変数は、一個のソースファイルでしか初期化してはならない。

packed

packed 属性は、変数や構造体フィールドが持つアラインメントを最小限にすべきであることを指定する。最小限のアラインメントとは、aligned 属性でもっと大きな値を指定しない限り、変数の場合は1バイトであり、構造体フィールドの場合は 1 ビットである。

以下の構造体では、フィールド x がパックされており、このため a の直後に配置される。

struct foo
{
  char a;
  int x[2] __attribute__ ((packed));
};

section ("section-name")

通常、GNU CC は生成したオブジェクトを data や bss といったセクションに置く。だが、追加で別のセクションが必要になったり、あるいはある種の特別な変数を特別なセクションに置く必要があったりすることがある。これは、例えば特別なハードウェアにマップするため等の理由で必要になる。section 属性は、変数(または関数)をある特定のセクションに置くことを指定する。例えば、以下のプログラムでは色々な固有のセクション名を使っている。

struct duart a __attribute__ ((section ("DUART_A"))) = { 0 };
struct duart b __attribute__ ((section ("DUART_B"))) = { 0 };
char stack[10000] __attribute__ ((section ("STACK"))) = { 0 };
int init_data __attribute__ ((section ("INITDATA"))) = 0;

main()
{
  /* Initialize stack pointer */
  init_sp (stack + sizeof (stack));

  /* Initialize initialized data */
  memcpy (&init_data, &data, &edata - &data);

  /* Turn on the serial ports */
  init_duart (&a);
  init_duart (&b);
}

section 属性は、上記の例のように、グローバル変数の初期値付き定義に使うこと。GNU CC は、初期値なしの変数宣言にsection 属性を使うと、警告を発するか、さもなければ無視する。

section 属性は、リンカの動作する仕組みにより、完全に初期化されたグローバルな定義にしか使うことができない。リンカは各オブジェクトは一回だけ定義されることを要求する。例外は、非初期化変数であり、一時的に common (あるいはbss) セクションに置かれ、このため複数回「定義」可能である。変数を強制的に初期化するには、-fno-common オプションかnocommon 属性を使うことが出来る。

オブジェクトファイル形式の中には、任意のセクションをサポートしないものがあり、そのため section 属性は全てのプラットフォームで利用できるわけではない。あるモジュールの全内容をある特定のセクションに対応させる必要がある場合は、代わりにリンカの機能を使うことを考えたほうが良い。

transparent_union

この属性は、共用体である関数の仮引数に付け、対応する実引数の型はその共用体のどのメンバの型であっても良いが、実引数は共用体の先頭のメンバの型として渡されるということを意味する。詳細は See Type Attributes を参照。また、この属性を共用体データ型のtypedef に使うこともできる。その場合、この型を持つ全ての関数仮引数に適用される。

unused

この属性は、変数に付け、この変数が使用されない可能性があることを意味する。GNU CC は、この変数については警告を出さない。

weak

weak 属性は、See Function Attributes で説明する。

model (model-name)

M32R/D ではこの属性を使って、あるオブジェクトのアドレス可能性を設定する。識別子 model-name は、small、medium、large の一つで、それぞれコードモデルを表す。

small モデルのオブジェクトはメモリの下位 16MB に置かれる(これにより、これらのオブジェクトのアドレスは ld24 命令でロード可能である。)

medium モデルと large モデルのオブジェクトは 32 ビットのアドレス空間のどこにでも置かれる(GNU CC はこれらのアドレスをロードするために、seth/add3 命令を生成する)。

複数の属性を指定するには、それらを二重括弧で囲み、その中でカンマで各属性を区切る。例えば、__attribute__ ((aligned (16), packed)) とする。

Node:Type Attributes, Next:Inline, Previous:Variable Attributes, Up:C Extensions

型の属性の指定

キーワード __attribute__ を使うと、struct 型やunion 型を定義するときに、特別な属性を指定することができる。このキーワードの後ろに、属性の指定を二重括弧に入れて続けておく。型を定義する際の属性としては、現在三つ定義されている。aligned、packed、transparent_union である。これ以外の属性が、関数(see Function Attributes)や変数(see Variable Attributes)用に定義されている。

これらのうちの属性は、キーワードの前後に __ を付加して指定しても良い。こちらを使うと、同じ名前のマクロがあるかどうかを気にせずにヘッダフィアルの中で使うことができる。例えば、aligned の代わりに __aligned__ を使っても良い。

属性 aligned と transparent_union は、typedef 宣言の中か、完全な enum、struct、union 型の定義の閉じ中括弧の直後に置くことができる。属性 packed は、定義の閉じ中括弧の直後にだけ置くことができる。

また、属性を、閉じ括弧の後ろではなくて、enum、struct、union タグとその型名の間に置くこともできる。

aligned (alignment)

この属性は、指定された型の変数に対し、最小のアラインメントをバイト数で指定する。例えば、

struct S { short f[3]; } __attribute__ ((aligned (8)));
typedef int more_aligned_int __attribute__ ((aligned (8)));

と宣言すると、struct S 型や more_aligned_int 型の変数がそれぞれ、少なくとも 8 バイト境界に割り当てられ、整列されることを保証する。SPARC では、struct S 型の変数を全て8 バイト境界に整列すると、GNU CC が ldd 命令と std 命令(倍語ロードと倍語ストア)を struct S 型の一つの変数を同じ型の変数にコピーするのに使うことができ、そのため実行時の効率が改善される。

任意の与えられた struct 型や union 型のアラインメントはANSI C 規格により、少なくとも、問題の struct や union の全てのメンバのアラインメントの最小公倍数の倍数になることが要求されていることに注意して欲しい。このため、struct や union 型のアラインメントを調整するのに、そのメンバのどれか一つに alignment を属性を付加することで、実質的に行なえることになる。だが、上の例で説明した書き方の方が、struct 型や union 型全体のアラインメントを調整するための指定としては、より明白で、判りやすく、読みやすい方法と言える。

前出の例のように、与えられた struct 型や union 型に対して使って欲しいアラインメントをバイト単位で明示的に指定することができる。別の方法としては、アラインメント因子を書かずに、コンパイルのターゲット機種で意味のある最大のアラインメントをその型に指定させるのを、GNU CC に任せることもできる。例えば、以下のように書いても良い。

struct S { short f[3]; } __attribute__ ((aligned));

aligned 属性の指定で、アラインメント因子を書かないと、GCC は、その型に、読者のコンパイルのターゲットである機種で任意のデータ型に対して使われる最大のアラインメントを自動的に設定する。こうすると、コピー操作の効率が良くなることが多い。GCC は、このようにアラインメントを設定した変数やフィールドとの間のコピーを行うときに、最大のメモリの塊をコピーする命令を使うことができるからである。

上の例で、short の大きさがどれも 2 バイトであれば、struct S 型全体の大きさは 6 バイトになる。この大きさ以上で、最小の 2 の冪乗は 8 なので、GCC は struct S 型全体のアラインメントを 8 バイトに設定する。

与えられた型に対し時間効率の良いアラインメントを選択するようにGCC に要求し、その型の単独のオブジェクトだけを個々に宣言することもできるが、GCC の時間優先アラインメントを選択する能力は、主に適切な(効率良く整列する)型を持つ変数の配列を作ろうとしている時にしか役に立たない。効率良く整列される型の変数の配列を宣言したり、使う時は、読者のプログラムは関連する型へのポインタに対するポインタ算術演算(あるいは同じことだが添え字による参照) も行われるだろう。これらのポインタ算術演算に対して GCC が生成するコードは、効率良く整列される型に対するもののほうが、他の型に対するものより効率が良くなる。

属性 aligned はアラインメントを増加させるだけだが、packed を指定すれば減少させることもできる。以下を参照。

aligned 属性の効果は、リンカの持つ制限により限定される可能性があることに注意してほしい。多くのシステムでは、リンカはある決まった最大のアラインメントに変数のアラインメントを切り上げるよう調整することしかできない。(リンカによっては、このサポートされている最大のアラインメントが非常に小さいこともある。) 読者のところのリンカが、最大 8 バイトまでしか変数のアラインメントを取れない場合は、__attribute__ でaligned(16) を指定しても、8 バイトのアラインメントしか取れない。詳細については読者のところのリンカのドキュメントを見て欲しい。

packed

この属性は、enum 型、struct 型、union 型の定義に付けて、その型を表現するのに最低限必要なメモリを指定する。

この属性を struct 型と union 型に指定するのは、その構造体や共用体のメンバのそれぞれに packed 属性を指定するのと同じである。コマンド行で -fshort-enums オプションを指定するのは、全ての enum 型の定義に packed 属性を指定すると同じである。

この属性は enum の定義の閉じ中括弧の後にしか指定できない。typedef の中では、その中に enum の定義も含んでいない限り、指定できない。

transparent_union

この属性を union 型の定義に付けると、その共用体型を持つ関数のパラメータがある場合、その関数への呼出しが特別な方法で取り扱われる。

第一に、ある透過共用体型に対応する引数は、その共用体のメンバのうちのどの型にでもなりうる。この場合、キャストは不要である。また、共用体がポインタ型を含んでいれば、対応する引数はヌルポインタ定数か void ポインタ式になりうる。共用体が、void ポインタ型を含んでいれば、対応する引数は任意のポインタ式になりうる。共用体のメンバの型がポインタであれば、それが参照している型についての const のような修飾子は、保存されなければならない。これは普通のポインタの変換と同じである。

第二に、その引数は、透過共用体自身の呼出し規約ではなくて、共用体の先頭のメンバの呼出し規約を使って関数に渡される。その共用体のメンバは全て同じマシン表現にならなければならない。これは、この引数を正しく渡すために必要である。

透過共用体は、互換性の理由により複数のインターフェースを持つライブラリ関数のために設計されている。例えば、関数 wait は、Posix に準拠するためには int * 型の値を受け付けるか、4.1BSD のインターフェースに準拠するためには union wait * 型の値を受け付けるかのどちらかでなければならない。wait の仮引数がvoid * であれば、wait はどちらの種類の引数でも受付可能になるが、他のどんなポインタ型でも受け付けることになってしまい、引数型の検査が役に立たなくなってしまう。代わりに、<sys/wait.h> では以下のようにインターフェースを定義しても良い。

typedef union
  {
    int *__ip;
    union wait *__up;
  } wait_status_ptr_t __attribute__ ((__transparent_union__));

pid_t wait (wait_status_ptr_t);

このインターフェースでは、int * 型か union wait * 型の引数を渡すことができる。呼出し規約は int * を使う。プログラムでは、どちかの型の引数で wait を呼び出すことができる。

int w1 () { int w; return wait (&w); }
int w2 () { union wait w; return wait (&w); }

このインターフェースを使った場合、 wait の実装は以下のようになるだろう。

pid_t wait (wait_status_ptr_t p)
{
  return waitpid (-1, p.__ip, 0);
}

unused

この属性を型(union や struct を含む)に指定すると、この型の変数が使われない可能性があることを意味する。GNU CC は、この型の変数が何もしないように見えた場合でも、これらの変数に対しては警告を出さない。これは、ロックやスレッドのクラスでは良くあることである。これらの場合、定義はされるが参照はされない。だが、コンストラクタやデストラクタが含まれていて、その中には色々な管理を行なう機能を持つ。

属性を複数指定するには、カンマで区切って全体を二重括弧で囲む。例えば、__attribute__ ((aligned (16), packed)) とする。

Node:Inline, Next:Extended Asm, Previous:Type Attributes, Up:C Extensions

マクロと同程度の速さのインライン展開関数

関数を inline と宣言することで、その関数のコードを呼出し箇所に統合することを GNU CC に指示する。これにより、関数呼出しの負荷を削除するので実行が速くなる。さらに、実引数値のどれかが定数であれば、それらの値が既知であることにより、インライン指定のついた関数のコードを全て含める必要が無いように、コンパイル時のコードの単純化が可能になる。インライン展開によりコードサイズがどうなるかは予測が難しい。インライン展開により、オブジェクトコードは大きくなることもあるし、小さくなることもある。個々の場合による。関数のインライン展開は最適化の一つであり、最適化付きコンパイルの場合にしか実際には機能しない。-O を指定しなければ、実際にはどの関数もインライン展開されない。

関数のインライン展開を宣言するには、その宣言で inline というキーワードを以下のように使う。

inline int
inc (int *a)
{
  (*a)++;
}

(ANSI C に準拠するプログラムで取り込まれるヘッダファイルを各場合は、inline の代わりに __inline__ と書くようにする。See Alternate Keywords。) 「充分単純」な関数は、-finline-functions オプションを指定することで、全てインライン展開関数とすることができる。

関数定義中である特定の使い方をしていると、インライン展開に適さなくなることに注意。そういう使い方には次のものがある。varargs を使っている、alloca を使っている、可変長データ型を使っている(see Variable Length)、計算形 goto を使っている(see Labels as Values)、非局所 goto を使っている、入れ子関数を使っている(see Nested Functions)。-Winline を指定すると、inline 付きの関数が置き換え可能でない場合は警告を出し、可能でない理由を表示する。

C と Objective C では、C++ とは違って、キーワード inline は、関数のリンケージには影響しないことに注意。

GNU CC は、C++ プログラムのクラス本体内で定義されているメンバ関数は、明示的に inline と宣言されていなくても、自動的にインライン展開する。(この効果をなくすには、-fno-default-inline オプションを指定する。see Options Controlling C++ Dialect.)

ある関数がインライン展開関数であり static でもあるとき、その関数への呼出しが全て呼出し側に統合されて、かつその関数のアドレスが使われることがない場合は、関数自身のアセンブラコードは決して参照されることがない。この場合、GNU CC は、-fkeep-inline-functions を指定しない限り、その関数のアセンブラコードを実際には出力しない。呼出しの中には様々な理由(特に、関数定義の前にある呼出しや、関数定義内の再帰呼出しは統合が不可能である)に統合できない。統合されない呼出しがあると、その関数は通常のようにアセンブラコードにコンパイルされる。関数は、プログラムがそのアドレスを参照している場合もコンパイルされなければならない。インライン展開が不可能だからである。

インライン関数が static でない場合は、コンパイラは他のソースファイルからの呼出しがあることを想定しなければならない。グローバルシンボルはどんなプログラムでも一箇所でしか定義できないので、その関数は他のソースファイルで定義してはならない。このため、他のソースファイルにある呼出しは統合できないのである。このため、非 static インライン関数は常に普通の形でコンパイルされる。

関数定義に inline と extern の両方を指定すると、その定義はインライン展開でのみ使われる。関数定義自体がコンパイルされることは決してない。その関数のアドレスを明示的に参照してもコンパイルされないのである。そのようなアドレスは、関数を宣言しただけで定義していない場合のように、外部参照になる。

inline と extern をこのように組み合わせると、ほとんどマクロと同じ効果になる。これの使い方は、この二つのキーワードを付けた関数定義をヘッダファイルに置いておき、この定義のコピー(inline と extern を付けないもの)をライブラリファイルに置いておくのである。ヘッダファイルの方の関数定義は、この関数のほとんどの呼出しをインライン展開されるようにする。この関数のそれ以外の使い方をすれば、ライブラリ中の一個のコピーの方を参照する。

GNU C は、最適化を行わない場合はどんな関数もインライン展開しない。こういう場合にインライン展開した方が良いのかどうかはっきりしていない。だが、最適化を行わない場合の正しい実装が難しいということが判ったので、我々は簡単な方にした。すなわち、インライン展開をしないことにした。

Node:Extended Asm, Next:Asm Labels, Previous:Inline, Up:C Extensions

C の式をオペランドとするアセンブラ命令

asm を使った場合のアセンブラ命令で、その命令のオペランドをC の式を使って指定することができる。これは、読者が使いたいデータがどのレジスタにあるのか、メモリのどこにあるのかを考える必要がないということを意味する。

マシン記述に現れるようなアセンブラ命令のテンプレート、それに各オペランドに対するオペランド制約文字列を指定しなければならない。

例えば、以下に 68881 の fsinx 命令の使い方を示す。

asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));

ここで、angle 入力オペランドを表す C の式であり、result は出力オペランドを表す C の式である。それぞれ、"f" をオペランド制約として持ち、浮動小数点レジスタが必要である事を示している。=f の = は、オペランドが出力であることを表している。出力オペランドの制約は全て = を使わなければならない。制約の書き方はマシン記述で使われているものと同じである(see Constraints)。

各オペランドは一個のオペランド制約文字列とそれに続く括弧に入った C の式で記述される。コロンでアセンブラテンプレートと出力オペランドの先頭を区切り、もう一つのコロンで最後の出力オペランドと入力オペランドの先頭を区切る。カンマで、それぞれのグループのオペランドを区切る。オペランドの総数は、10 か、マシン記述中の命令パターンで使われているものの中で最大のオペランド数か、どちらか大きいほうに制限される。

出力オペランドはないが、入力オペランドはあるという場合は、出力オペランドが本来置かれる場所を囲むようにコロンを二つ続けて置かなければならない。

出力オペランドの式は左辺値でなければならない。GNU CC はこれを検査することが可能である。入力オペランドは左辺値である必要はない。GNU CC は、オペランドのデータ型が実行される命令に適切なものかどうかの検査は行えない。アセンブラ命令テンプレートの構文解析は行わないので、それが何を意味するものか、あるいはそれがアセンブラへの入力として有効なものかどうかさえも判らないのである。拡張された asm の機能がもっとも良く使われるのは、GNU CC がその存在を知らないような機械語命令に対してである。出力式が直接アドレスを指定できないものである場合は(例えば、ビットーフィールド)、制約でレジスタを許すようにしなければならない。その場合、GNU CC は asm の出力としてレジスタを使い、その後そのレジスタを出力先に格納する。

通常の出力オペランドは書き込み専用でなければならない。GNU CC は、現在の命令の前にこれらのオペランドに入っていた値は死んでおり、生成する必要がないと想定する。拡張 asm は、入力／出力両用、あるいは読み書き両用のオペランドをサポートしている。そういうオペランドであることを示すには制約文字 + を使い、出力オペランドとして列挙する。

読み書き両用のオペランド(あるいは一部のビットしか変化しないオペランド) に対する制約がレジスタを許しているなら、別の選択肢として、論理的にはその機能を二つの別々のオペランドに分割し、一つを入力オペランド、もう一つを書き込み専用出力オペランドとすることもできる。この二つのオペランドの間の関係は、制約により、命令を実行するときには二つのオペランドが同じ位置にある必要があると指定することで、表される。両方のオペランドに同じ C の式を使うことも出来るし、違う式を使っても良い。例えば、以下では、(架空の) combine 命令を bar を読みだし専用読みだし元オペランドとして、foo を読み書き両用目的先オペランドとして書いている。

asm ("combine %2,%0" : "=r" (foo) : "0" (foo), "g" (bar));

オペランド 1 の制約 "0" は、オペランド 0 と同じ位置を占めなければならないということを表す。制約の中に数字を置くのは入力オペランドの場合だけ許され、それは出力オペランドを参照していなければならない。

制約の中の数字だけが、一つのオペランドがもう一つ別のオペランドと同じ位置になることを保証できる。単に foo が両方のオペランドの値になっているというだけでは、生成されるアセンブラコードで同じ位置になるということを保証するには充分ではない。以下のように書いたのでは正しく動作しない。

asm ("combine %2,%0" : "=r" (foo) : "r" (foo), "g" (bar));

色々な最適化や再ロードにより、オペランド 0 と 1 が異なるレジスタに置かれる可能性はある。GNU CC は、そうしない理由はないということを知っている。例えば、GCC は foo の値のコピーが一つのレジスタにあることを見つけ、オペランド 1 用にそれを使うが、オペランド 0 を別のレジスタに出力するかもしれない(後で foo 自身のアドレスにコピーする)。当然、オペランド 1 用のレジスタはアセンブラコードでは言及さえされていないので、その結果は動作しないのだが、GNU CC にはそれが判らないのである。

命令によっては特定のハードレジスタを上書きするものがある。このことを記述するには、入力オペランドの後ろに3番目のコロンを置き、その後に上書きされるハードレジスタ名を、レジスタ一つを一つの文字列として置く。以下に VAX 用の実際の例を示す。

asm volatile ("movc3 %0,%1,%2"
              : /* no outputs */
              : "g" (from), "g" (to), "g" (count)
              : "r0", "r1", "r2", "r3", "r4", "r5");

入力オペランドと出力オペランドが重なるような破壊指定はエラーである(例えば、一つのメンバからなるレジスタクラスを記述するオペランドを破壊されるリストで言及すること)。一番はっきりしている例は、入力オペランドが変更を受けるのに、出力として使われていないという記述を行うのは正しくない。いずれにしても入力オペランドと出力オペランドとして指定する必要がある。使われない出力オペランドしかない場合は、以下で説明するように、asm 分に volatile を指定する必要もある。

このアセンブラコードから特定のハードウェアレジスタを参照する場合は、おそらく、三番目のコロンの後にそのレジスタを列挙して、GCC に対してそのレジスタの値が変更を受けることを知らせる必要があるだろう。

読者の書いたアセンブラ命令が条件コードレジスタを変更し得るなら、cc を破壊されるレジスタのリストに入れておく。いくつかの機種では GNU CC は、条件コードをある特定のハードウェアレジスタで表現する。それ以外の機種では、条件コードは違う取扱いを受けるので、cc を指定しても意味がない。だが、どんな機種でもコードとしては有効である。

読者の書いたアセンブラ命令が予期できない形でメモリを変更するなら、memory を破壊されるレジスタのリストに追加しておく。こうすると、GCC は、そのアセンブラ命令を越えては、メモリ値をレジスタにキャッシュしておくことはしない。

複数のアセンブラ命令をまとめて一個の asm テンプレートに入れることができる。その場合、それぞれを改行(\n と書く)かアセンブラが許すなら、セミコロンで区切る。GNU アセンブラはセミコロンが使えるし、ほとんどの Unix アセンブラでも使えるようだ。入力オペランドはどの破壊レジスタも使わないこと、そして、出力オペランドのアドレスも使われないことが保証されている。このため、破壊レジスタは好きなだけ何度でも読み書きすることができる。一個のテンプレートに複数の命令を入れる例を以下に示す。サブルーチン _foo はレジスタ 9 と 10 で引数を受け取ることを想定している。

asm ("movl %0,r9;movl %1,r10;call _foo"
     : /* no outputs */
     : "g" (from), "g" (to)
     : "r9", "r10");

出力オペランドに & 制約修飾子がない限り、GNU CC は、関係のない入力オペランドと同じレジスタにそれを割り当てる。この時、入力は出力が生成される前に消費されるという想定を行う。この想定は、アセンブラコードが実際に複数の命令から成っている場合は偽になる可能性がある。そういう場合、入力と重なってはならない出力オペランドにはそれぞれ& を付けること。 See Modifiers。

アセンブラ命令により生成される条件コードをテストしたい場合は、以下のように、asm 構文に分岐と命令を含めなければならない。

asm ("clr %0;frob %1;beq 0f;mov #1,%0;0:"
     : "g" (result)
     : "g" (input));

これはアセンブラが、GNU アセンブラやほとんどの Unix のアセンブラのように、ローカルラベルをサポートしていることを想定している。

ラベルについて言えば、一つの asm から別の asm へのジャンプはサポートされていない。GCC の最適化器はそういうジャンプについては知らないので、どのように最適化するかを決めるときに考慮にいれることができないのである。

普通、これらの asm 命令を最も手軽に使うには、関数のように見えるマクロに押し込めることである。例えば、以下のようにする。

#define sin(x)       \
({ double __value, __arg = (x);   \
   asm ("fsinx %1,%0": "=f" (__value): "f" (__arg));  \
   __value; })

ここでは、変数 __arg を使って、命令が適切な double 型の値に作用すること、それに引数 x として自動的に double 型に変換可能なものだけを受け付けることを保証している。

命令が正しいデータ型に作用することを保証するもう一つの方法は、asm の中でキャストを使うことである。これは、変数 __arg を使う方法とは、さらに差異の大きな型に変換するという点において異なる。例えば、望ましい型が int だとすると、引数を int にキャストした場合、その引数としてポインタを何の不満もなく受け付ける。一方、その引数を、__arg で指定される int 型の変数に代入すると、呼出し側で明示的にキャストしていない限り、ポインタ型を使うと警告がでる。

asm 文に出力オペランドがあると、GNU CC は最適化目的のためにその命令に、出力オペランドを変更する以外の副作用がないことを想定する。これは副作用がある命令を使うことができないということではないが、注意しなくてはならない。GCC は、出力オペランドが使われていないとその命令を消去したり、ループの外側に移動したり、共通部分式を構成している場合には二つの命令を一つに置き換えたりするからである。また、読者の命令に変数について副作用があり、その変数がそれ以外には変更を受けないものに見えたなら、その変数の元の値は、レジスタに残っていれば、後で再使用される可能性がある。

asm の後にキーワード volatile を指定することで、その asm 命令が削除されたり、著しく移動されたり、組み合わせられたりするのを避けることができる。

#define get_and_set_priority(new)  \
({ int __old; \
   asm volatile ("get_and_set_priority %0, %1": "=g" (__old) : "g" (new)); \
   __old; })

出力のない asm 命令を書くと、GNU CC はその命令に副作用があることを知り、その命令を消したりループの外側に移動したりしない。読者の書いた命令の副作用が純粋に外部的なものでないが、入力を読み込み、指定されたレジスタやメモリを破壊する以外の方法で読者のプログラム中の変数に影響を与えるなら、キーワード volatile を指定して、GNU CC の将来のバージョンが中心領域内で命令を移動するのを防いでおくべきである。

オペランドや破壊が一つもない asm 命令(それに「古い形式の」asm)は、到達不能でない限り、おかまいなしに削除されたり大きく移動されたりすることはない。キーワード volatile を書いたのと同じである。

volatile 指定付きの asm 命令であっても、GCC にとって違いがないと見れば、例えばジャンプ命令をまたぐといったような移動も行われる可能性があるので注意して欲しい。揮発性 asm 命令の列がそのまま連続に保たれると期待することはできない。出力が連続になって欲しければ、一個の asm 文を使うことである。

アセンブラ命令で残された条件コードをアクセスする方法を探そうと誰しも思うだろう。だが、それを実装しようとすると、信頼できる方法がないことがわかった。問題は、出力オペランドは再ロードを必要とすることがあり、それにはストア命令を続ける必要が出てくる。ほとんどの機種ではこれらの命令により、値を検査する前に条件コードを変えてしまうということにある。この問題は、通常の「テスト」命令と「比較」命令では起きない。これらの命令には出力オペランドがないからである。

ANSI C のプログラムからインクルードされるヘッダファイルでは、asm の代わりに __asm__ と書くようにする。See Alternate Keywords。

i386 浮動小数点 asm オペランド

スタック状のレジスタを asm のオペランドで使うには幾つか規則がある。これらの規則は、スタック状レジスタであるオペランドにのみ適用される。

asm_operands 中で死ぬ入力レジスタの組が与えられた場合、どれが asm 文により暗黙にポップされて、どれが GCC で明示的にポップしなければならないかを知る必要がある。
asm 文により暗黙にポップされる入力kレジスタは、出力オペランドにマッチするように制約が課されていない限り、明示的に破壊しなければならない。
asm 文により暗黙にポップされる任意の入力レジスタについて、ポップした分を補償するためにスタックをどうやって調整するかを知る必要がある。ポップされない入力レジスタのどれかが、暗黙にポップされるレジスタよりもレジスタスタックの最上位に近い場合、スタックがどのように見えるかを知るのは可能ではないだろう。スタックの残りの部分がどのように「上下」するのか明らかでないのである。
暗黙にポップされる入力レジスタは全て、暗黙にポップされないどの入力レジスタよりもレジスタスタックの最上に近くなければならないのである。
ある入力が insn の中で死ぬのであれば、再ロードでその入力レジスタを出力再ロード用に使っても良い。次の例を考えてみよう。
```
asm ("foo" : "=t" (a) : "f" (b));
```
この asm 文は、入力 B が asm によりポップされないこと、asm が結果をレジスタ・スタックにプッシュする、すなわち、スタックが前より一段深くなるということを言っている。しかし、入力 B がこの insn で死ぬのであれば、再ロードは、入力と出力に同じレジスタを使うことが出来ると考えるだろう。
入力オペランドのどれかが制約 f を使っていれば、全ての出力レジスタの制約は早期破壊 & を使用しなければならない。
上の asm は以下のように書ける。
```
asm ("foo" : "=&t" (a) : "f" (b));
```
オペランドの幾つかは、スタック上の特定の位置にある必要がある。出力オペランドは全てこのカテゴリに入る。ユーザが制約で指示しない限り、どのレジスタに出力が現れるか知る方法がないのである。
出力オペランドは、asm の後で出力がどのレジスタに現れるかをはっきりと指示しなければならない。=f は許されない。このオペランド制約は一個のレジスタからなるクラスを選択しなければならない。
出力オペランドは、存在するスタックレジスタの間に「挿入」してはいけない。387 のオペコードで読み書きオペランドを使っているものはないので、全ての出力オペランドは asm_operands の前で死んでおり、asm_operands によりプッシュされる。レジスタスタックの一番上以外の場所にプッシュするのは意味がない。
出力オペランドはレジスタスタックの一番上から始まっていなければならない。出力オペランドはレジスタを「スキップ」してはいけない。
asm 文の中には、内部的な計算のためにスタックスペースを余分に必要とするものがある。これは、入力と出力に関係のないスタックレジスタを破壊することにより保証することができる。

以下に、書くのが妥当と思われる asm 文を2,3示す。次の asm 文は入力を一つ取り、この入力は内部的にポップされる。そして、出力を二つ生成する。

asm ("fsincos" : "=t" (cos), "=u" (sin) : "0" (inp));

次の asm 文は、二つの入力を取る。これらは、オペコード fyl2xp1 によりポップされ、一つの出力に置き換えられる。ユーザは、reg-stack.c が fyl2xpl が両方の入力をポップするということが判るように破壊指定 st(1) を書かなければならない。

asm ("fyl2xp1" : "=t" (result) : "0" (x), "u" (y) : "st(1)");

Node:Asm Labels, Next:Explicit Reg Vars, Previous:Extended Asm, Up:C Extensions

アセンブラコードで使用される名前の制御

C の関数や変数の、アセンブラコード中で使われる名前を指定することができる。それには、キーワード asm(または__asm__)を以下のように宣言の後に書く。

int foo asm ("myfoo") = 2;

これにより、アセンブラコードの中で、変数 foo に対して使われる名前は、通常の _foo ではなく、myfoo とすることを指定する。

C の関数や変数の名前には通常アンダースコアが頭につくシステムでは、この機能により、アンダースコアが頭につかない、リンカ用の名前を定義することが可能になる。

関数の定義では、asm を上のように使うことはできないが、以下のように、関数の宣言をその定義の前に書き、宣言の後ろに asm を書くことで同じ効果が得られる。

extern func () asm ("FUNC");

func (x, y)
     int x, y;
...

指定したアセンブラでの名前が、何か他のアセンブラシンボルとぶつからないことを保証するのはユーザの責任である。また、レジスタ名を使ってはならない。もし使うと、全く不正なアセンブラコードが生成される。GNU CC には、静的変数をレジスタにストアする能力はない。おそらく、将来その機能が追加されるだろう。

Node:Explicit Reg Vars, Next:Alternate Keywords, Previous:Asm Labels, Up:C Extensions

指定したレジスタに置かれる変数

GNU C では、2,3 のグローバル変数を指定したハードウェアレジスタに置くことができる。また、通常のレジスタ変数が割り当てられるべきレジスタを指定することもできる。

グローバルレジスタ変数はプログラム全体を通してレジスタを予約される。これは、一群のグローバル変数が頻繁にアクセスされる、プログラミング言語インタプリタのようなプログラムで有用である。
特定のレジスタに置かれる局所レジスタ変数はレジスタを予約しない。GCC のデータ流解析には、指定されたレジスタが有効な値を含んでいるかどうか、それらを他の目的に使えるどうかを決定する能力がある。局所レジスタ変数への格納は、データ流解析に従うと死んでいるようであれば、削除される可能性がある。局所レジスタ変数への参照は、削除されたり、移動されたり、単純化される可能性がある。
これらのローカル変数は、アセンブラ命令の一個の出力を特定のレジスタに直接書き込みたいときは、拡張 asm 機能(see Extended Asm)と一緒に使うと便利なことが多い。(指定したレジスタが、asm のオペランドに指定された制約に当てはまるなら、この機能は動作する。)

Global Reg Vars:
Local Reg Vars:

Node:Global Reg Vars, Next:Local Reg Vars, Previous:Explicit Reg Vars, Up:Explicit Reg Vars

グローバルレジスタ変数の定義

GNU C ではグローバルレジスタ変数を以下のように定義することができる。

register int *foo asm ("a5");

ここで a5 は、使用したいレジスタ名である。レジスタはその機種で関数呼び出しで退避／復帰されるものを選ぶようにしておくと、ライブラリルーチンで値が破壊されることがない。

当然レジスタ名は CPU に依存するので、CPU タイプに応じてプログラムを条件で分ける必要がある。a5 というレジスタは、68000 の場合はポインタ型の変数向けとしては、良い選択である。レジスタウィンドウを持つ機種の場合は、「グローバル」なレジスタを選ぶようにし、関数呼び出し機構により影響を受けないようにする必要がある。

さらに、同じ CPU タイプでもその上で動作する OS によっては、レジスタの呼び方が違う場合がある。その場合はさらに場合わけが必要になる。例えば、68000 で動作する OS の中には上記の例のレジスタを%a5 と呼ぶものもある。

将来的にはコンパイラに自動的にレジスタを選ぶように指示する手段があって良いだろうが、まず、どのようにして選択すべきか、そしてその選択を読者が知るにはどのようにしたら良いかを明らかにしなければならない。明らかな解決手段はないのである。

グローバルレジスタ変数をあるレジスタに割り当てると、少なくともコンパイル単位内では、そのレジスタはその目的にだけ使われる。現在のコンパイル単位内の関数では、他の用途にそのレジスタが割り当てられることはない。また、このコンパイル単位内の関数で退避／復帰されることもない。このレジスタへの格納は、死んでいるように見えても決して削除されないが、参照は削除されたり、移動されたり、簡素化される可能性がある。

グローバルレジスタ変数をシグナルハンドラや、一つ以上の制御スレッドからアクセスするのは安全ではない。というのは、システムのライブラリルーチンがそのレジスタを別の目的で一時的に使う可能性があるからである。(システムのライブラリルーチンをその目的のために特別にコンパイルし直せばその限りではないが。)

グローバルレジスタ変数を使っている関数が、別のやはりグローバルレジスタ変数を使っている関数 foo を、この変数についての情報無しに(例えば、この変数が宣言されていない別のソースファイルにある等) コンパイルされた三番目の関数 lose を経由して呼び出すのは危険である。これは、lose がそのレジスタをセーブした上で何か他の値を置く可能性があるからである。例えば、qsort に渡す比較関数の中でグローバルレジスタ変数を使えると思ってはいけない。qsort が、何か他のものをそのレジスタに置く可能性があるからである。(qsort を同じグローバルレジスタ変数を使うように再コンパイルすれば、この問題は解消する。)

qsort や他のソースファイルで、実際にはグローバルレジスタ変数を使っていないものを再コンパイルして、そのレジスタを他の目的には使わないようにしたければ、-ffixed-reg オプションを指定すれば充分である。実際にソースコードにグローバルレジスタの宣言を追加する必要はない。

グローバルレジスタ変数の値を変え得る関数は、この変数なしでコンパイルした関数からは安全に呼び出すことができない。呼出し側が戻り値を見つける場所にある値を書き換える可能性があるからである。このため、グローバルレジスタ変数を使っているプログラムの途中への入り口点となる関数は、呼出し側に所属する値を明示的にセーブ／リストアしなければならない。

ほとんどの機種では、longjmp は、各グローバルレジスタ変数に、それらの変数の setjmp の時点での値をリストアする。しかし、中には longjmp がグローバルレジスタ変数の値を変えない機種もある。移植性を良くするためには、setjmp を呼び出す関数は、グローバルレジスタ変数をセーブし、longjmp の中でそれらをリストアするように調整を行なわなければならない。こうしておけば、longjmp が何をするかに関わらず同じ動作が期待できる。

全てのグローバルレジスタ変数の宣言は、全ての関数定義の前になければならない。もしグローバルレジスタ変数の宣言が関数定義の後に現れても、その宣言では先行する関数でそのレジスタが別の目的で使われるのを防ぐことができない。

グローバルレジスタ変数は初期値を持つことができない。実行形式ファイルには、レジスタの初期内容を提供する方法がないからである。

SPARC では、g3 ～ g7 がグローバルレジスタに適しているとの報告がある。ただし、幾つかのライブラリ関数、例えば、getwd や、除算と剰余算のサブルーチンは g3 と g4 を修正する。g1 と g2 はローカルの一時レジスタである。

68000 では、a2 ～ a5 と d2 ～ d7 が適している。当然ながら、これらのうちの 2,3個ではなく、もっとたくさん使うのは適していない。

Node:Local Reg Vars, Previous:Global Reg Vars, Up:Explicit Reg Vars

ローカル変数にレジスタを指定するには

ローカルのレジスタ変数を、以下のようにレジスタを指定して定義することができる。

register int *foo asm ("a5");

ここで a5 は使われるべきレジスタ名である。この書き方は、グローバルレジスタ変数を定義する場合と同じだが、ローカル変数の場合は関数内に現れることに注意。

普通、レジスタ名は CPU に依存するが、これは問題ではない。特定のレジスタは明示的なアセンブラ命令で役に立つことが多いからである(see Extended Asm)。これらのどちらも一般に CPU 型に応じてプログラムを条件節で場合分けする必要がある。

さらに、一つの CPU タイプで動作するオペレーティングシステムが複数ある場合は、レジスタの指定法が違う可能性がある。例えば、幾つかの 68000 上のオペレーティングシステムでは、上記のレジスタを %a5 と読んでいる。

レジスタ変数をこのように定義しても、指定されたレジスタを予約することはない。フロー制御によりこのレジスタ変数の値が生きていないと分かった場所で、他の目的に使うことは依然として可能である。だが、これらのレジスタはリロードパスで利用できなくなる。この機能を使い過ぎると、コンパイラが関数をコンパイルするのに使えるレジスタが足りなくなってしまう。

このオプションは、このレジスタ変数が、ユーザが指定したレジスタにいつでも入るようなコードを GNU CC が生成することを保証するものではない。asm 文でこのレジスタを明示的に参照するコードを書いて、それが常にこの変数を指すと仮定してはいけない。

局所レジスタ変数への格納は、データ流解析に従うと死んでいるようであれば、削除される可能性がある。局所レジスタ変数への参照は、削除されたり、移動されたり、単純化される可能性がある。

Node:Alternate Keywords, Next:Incomplete Enums, Previous:Explicit Reg Vars, Up:C Extensions

もう一組のキーワード

-traditional オプションを指定すると、特定のキーワードをいくつか無効にする。-ansi を指定すると、その他のキーワードをいくつか無効にする。これは、GNU C の拡張や ANSI C の機能を、ANSI C のプログラムと旧来の C のプログラムを含む全てのプログラムで使えなければならない、汎用のヘッダファイルで使いたい場合に問題になる。その場合、キーワードasm、typeof、inline は -ansi でコンパイルしたプログラムでは動作しないので使えない。一方、キーワード const、volatile、signed、typeof、inline は、-traditional を指定してコンパイルしたプログラムで動作しない。

この問題を解決するには、問題となる各キーワードの頭に __ を付ければ良い。例えば、asm の代わりに __asm__ を、const の代わりに __const__ を、inline の代わりに __inline__ を使う。

他の C コンパイラはこれらの代替キーワードを受け付けないので、別のコンパイラでコンパイルした場合には、代替キーワードをマクロとして定義し、通常のキーワードに置き代わるようにすることができる。それには以下のようにする。

#ifndef __GNUC__
#define __asm__ asm
#endif

-pedantic は、GNU C の拡張の多くに警告を出す。そういう警告のうち、一つの式の中に収まっているものについては、その式の前に __extension__ を書くことで、出さないようにすることができる。__extension__ には、これ以外の効果はない。

Node:Incomplete Enums, Next:Function Names, Previous:Alternate Keywords, Up:C Extensions

不完全な `enum` 型

enum のタグを、可能な値を指定することなしに定義することが可能である。これは不完全型を生じるが、struct foo を要素を記述すること無しに書いた場合とほとんど同じような結果になる。後の宣言で、可能な値を指定すれば完全な型となる。

型が不完全である間は、その型を使って変数や記憶領域を割り当てることはできない。だが、その型へのポインタを使うことは可能である。

この拡張はそれほど役に立つわけではないが、enum の取扱いが、struct や union の取扱いとより一貫性を保てるようになる。

この拡張は GNU C++ ではサポートされない。

Node:Function Names, Next:Return Address, Previous:Incomplete Enums, Up:C Extensions

文字列としての関数名

GNU CC は、現在の関数名を表す文字列変数を二つ前もって定義している。変数 __FUNCTION__ は、ソースコードに現れた通りの関数名を表す。変数 __PRETTY_FUNCTION__ は、言語に固有の形式で整形した関数名を表す。

この二つは、C 言語の関数ではいつでも同じになるが、C++ の関数では違ったものになる可能性がある。例えば、

extern "C" {
extern int printf (char *, ...);
}

class a {
 public:
  sub (int i)
    {
      printf ("__FUNCTION__ = %s\n", __FUNCTION__);
      printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__);
    }
};

int
main (void)
{
  a ax;
  ax.sub (0);
  return 0;
}

というプログラムの出力は以下のようになる。

__FUNCTION__ = sub
__PRETTY_FUNCTION__ = int  a::sub (int)

この二つの名前はマクロではなくて、定義済の文字列変数である。例えば、関数の中で #ifdef __FUNCTION__ としても何も特別な意味は持たない。プリプロセッサは __FUNCTION__ という識別子について何も特別な処理を行なわないからである。

Node:Return Address, Next:Other Builtins, Previous:Function Names, Up:C Extensions

関数の戻りアドレスやフレームアドレスを得るには

以下の関数を使って、関数の呼び出し元についての情報を得ることができる。

__builtin_return_address (level)

この関数は、現在の関数か、あるいはその呼び出し元関数のどれか一つの戻りアドレスを返す。引数 level は、呼び出しスタックを走査すべきフレーム数である。この値が 0 であれば、現在の関数の戻りアドレスを返す。この値が 1 であれば、現在の関数の呼び出し元の戻りを返す。以下同様。

引数 level は整数定数でなければならない。

機種によっては、現在の関数以外の関数の戻りアドレスを決定することが不可能な場合がある。そういう場合や、スタックの頂点に達したときは、この関数は 0 を返す。

この関数は、ゼロ以外の引数をつけてデバッグ用にのみ使うべきである。

__builtin_frame_address (level)

この関数は __builtin_return_address に似ているが、関数の戻りアドレスではなく、関数フレームのアドレスを返す。__builtin_frame_address を引数値を 0 として呼び出すと、現在の関数のフレームアドレスを返す。1 を引数値とすると、現在の関数の呼び出し元関数のフレームアドレスを返す。以下同様。

フレームは、ローカル変数やセーブされたレジスタを保持するスタック上の領域である。フレームアドレスは、普通は、その関数によりスタックにプッシュされた先頭のワードのアドレスになる。しかし、厳密な定義は、プロセッサと呼び出し規約に依存する。プロセッサにフレームポインタ専用レジスタがあれば、関数はフレームを一個持ち、__builtin_frame_address は、そのフレームポインタレジスタの値を返す。

__builtin_return_address についての注意が、この関数についても同様に当てはまる。

Node:Other Builtins, Next:Deprecated Features, Previous:Return Address, Up:C Extensions

GNU CC が提供するその他の組み込み関数

GNU CC はこれまでに述べた以外にもたくさんの組み込み関数を提供している。その中の幾つかは内部で使う目的のものがあり、例外や可変長引数リストの処理に使われる。これらについては、ここでは説明しない。頻繁に変更が行われるからである。これらの関数を一般的な目的で使用するのはお勧めしない。

その他の関数は、最適化目的で提供されている。

GNU CC には、標準 C ライブラリにある多くの関数の組み込み版が含まれている。これらは常に、例え -fno-builtin オプション(see C Dialect Options)を指定した場合でも、C ライブラリの関数と同じ意味を持つものとして取り扱われる。これらの関数は、C ライブラリ関数の alloca、ffs、abs、fabsf、fabs、fabsl、labs、memcpy、memcmp、strcmp、strcpy、strlen、sqrtf、sqrt、sqrtl、sinf、sin、sinl、cosf、cos、cosl に対応する。

組み込み関数 __builtin_constant_p を使うと、ある値がコンパイル時に定数であったかどうかを知ることができ、そのため、GNU CC がその値を含む式について定数畳み込みが実行できるかを知ることができる。この関数の引数がテストすべき値になる。この関数は、引数がコンパイル時定数であることがわかっていた場合には整数 1 を返し、コンパイル時定数であったことがわからない場合には整数 0 を返す。0 が返ってきても、その値が定数でなかったということを意味するものではない。単に GNU CC が、-O オプションで指定された値では、定数であることが証明できなかっただけである。

この関数が使われる代表的な場合は、メモリが重要なリソースになる組み込みアプリケーションであろう。何か複雑な形算式があって、それが定数を含んでいれば定数畳み込みを行って欲しいだろうが、定数を含まない場合は関数を呼び出す必要がある。例えば、以下のような場合である。

#define Scale_Value(X)  \
  (__builtin_constant_p (X) ? ((X) * SCALE + OFFSET) : Scale (X))

この組み込み関数は、マクロやインライン展開関数で使っても良い。ただし、インライン展開関数の中で使って、その関数に対する引数を組み込み関数への引数として渡した場合、そのインライン関数の引数に文字列定数やコンストラクタ式(see Constructors)を指定して呼び出した場合は決して 1 を返さない。また、-O オプションを指定しない限り、インライン関数に数値定数を渡したときは 1 を返さない。

Node:Deprecated Features, Previous:Other Builtins, Up:C Extensions

消えた機能

過去において、GNU C++ コンパイラは新しい機能を実験するために拡張がなされた。当時は C++ 言語が進化途上だったのである。現在では、C++ 規格が完成したので、これらの幾つかの機能は依り良い別の機能で置き換えられている。古い機能を使うと、その機能が将来削除されるいくつかの場合に警告が発せられる。その他の場合には、機能は既に削除されている。

以下のリストは全てを網羅していないが、現在では廃止要求が出ている幾つかのオプションについて説明する。

-fthis-is-variable: C++ の初期のバージョンでは、this への代入を、アプリケーション定義のメモリ割当を実装するのに使うことができた。現在では、割当関数(operator new)が、同じ効果を得るための規格に適った方法になっている。
-fexternal-templates
-falt-external-templates: これらは、g++ でテンプレートの実体化を実装するためのたくさんの方法のうちの二つである。See Template Instantiation。C++ 規格は、実装単位を越えてテンプレート定義がどのように組織されなければならないかをはっきりと定義している。g++ には、規格に適ったコードとうまく動作する暗黙の実体化機構がある。

Node:C++ Extensions, Next:Gcov, Previous:C Extensions, Up:Top

Introduction

C, C++, Objective C, Fortran のコンパイル

GCC コマンド行オプション

オプション要約

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

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

C 方言を扱うオプション

C++ 方言を扱うオプション

警告を要求／抑止するオプション

読者のプログラムや GCC をデバッグするためのオプション

最適化オプション

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

アセンブラに渡されるオプション

リンクオプション

ディレクトリ検索用オプション

ターゲット機種とコンパイラバージョンの指定

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

M680x0 オプション

VAX オプション

SPARC オプション

Convex オプション

AMD29K オプション

ARM オプション

Thumb オプション

MN10200 オプション

MN10300 オプション

M32R/D オプション

M88K オプション

IBM RS/6000 と PowerPC オプション

IBM RT オプション

MIPS オプション

Intel 386 オプション

HPPA オプション

Intel 960 オプション

DEC Alpha オプション

Clipper オプション

H8/300 オプション

SH オプション

System V 向けオプション

TMS320C3x/C4x オプション

V850 オプション

ARC オプション

NS32K オプション

コード生成規約についてのオプション

GCC に影響する環境変数

protoize の実行

GNU CC のインストール

configure が作り出すファイル達

GNU CC でサポートしているコンフィギュレーション

別ディレクトリでのコンパイル方法

クロスコンパイラの構築とインストールの方法

クロスコンパイルのステップ

クロスコンパイラのコンフィギュレーション

クロスコンパイラ用のツールとライブラリ

libgcc.a とクロスコンパイラ

クロスコンパイラとヘッダファイル

クロスコンパイラ構築の実際

GNU CC を Sun にインストール

GNU CC を VMS にインストール

collect2

標準ヘッダファイルのディレクトリ

C 言語に対する拡張

式中の文と宣言

局所的に宣言されたラベル

ラベルの値

入れ子関数

関数呼び出しの構築

式の型に名前を与える

typeof による型の参照

拡張左辺値

三項演算子のオペランドの省略

倍語整数

複素数

16進浮動小数

大きさゼロの配列

可変長配列

改変数引数を持つマクロ

左辺値でない配列の添え字を取ることが可能

voidポインタと関数へのポインタに対する演算

非定数による初期化

`configure` が作り出すファイル達

`libgcc.a` とクロスコンパイラ

`collect2`

`typeof` による型の参照

`void`ポインタと関数へのポインタに対する演算

不完全な `enum` 型