マニュアルページ cc.1
名前
cc - C コンパイラ
形式
cc [-#] [-###] [-A<名前>[(<トークン>)]]
[-B[static|dynamic]] [-C] [-c] [-D<名前>[=<トークン>]]
[-d[y|n]] [-dalign] [-E] [-errfmt[=[no%]error]]
[-erroff[=t[,t...]]] [-errshort[=i]] [-errtags=a]
[-errwarn[=t[,t...]]] [-fast] [-fd]
[-features=[[no%]extinl|%none]] [-flags]
[-flteval[={any|2}]] [-fnonstd] [-fns=[no|yes]]
[-fprecision=p] [-fround=r] [-fsimple[=n]] [-fsingle]
[-fstore] [-ftrap[=t[,t...]]] [-G] [-g] [-H] [-h<名前
>] [-I[-|<ディレクトリ>]] [-i] [-KPIC] [-Kpic]
[-keeptmp] [-L<ディレクトリ>] [-l<名前>] [-mc]
[-misalign] [-misalign2] [-mr[,<文字列>]] [-mt]
[-native] [-nofstore] [-O] [-ofilename] [-P] [-p]
[-Q[y|n]] [-qp] [-R<ディレクトリ>[:<ディレクトリ>...]]
[-S] [-s] [-U<名前>] [-V] [-v] [-Wc,<引数>] [-w]
[-X[c|a|t|s]] [-x386] [-x486] [-xa] [-xalias_level[=a]]
[-xarch=a] [-xautopar] [-xbuiltin[=a]] [-xCC]
[-xc99[=o]] [-xcache=c] [-xcg89] [-xcg92] [-xchar[=o]]
[-xchar_byte_order[=o]] [-xcheck=n] [-xchip=c]
[-xcode=v] [-xcrossfile[=n]] [-xcsi]
[-xdebugformat=[stabs|dwarf]] [-xdepend[={yes|no}]]
[-xdryrun] [-xe] [-xexplicitpar] [-xF] [-xhelp=f]
[-xhwcprof=[enable|disable]]
[-xildoff] [-xildon] [-xinline=[v[,v...]]] [-xipo[=a]]
[-xipo_archive[=a]] [-xjobs=n] [-xldscope={v}]
[-xlibmieee] [-xlibmil] [-xlibmopt] [-xlic_lib=sunperf]
[-xlicinfo] [-xlinkopt[=level]] [-xloopinfo] [-xM]
[-xM1] [-xMerge] [-xmaxopt[=v]] [-xmemalign=ab]
[-xnativeconnect[=a[,a]...]] [-xnolib] [-xnolibmil]
[-xnolibmopt] [-xOn] [-xopenmp[=i]] [-xP]
[-xpagesize=n] [-xpagesize_heap=n] [-xpagesize_stack=n]
[-xparallel] [-xpch=v] [-xpchstop] [-xpentium] [-xpg]
[-xprefetch[=val[,val]]] [-xprefetch_auto_type=[a]
[-xprefetch_level=l] [-xprofile=p]
[-xprofile_ircache[=path]]
[-xprofile_pathmap=collect_prefix:use_prefix]
[-xreduction] [-xregs=r[,r...]] [-xrestrict[=f]] [-xs]
[-xsafe=mem] [-xsb] [-xsbfast] [-xsfpconst] [-xspace]
[-xstrconst] [-xtarget=t] [-xtemp=<ディレクトリ>]
[-xthreadvar[=o] [-xtime] [-xtransition]
[-xtrigraphs[=[yes|no]] [-xunroll=n]
[-xustr={ascii_utf16_ushort|no}] [-xvector[={yes|no}]]
[-xvis] [-xvpara] [-Yc,<ディレクトリ>] [-YA,<ディレクト
リ>] [-YI,<ディレクトリ>] [-YP,<ディレクトリ>] [-YS,<
ディレクトリ>] [-Zll]
DESCRIPTION
Sun Studio 9 C コンパイラ。
マニュアルページは、クイックリファレンスです。C コンパイラと
そのオプションの詳細については、『C ユーザーズガイド』を参照
してください。
プラットフォーム、環境、新機能、およびソフトウェア修正に関す
る最新の重要情報については、オンラインの readme
ファイルを参照してください。このファイルは、
cc -xhelp=readme
を実行して表示できます。
すべてのマニュアルの一覧は、このマニュアルページの最後にあり
ます。
README ファイル、ユーザーズガイド、リファレンスマニュアルを
含むすべてのインストール済みマニュアルには、HTML ブラウザで
file:/opt/SUNWspro/docs/ja/index.html
を指定してアクセスできます (デフォルトのインストールディレク
トリの場合)。
注- Sun コンパイラおよびツールのインストールディレクトリが、
デフォルトの /opt ディレクトリでない場合は、ご使用のシステム
の実際のパスを、システム管理者に確認してください。
新しいオプション、フラグ、およびデフォルト
このリリースの C コンパイラでは以下の改良が行われています。
o -xarch、-xcode、-xmemalign、および
-xprefetch オプションのデフォルトを変更し、-fast および -O
オプションの展開を変更することによるパフォーマンスの向上
o Intel アーキテクチャ向けの -xarch、-xtarget、および -xchip
のフラグを追加(下記の個々のオプションの説明も参照)
o -xlibmopt、-xnolibmopt、-xipo_archive、および
-xprefetch_auto_type オプションによる実行時パフォーマンスの
向上
o -xpch でのプリコンパイル済みヘッダーファイルの自動生成によ
るコンパイル時パフォーマンスの向上
o -xchip および -xtarget のフラグ追加による SPARC のサポート
を拡張
o extern インライン関数、指示付きの初期化子、汎用文字名な
ど、Solaris 10 上での 1999 C ISO 機能の完全サポート
o lint ユーティリティのセキュリティ検査機能の追加 (詳細は
lint(1) のマニュアルページを参照)
Intel 向けの新しいフラグ
コンパイラが、-xarch、-xtarget、および -xchip の Intel 向け
フラグを新しくサポートするようになりました。これらの新しいフ
ラグは、Intel プラットフォーム上での Solaris ソフトウェアに
よる SSE および SSE2 命令のサポートとの組み合わせで Pentium
3 および Pentium 4 チップを活用することを意図しています。新
しいフラグは次のとおりです。
-xchip=pentium3: Pentium 3 方式のプロセッサ用に最適化し
ます。
-xchip=pentium4: Pentium 4 方式のプロセッサ用に最適化し
ます。
-xtarget=pentium3: -xarch=sse、-xchip=pentium3、および
-xcache=16/32/4:256/32/4 に設定します。
-xtarget=pentium4: -xarch=sse2、-xchip=pentium4、および
-xcache=8/64/4:256/128/8 に設定します。
-xarch=sse: pentium_pro 命令セットに SSE 命令セットを追
加します。
-xarch=sse2: SSE が認める命令セットに SSE2 命令セットを
追加します。
注意:
Solaris x86 SSE/SSE2 Pentium 4 互換プラットフォームで動
作するよう -xarch={sse| sse2} を使ってコンパイルしたプ
ログラムは、SSE/SSE2 対応のプラットフォームでのみ実行す
る必要があります。SSE/SSE2 に対応していないプラット
フォームでそうしたプログラムを実行すると、セグメント例
外が発生したり、明示的な警告メッセージなしに不正な結果
が発生したりすることがあります。
SSE/SSE2 でコンパイルされたバイナリが SSE/SSE2 に対応し
ていないプラットフォームで実行されないようにするための
OS およびコンパイラに対するパッチが、後日提供される可能
性があります。
Pentium 4 互換プラットフォームの場合、Solaris 9 update
6 以降の OS リリースが SSE/SSE2 に対応しています。これ
より前のバージョンの Solaris OS は
SSE/SSE2 に対応していません。このことは、.il インライ
ンアセンブリ言語関数を使用しているプログラムや、
SSE/SSE2 命令を利用している __asm() アセンブラコードに
も当てはまります。
コンパイルとリンクを別々に行う場合は、必ずコンパイラを
使ってリンクし、-xarch={sse| sse2} で適切な起動ルーチン
がリンクされるようにしてください。
実際のニーズに合った適切な -xarch、-xchip、および -xtarget
のフラグの組み合わせを決定するにあたっては、次の指針に従って
ください。
* Solaris 9 update 6 か、それ以前の Solaris を実行する Pen-
tium 3 または Pentium 4 で構築を行い、-fast、-xarch=native、
または -xtarget=native を指定するかどうか。
この場合、コンパイラは次のように展開します。
o Solaris 9 update 5 またはそれ以前の Solaris オペレー
ティングシステムは、SSE および SSE2 命令をサポートしな
いため、-xarch は pentium_pro に設定されます (pentium3
あるいは pentium4 ではありません)。
注: これらのバージョンの Solaris ソフトウェアを使用して
いるかどうかに関係なく、-xarch=sse あるいは -xarch=sse2
を指定することができますが、Solaris 9 update 6 以降の
OS リリースは SSE および SSE2 命令をサポートしているた
め、構築で生成された実行可能ファイルは、そうしたバー
ジョンの Solaris ソフトウェアが動作しているマシンで実行
する必要があります。
o -xchip は、適宜 pentium3 または pentium4 に設定されま
す。
o -xcache は、Pentium 3 プロセッサの場合
16/32/4:256/32/4、Pentium 4 プロセッサの場合
8/64/4:256/128/8 に設定されます。
* Solaris 9 update 6 以降の Solaris を実行する Pentium 3 ま
たは Pentium 4 で構築を行い、-fast、-xarch=native、または
-xtarget=native を指定するかどうか。
この場合、コンパイラは次のように展開します。
o xarch は、Pentium 3 の場合 sse、Pentium 4 の場合 sse2
に設定されます。
o -xchip は、適宜 pentium3 または pentium4 に設定されま
す。
o -xcache は、Pentium 3 プロセッサの場合
16/32/4:256/32/4、Pentium 4 プロセッサの場合
8/64/4:256/128/8 に設定されます。
詳細は、このマニュアルページのそれぞれのオプションの説明を参
照してください。
C コンパイラの概要
この cc (1) のマニュアルページは、Solaris 8、Solaris 9、およ
び Solaris 10 のオペレーティング環境における SVID に準拠した
ISO C コンパイラオプションについて説明しています。C コンパイ
ラは、デフォルトで 1999 ISO/IEC C 標準の構造を一部認識するこ
とに注意してください。サポートされる構造については『C ユー
ザーズガイド』に詳細な説明があります。コンパイラを 1990
ISO/IEC C 標準に限定したい場合は、 -xc99=none コマンドを使用
してください。
cc は getopt を使用してコマンド行オプションを構文解析しま
す。オプションは 1 文字、または引数を伴う 1 文字として扱われ
ます。詳細は getopt(3C) を参照してください。
cc は、C コンパイルシステムとのインタフェースです。コンパイ
ル処理には、プリプロセッサ、コンパイラ、コードジェネレータ、
オプティマイザ、アセンブラ、リンカーが含まれます。cc は指定
されたオプションを処理し、適切な引数を使って各種の構成要素を
実行します。cc は引数としていくつかの種類のファイルを受け付
けます。
接尾辞 .c が付いているファイルは C のソースファイルと見なさ
れ、前処理、コンパイル、最適化、プロファイリングのための準
備、アセンブル、リンクを行うことができます。前処理はマクロプ
ロセッサとして使用できますが、その出力は C コンパイラへの入
力となることを目的としているため、お勧めできません。適切なオ
プションを指定した場合、コンパイル処理は任意の段階が完了した
時点で停止できます。
コンパイル処理でアセンブラの段階まで終了すると、ソースファイ
ルの名前の .c を .o に置き換えたオブジェクトファイルが、現在
の作業ディレクトリに生成されます。しかし、1 つの C ファイル
をコンパイルしてすぐにリンクした場合、通常、接尾辞 .o の付い
たファイルは削除されます。
名前が .s で終わるファイルはアセンブリソースファイルと見なさ
れ、アセンブルとリンクが行われます。
.S という接尾辞の付いたファイルは、コンパイラの -Xs モード
として扱われ、まず /usr/ccs/lib/cpp に渡されて前処理を行なっ
てから、アセンブラに渡されます。
名前が .i で終わるファイルは前処理済みの C ソースファイルと
見なされ、コンパイル、最適化、プロファイリングのための準備、
アセンブル、リンクを行うことができます。名前の末尾が .c、
.s、.S、.i のいずれでもないファイルは、リンカーに渡され、動
的にリンクされた実行可能ファイルが生成されます。この実行ファ
イルの名前は、デフォルトでは a.out になります。
インクリメンタルリンクを行う場合は、リンカーld の代わりにイ
ンクリメンタルリンカー(ild) が使用されます。詳細は、-xildon
および -xildoff を参照してください。
ライブラリの検索に使用するデフォルトディレクトリを変更する場
合は、 -Yc, <ディレクトリ> オプションを参照してください。<
ディレクトリ> には、1 つ以上のパスをコロンで区切って指定しま
す。デフォルトでは、cc は次の順序でライブラリを検索します。
/opt/SUNWspro/prod/lib
/usr/ccs/lib
/usr/lib
64 ビット Solaris 用のコンパイル
このバージョンのコンパイラでは、32 ビットまたは 64 ビット
Solaris SPARC 版で 64 ビットオブジェクトを生成できます。生成
された実行可能ファイルは、64 ビットカーネルを持つ Solaris ソ
フトウェアの 64 ビットプロセッサ上でのみ動作します。
いくつかの形式の -xarch=v9 オプションを使って、64 ビット
Solaris 向けのコンパイルができます。 -xtarget または -fast
を指定した場合でも、これらのオプションのいずれか 1 つを指定
する必要があります。その場合、-xarch=v9 オプションは、-xtar-
get またはその他、 -xarch を設定するオプションの後に指定する
必要があります。たとえば、次のように指定します。
-xtarget=ultra -xarch=v9
64 ビットの Solaris オペレーティング環境で -xarch=v9 を付け
て共有動的ライブラリを構築する場合、デフォルトの
-xcode=abs44 は機能しないため、-xcode= を指定する必要があり
ます。-xcode=pic13 か -xcode=pic32 のいずれかを使用してくだ
さい。
コードアドレスサイズの指定方法は、-xcode オプションの説明を
参照してください。
64 ビット Solaris ソフトウェアは、64 ビットの整数やポインタ
のデータを有効にするだけではなく、大規模ファイルもサポートし
ます。
64 ビット Solaris ソフトウェアに関する開発者向けの情報につい
ては、http://docs.sun.com にある『Solaris 64 ビット開発ガイ
ド』を参照してください。
C プログラムの 64 ビット環境への移行に関する具体的な情報につ
いては、『C ユーザーズガイド』を参照してください。
オプション
プラットフォーム固有のオプションは、どのプラットフォームでも
受け付けられ、エラーとしては処理されません。この規則の例外に
ついては、各オプションの項で説明しています。
cc では、以下のオプションが解釈されます。
-# 冗長モードでコマンドオプションの展開方法を表示します。
呼び出された各構成要素を表示します。
-### 呼び出された各構成要素を表示しますが、各要素を実際には
実行しません。コマンドオプションの展開方法も表示しま
す。
-A<名前>[(<トークン>)]
プリプロセッサ(前処理系)指令 #assert を実行するのと同じ
ように、<名前> を述語として、指定した <トークン> に対応
付けます。
Preassertions:system(unix)
machine(sparc) (SPARC)
machine(i386) (x86)
cpu(sparc) (SPARC)
cpu(i386) (x86)
これらは、 -Xc モードでは事前定義されません。
If -A の後にハイフン (-) しかない場合、事前定義されてい
るマクロ ( __ で始まるものを除く) と事前表明はすべて無
視されます。
-B [static|dynamic]
ライブラリのリンクを静的または動的のいずれかに指定しま
す。静的リンクでは非共有形式のライブラリ、動的リンクで
は共有形式のライブラリになります。 -Bdynamic を指定する
と、-lx オプションが同時に指定されている場合にリンカー
は libx.so という名前のファイルを検索し、次に libx.a と
いう名前のファイルを検索します。 -Bstatic を指定する
と、リンカーは libx.a という名前だけを検索します。この
オプションをコマンド行で 2 回以上指定すると、トグル (設
定の切り替え) として機能します。
注: Solaris の 64 ビットコンパイル環境では、多くのシス
テムライブラリ (libc など) は、動的ライブラリのみ使用で
きます。このため、コマンド行の最後で -Bstatic を使わな
いでください。
このオプションと引数は ld に渡されます。
-C C プリプロセッサは、プリプロセッサ指令行のコメント以外
は、コメントを削除しません。
-c C コンパイラに、ld によるリンクを抑止して、ソースファイ
ルごとにこの -o オプションを使用すると、単一のオブジェ
クトファイルに明示的に名前を付けることができます。各 .i
または .c 入力ファイルについてコンパイラがオブジェクト
コードを作成する場合、コンパイラは常に現在の作業用ディ
レクトリにオブジェクトファイルを作成します。リンクを行
わない場合、オブジェクトファイルの削除も行われません。
-D<名前>[=<トークン>]
プリプロセッサ指令 #define を実行するのと同じように、<
名前> を指定した <トークン> に対応づけます。<トークン>
が指定されない場合は、トークン 1 を使用します。
Predefinitions:unix
sparc (SPARC)
i386 (x86)
sun
これらは、-Xc モードでは事前定義されません。
以下の事前定義は、すべてのモードで有効です。
__sun
__unix
__SUNPRO_C=0x560
__`uname -s`_`uname -r`
__sparc (SPARC)
__sparcv9 (SPARC with -xarch=v9|v9a|v9b)
__i386 (x86)
__BUILTIN_VA_ARG_INCR
__SVR4
以下の事前定義は、-Xa および -Xt モードでのみ有効です。
__RESTRICT
コンパイラはオブジェクト形式のマクロ
__PRAGMA_REDEFINE_EXTNAME,
を事前定義して、プラグマを認識できるようにします。
-d[y|n]
-dy は、リンカーに対して動的リンクを指定します (デフォ
ルト)。 -dn は、リンカーに対して静的リンクを指定しま
す。
このオプションと引数は ld に渡されます。
注: 動的ライブラリとこのオプションを組み合わせると、致
命的なエラーが発生します。大部分のシステムライブラリ
は、動的ライブラリとしてのみ使用できます。
-dalign
(SPARC のみ) 旧式。このオプションは使わないでください。
代わりに -xmemalign=8s を使ってください。『C ユーザーズ
ガイド』に、旧式のオプションおよびフラグの全一覧が掲載
されています。
-E ソースファイルの前処理だけを行い、結果を stdout に出力
します。プリプロセッサはコンパイラ内部に直接組み込まれ
ます (/usr/ccs/lib/cpp が直接呼び出される -Xs モードの
場合を除きます)。プリプロセッサの行番号付け情報も含みま
す。 -P オプションも参照してください。
-errfmt[=[no%]error]
エラーメッセージのはじめに文字列「エラー:」を接頭辞とし
て付け加え、警告メッセージと明確に区別できるようにする
には、このオプションを使用します。この接頭辞は、
-errwarn によりエラーに変換される警告にも付け加えられま
す。
error すべてのエラーメッセージに接頭辞「エラー:」を
付けます。
no%error エラーメッセージに接頭辞「エラー:」を付けませ
ん。
このオプションを使用しないと、コンパイラはオプションを
-errfmt=no%error に設定します。-errfmt を使用して、値を
指定しない場合、コンパイラにより -errfmt=error に設定さ
れます。
-erroff[=t[,t...] ]
cc 警告メッセージを抑制します。エラーメッセージには影響
しません。
-erroff 値は、次の 1 つ以上からなるコンマ区切りのリスト
です。
tag tag のリストに指定されている警告メッセージを抑
制します。 -errtags=yes オプションを使用すれば
メッセージのタグを表示できます。
no%tag tagのリストに指定されている警告メッセージを抑
制します。
%all すべての警告メッセージを抑制します。
%none 警告メッセージを何も抑制しません。デフォルトは
この設定です。
指定の順序は重要です。たとえば、 %all,no%tag によって
tag を除く、すべての警告メッセージが抑制されます。
デフォルトは、 -erroff=%none です。 -erroff と指定する
のは、 -erroff=%all と指定した場合と同等です。
-erroff オプションにより抑制できるのは、-errtags オプ
ションが使用されるとタグを表示する、C コンパイラフロン
トエンドからの警告メッセージだけです。エラーメッセージ
の抑制をより細かく制御するには、#pragma error_messages
を使用します。
-errshort[=i]
型の不一致が検出されたとき、コンパイラがエラーメッセー
ジにどれだけ多くの詳細を生成するかを制御するには、この
オプションを使用します。このオプションは、コンパイラに
よって大規模な集合に関する型の不一致が検出されたときに
特に便利です。
i には以下のいずれかの値を指定できます。
short エラーメッセージは、型の展開なしで短形式で出力
されます。集合メンバーは展開されず、関数の引数
も戻りの型も展開されません。
full エラーメッセージは、完全冗長形式で出力され、不
一致型の完全展開が表示されます。
tags エラーメッセージは、タグ名を持つ型についてはタ
グ名付きで出力されます。タグ名がない場合、型は
拡張形式で出力されます。
-errshort を使用しない場合、コンパイラがこのオプション
を -errshort=full に設定します。-errshort を指定して、
値を指定しないと、コンパイラによりオプションは
-errshort=tags に設定されます。
このオプションは累積されず、コマンド行に指定された最後
の値を受け入れます。
-errtags=a
-erroff オプションにより抑制されるか、または -errwarn
オプションによって致命的エラーとなる、C コンパイラフロ
ントエンドからの各警告メッセージのメッセージタグを表示
します。C コンパイラドライブや
C コンパイルシステムのその他の構成要素からのメッセージ
にはエラータグはなく、 -erroff により抑制されたり、
-errwarn により致命的エラーとなることはありません。
a には yes または no のいずれかを指定します。デフォルト
は -errtags=no です。 -errtags だけを指定すると、
-errtags=yes を指定した場合と同じ結果になります。
-errwarn[=t[,t...] ]
指定された警告メッセージに対して、エラーステータスを返
して C コンパイラを終了させるには、-errwarn オプション
を使用します。
t はコンマで区切ったリストで、tag、no%tag、%all、%none
の 1 つまたは複数から構成されます。リストの順序は重要で
す。たとえば、%all,no%tag と指定すると、C コンパイラは
タグを除くどのような警告が発行されても致命的エラース
テータスを返して終了します。
C コンパイラにより生成される警告メッセージは、コンパイ
ルエラーチェックの改善や機能の追加のため、リリースごと
に異なります。-errwarn=%all を使用してコンパイル時にエ
ラーを返さないコードが、次のコンパイラリリースではコン
パイル時にエラーを返すようになる可能性があります。
-errwarn オプションを使用して C コンパイラをエラース
テータスを出して終了させるように指定できるのは、
-errtags オプションが使用されるとタグを表示する、C コン
パイラフロントエンドからの警告メッセージだけです。
デフォルトは -errwarn=%none です。-errwarn だけを指定す
ると、 -errwarn=%all を指定した場合と同じ結果になりま
す。
以下の表に -errwarn 値の詳細を示します。
tag tag で指定したメッセージが警告メッセージとして
発行されると、 cc は致命的エラーステータスを返
して終了します。tag が発行されない場合は影響し
ません。
no%tag tag で指定したメッセージが警告メッセージとして
だけ発行された場合に cc が致命的エラーステータ
スを返して終了することを防ぎます。tag が発行さ
れない場合は影響しません。このオプションを使用
すると、オプションは、tag または %all を使用し
て以前に指定したメッセージが警告メッセージとし
て発行されても、 cc は致命的エラーステータスを
返して終了しません。
%all どのような警告メッセージが発行されても、 cc は
致命的エラーステータスを返して終了します。%all
の後に no%tag を指定すると、特定の警告メッセー
ジだけをこの動作から除外できます。
%none どのような警告メッセージが発行されても、 cc は
致命的エラーステータスを返して終了することはあ
りません。これはデフォルトです。
-fast
このオプションは、最高の実行時性能が得られるように実行
可能ファイルをチューニングするための最初の手段として効
果的に利用できるマクロです。-fast の展開内容はコンパイ
ラのリリースのたびに変更される可能性があり、ターゲット
のプラットフォーム固有のオプションに展開されます。実行
可能ファイルのチューニング過程で、-# または -xdryrun オ
プションを使って -fast の展開内容を確認し、-fast の適切
なオプションを反映させることを推奨します。
-fast オプションの展開内容に -xlibmopt オプションが新し
く含まれるようになっています。このオプションは、コンパ
イラが最適化された数学ルーチンを使用することを可能にし
ます。詳細は、このマニュアルページの -xlibmopt の説明を
参照してください。
-fast オプションは、errno の値に影響します。詳細は、こ
のマニュアルページの最後の注を参照してください。
-fast を付けてコンパイルするモジュールはまた、-fast を
付けてリンクする必要があります。コンパイル時およびリン
ク時両方に指定する必要があるコンパイラオプションの全一
覧は、『C ユーザーズガイド』を参照してください。
-fast オプションは、コンパイルを行なったマシンとは異な
るマシン上で実行する予定のプログラムには適していませ
ん。このような場合は、次の例のように、 -fast の後に適切
な -xtarget -xtarget オプションを指定します。
% cc -fast -xtarget=ultra
SUID で指定された例外処理に依存する C モジュールの場
合、-fast の後に -xnolibmil を指定します。
% cc -fast -xnolibmil
-fast オプションはコマンド行でマクロ展開のように動作し
ます。そのため、-fast の後に必要なオプションを指定すれ
ば、展開されたオプションの設定を変更できます。
-fast を他のオプションと組み合わせた場合は、最後の指定
が適用されます。
次のオプションは、 -fast に対して有効になります。
-fns
-fsimple=2
-fsingle
-ftrap=%none
-nofstore (x86)
-xalias_level=basic (SPARC)
-xbuiltin=%all
-xdepend
-xlibmil
-xlibmopt
-xmemalign=8s (SPARC)
-xO5
-xprefetch=auto,explicit (SPARC)
-xtarget=native
注: 最適化の中には、プログラムの動作を仮定しているもの
もあります。プログラムがこれらの仮定に一致しない場合、
アプリケーションがクラッシュしたり、誤った結果となる可
能性があります。プログラムが -fast を使用したコンパイル
に適しているか否かを判断するには、個々のオプションの説
明を参照してください。
このオプションは、IEEE に準拠した例外処理に依存するプロ
グラムには使用しないでください。数値結果が異なったり、
プログラムが途中で終了したり、予想外の SIGFPE シグナル
が発生する可能性があります。
-fd K&R の関数宣言と定義を報告します。
-features=[[no%]extinl|%none]
extern インライン関数のコンパイラの処理は、デフォルトで
は、ISO/IEC 9899:1999 C 規格に規定されている動作に準拠
しています。バージョン 5.5 またはそれ以前の C および
C++ コンパイラで提供されているのと同じ extern インライ
ン関数の処理を得るには、 -features=no%extinl を付けて新
しいコードをコンパイルしてください。
-features の値が指定されていない場合、-features=extinl
に設定されます。
古い C および C++ バイナリ (C/C++ 5.6 より前) は、その
オブジェクトの動作を変更することなく、新しい C および
C++ バイナリとリンクできます。規格に準拠した動作を実現
するには、最新のコンパイラを使って、古いコードを再コン
パイルする必要があります。
-features=extinl
extern インライン関数を大域関数として生成しま
す。これがデフォルトで、1999 C 規格に準拠して
います。
-features=no%extinl
extern インライン関数を静的関数として生成しま
す。
-features=%none
このオプションを無効にします。
-flags
利用可能なオプションについて 1 行にまとめて表示します。
-flteval[={any|2}]
(Intel のみ) このオプションは、浮動小数点式の評価方法の
制御に使用します。
2 浮動小数点式を long double として評価します。
any 式を構成している変数および定数の型の組み合わせ
に基づいて浮動小数点式を評価します。
-flteval が指定されなかった場合は、-flteval=any に設定
されます。 -flteval が指定されているが、値がない場合
は、 -flteval=2 に設定されます。
f3-flteval=2 と次のオプションを組み合わせてはいけませ
ん。 -flteval=2:
o -fprecision
o -nofstore
o -xarch=sse2
詳細は、『C ユーザーズガイド』の付録 D の「Precision of
Floating Point Evaluators」を参照してください。
-fnonstd
-fnonstd は、-fns および -ftrap=common と同義のマクロで
す。
-fns [=[no|yes]]
SPARC 非標準の浮動小数点モードを選択します。デフォルト
の -fns=no は、SPARC の標準浮動小数点モードです。
オプションの =yes または =no を使用すると、他のマクロフ
ラグ (-fns も含む) に続く -fns フラグを切り替えることが
できます (-fast など)。
-fns は -fns=yes と同義です。
-fns=yes は非標準の浮動小数点を選択します。
-fns=no は標準の浮動小数点を選択します。
一部の SPARC システムでは、非標準の浮動小数点モードは
「段階的アンダーフロー」を無効にします。つまり、小さな
演算結果は、非正規数にはならず、ゼロにフラッシュされま
す。また、非正規オペランドは自動的にゼロに変更されま
す。ハードウェアで段階的アンダーフローと非正規数がサ
ポートされていない SPARC システムでは、このオプションを
使用すると、プログラムによってはパフォーマンスが飛躍的
に上がることがあります。
非標準モードを有効にすると、浮動小数点演算は IEEE 754
規格に準拠しない結果を生成する場合があります。詳細は、
『数値計算ガイド』を参照してください。
このオプションは、SPARC システム上だけで有効であり、さ
らに、メインプログラムをコンパイルするときにのみ有効で
す。x86 システムでは、このオプションは無視されます。
-fprecision=p
(x86) 浮動小数点制御ワードの丸め精度モードを p に初期化
します。p には、single (24 ビット)、double (53 ビット
)、または extended (64 ビット) のいずれかを指定します。
デフォルトの浮動小数点丸め精度は、extended です。
Intel の場合、浮動小数点丸め精度モードを設定すると、指
数ではなく、精度だけが影響を受けます。
このオプションは、x86 システム上だけで有効であり、さら
に、メインプログラムをコンパイルするときにのみ有効で
す。SPARC システムでは、このオプションは無視されます。
-fround=r
プログラム初期化中、実行時に確立される IEEE 754 小数点
丸めモードを設定します。
r には、 nearest、 tozero、 negative、 positive、のいず
れかを指定します。
デフォルト値は、 -fround=nearest です。
その意味は、ieee_flags サブルーチンの場合と同じです。
r が tozero、negative、positive のいずれかの場合は、プ
ログラムが実行を開始するときに、丸め方向モードがそれぞ
れ、「ゼロに向かって丸める」、「負の無限に向かって丸め
る」、「正の無限に向かって丸める」に設定されます。r が
nearest のとき、あるいは -fround フラグを使用しないと
き、丸め方向モードは初期値から変更されません (デフォル
トは「最近似値に丸める」)。
このオプションは、メインプログラムをコンパイルするとき
にのみ有効です。
-fsimple[=n]
オプティマイザが浮動小数点演算に関する仮定を単純化でき
るようにします。
デフォルトは -fsimple=0 です。-fsimple は -fsimple=1 と
同義です。
n を指定する場合は、0、1、2 のいずれかを指定します。
-fsimple=0
仮定の単純化を行えないようにします。厳密に IEEE 754 に
準拠します。
-fsimple=1
適度の単純化を行えるようにします。結果として作成される
コードは、IEEE 754 に厳密には準拠していませんが、ほとん
どのプログラムの数値演算の結果は変更されていません。
With -fsimple=1 の場合、オプティマイザは以下の事項を前
提とします。
o IEEE 754 のデフォルトの丸めモードおよびトラップモード
は、プロセスの初期化後も変化しない。
o 潜在的な浮動小数点例外以外の目に見える結果を作成しな
い演算は、削除できる。
o 無限大または非数をオペランドとして持つ演算は、非数を
その結果に伝える必要はない。たとえば、x*0 は 0 で置き換
えることができる。
o 演算はゼロの符号には依存しない。
-fsimple=1 を指定した場合は、オプティマイザは必ず四捨五
入または例外に応じた最適化を行います。特に浮動小数点演
算は、実行時に適用される丸めモードで異なる結果を作成す
る演算で置き換えることはできません。-fast だけを使用す
ると -fsimple=1 が暗黙的に設定されます。
-fsimple=2
多くのプログラムで丸め方法を変更して異なる数値を結果と
して作成するような、積極的な浮動小数点演算の最適化を可
能にします。たとえば、-fsimple=2 を指定すると、オプティ
マイザは、あるループ内の x/y のすべての計算を x*y に変
更しようとします。この場合、x/y はループ内で少なくとも
1 回は計算されることが保証されており、z=1/y であり、y
と z の値はループ実行中は定数値であることが分かっていま
す。
-fsimple=2 の場合でも、オプティマイザは何も作成しないプ
ログラムに浮動小数点例外を導入することは許されていませ
ん。
関連項目:
最適化が精度に与える影響の詳細は、Rajat Garg、Ilya
Sharapov 共著の Techniques for Optimizing Applications:
High Performance Computing をお読みください。
-fsingle
(-Xt モードおよび -Xs モードのみ) コンパイラは、 float
式を倍精度ではなく、単精度として評価します ( -Xa モード
または -Xc モードのときは、 float 式が常に単精度として
評価されるため、このオプションの影響はありません)。
-fstore
(x86) 浮動小数点式または関数がある変数に代入されるか、
より短い型の浮動小数点にキャストされる場合に、コンパイ
ラがその値をレジスタに残さないで、代入値の左の型に変換
するようにします。結果は、四捨五入と切り捨てが適用され
るため、レジスタ値から生成される値とは異なる場合があり
ます。これはデフォルトのモードです。このオプションを無
効にするには、-nofstore オプションを使用します。
-ftrap[=t[,t...] ]
起動時に IEEE トラップモードを設定しますが、 SIGFPE ハ
ンドラを組み込みません。ieee_handler(3M) または
fex_set_handling(3M) を使用すると、トラップを有効にする
のと同時に SIGFPE ハンドラを組み込むことができます。複
数の値を指定すると、それらの値は左から右に処理されま
す。
値 意味
[no%]division ゼロによる除算時にをトラップします [しま
せん]。
[no%]inexact 不正確な結果時にトラップします [しません
]。
[no%]invalid 無効な演算時にトラップします [しません
]。
オーバーフロー時にトラップします [しません]。
[no%]underflow アンダーフロー時にトラップします [しませ
ん]。
%all 上記のどの場合もトラップします。
%none 上記のどの場合もトラップしません。
common 無効な演算、ゼロによる除算、およびオー
バーフロー時にトラップします。
デフォルト値は -ftrap=%none です。
このオプションの [no%] 形式は、 %all または common 値の
意味を変更する目的にのみ使用され、例に示しているよう
に、下記のいずれかの値と組み合わせる必要があることに注
意してください。 [no%] 形式そのものは、明示的に特定のト
ラップを無効にするわけではありません。
例: -ftrap=%all,no%inexact は、 inexact を除くすべての
トラップを設定します。
1 つのルーチンを -ftrap=t でコンパイルした場合は、その
プログラムのすべてのルーチンを -ftrap=t オプションでコ
ンパイルする必要があります。途中から異なるオプションを
使用すると、予期しない結果を生じることがあります。
浮動小数点値が正確に表現できない場合、必ずトラップが発
行されることになるため、 -ftrap=inexact トラップの使用
には注意してください。たとえば、次の文はこの状態を引き
起こすことがあります。
x = 1.0 / 3.0;
-G 動的にリンクされた実行可能ファイルではなく共有オブジェ
クトを生成します。このオプションは ld に渡され、-dn と
は併用できません。
コンパイル時とリンク時の両方に指定する必要があるコンパ
イラオプションと -G オプションを組み合わせて共有ライブ
ラリを作成した場合は、生成された共有オブジェクトとのリ
ンクでも、必ず同じオプションを指定してください。
-xcode で説明しているように、共有オブジェクトの作成で
は、-xarch=v9 を付けてコンパイルしたすべてのオブジェク
トファイルもまた、明示的な -xcode 値を付けてコンパイル
する必要があります。
-g dbx (1) およびパフォーマンスアナライザ analyzer(1) 用の
追加シンボルテーブル情報を生成します。
コンパイラをリンクのみの用途で起動すると、リンカーld(1)
の代わりに、インクリメンタルリンカーild(1) がデフォルト
になります。-g オプションを指定した場合、コマンド行で
-G またはソースファイルを指定しない限り、ld ではなく
ild がデフォルトで自動的に起動されます。ild の使用を無
効にするには、-xildoff を指定します。 -g を指定して、最
適化レベルが -xO3 以下の場合、コンパイラは最大限のシン
ボル情報とほぼ完全な最適化を提供します。末尾呼び出しの
最適化とバックエンドのインライン化は無効になります。
-g を指定して、最適化レベルが -xO4 の場合、コンパイラは
最大限のシンボル情報とほぼ完全な最適化を提供します。
パフォーマンスアナライザの能力をフルに使用するには、-g
オプションを指定してコンパイルを行います。パフォーマン
ス解析機能の中には -g オプションを指定せずに使用できる
ものもありますが、注釈付きのソース、機能レベル情報の一
部、コンパイラの注釈メッセージを表示するには、-g を指定
してコンパイルを行う必要があります。詳細については、
analyzer(1) のマニュアルページとプログラムのパフォーマ
ンス解析』の「データ収集と解析」を参照してください。
-g を指定した場合に生成される注釈メッセージは、コンパイ
ラがプログラムのコンパイル中に行なった最適化と変換を説
明するものです。ソースコードと交互に配置されるメッセー
ジを表示するには、er_src(1) コマンドを使用します。
注: 以前のリリースでは、このオプションは、コンパイラの
リンク専用の呼び出しにおいて、デフォルトで強制的にリン
カー(ld) ではなく、インクリメンタルリンカー(ild) を使用
するようにしていました。すなわち、-g が指定されたときの
コンパイラは、そのデフォルトの動作として、コマンド行に
-G またはソースファイルの指定がなくてもオブジェクトファ
イルのリンクで必ず、ld の代わりに ild を自動的に呼び出
していました。このリリースではこのようにならず、リンク
専用の呼び出しでは、コンパイラは、-xildon が指定された
場合にのみ ild を使用します。
-H 現在のコンパイル中に取り込まれた各ファイルのパス名を 1
行に 1 つずつ標準エラーに書き込みます。
-h <名前>
共有動的ライブラリの名前を指定します。これにより、複数
のライブラリを作成することができます。
通常は、-h の後に指定する <名前> は、 -o オプションで指
定するファイル名と同じにします。 -h と <名前> の間の空
白は、あってもなくてもかまいません。
リンカーは、指定された <名前> をライブラリに割り当て、
その名前をライブラリファイル中にライブラリの <イントリ
ンシック> 名として記録します。 -h <名前> オプションを指
定しない場合は、ライブラリファイルにはイントリンシック
名は記録されません。
実行時リンカーがライブラリを実行可能ファイルに読み込ん
だ時点で、ライブラリファイルからイントリンシック名が、
実行可能ファイルと必要なライブラリファイルのリストにコ
ピーされます。共有ライブラリのイントリンシック名がない
場合、リンカーは共有ライブラリファイルのパスをコピーし
ます。
-I[-|dir]
-Idir は、#include ファイルが検索されるディレクトリリス
トに dir を追加します。-I 値は、左から右へ累積されま
す。
o ヘッダファイルを検索する際、コンパイラが調べるディ
レクトリは、インクルード文の形式によって異なりま
す。#include <foo.h> の形式のインクルード文の場
合、次の順序でディレクトリを調べます。
1. -I で指定されたディレクトリすべて。
2. 標準のコンパイラおよびシステムディレクトリ (
通常は /usr/include)。
o #include "foo.h" の形式のインクルード文の場合は、
次の順序でディレクトリを調べます。
1. 現在のディレクトリ (すなわち、インクルード文
自体が含まれているファイルが存在するディレク
トリ)。
2. -I で指定されたディレクトリすべて。
3. 標準のコンパイラおよびシステムディレクトリ (
通常は /usr/include)
-I- は、インクルードファイルの検索規則を次のように変更
します。
o -I 指令で明示的に指定されない限り、コンパイラ
は現在のディレクトリを検索しません。この規則
は、#include "foo.h" のようなインクルード文に
ついても同様に適用されます。
o #include "foo.h" という形式のインクルードファ
イルの場合は、次の順序で検索します。
o -Iオプションで (-I-の前と後の両方に) 指
定されたディレクトリ。
o 標準のコンパイラおよびシステムディレクト
リ (通常は /usr/include)。
o #include <foo.h> という形式のインクルードファ
イルの場合は、次の順序で検索されます。
o -I オプションで、-I- の後ろに指定された
ディレクトリ (すなわち、コンパイラは、
-I- の前に指定されたディレクトリを検索し
ません)。
o 標準のコンパイラおよびシステムディレクト
リ (通常は /usr/include)
上記のように動作するのは、コマンド行の最初の -I- オプ
ションだけです。
-I<ディレクトリ> は /usr/include の前に <ディレクトリ>
を検索して、名前の先頭がスラッシュ(/) でないインクルー
ドファイルを探します。複数の -I オプションを指定した場
合は指定した順に検索が行われます。
-i LD_LIBRARY_PATH および LD_LIBRARY_PATH_64 の設定を無視
します。
-KPIC
(SPARC) 旧式。このオプションは使わないでください。代わ
りに -xcode=pic32 を使ってください。『C ユーザーズガイ
ド』に、旧式のオプションとフラグの全一覧が掲載されてい
ます。
(Intel) Intel アーキテクチャでは、-KPIC は -Kpic と同義
です。
-Kpic
(SPARC のみ) 旧式。このオプションは使わないでください。
代わりに -xcode=pic13 を使ってください。『C ユーザーズ
ガイド』に、旧式のオプションとフラグの全一覧が掲載され
ています。
(Intel) 共用ライブラリ (小型) で使用するために、位置独
立コードを生成してください。2**11 一意外部シンボルへの
参照を許可します。
-keeptmp
コンパイル中に作成された一時ファイルを自動的に削除しな
いで、保持します。
-L<ディレクトリ>
ld がライブラリを検索するディレクトリのリストに <ディレ
クトリ> を追加します。このオプションと引数は ld に渡さ
れます。
-l<名前>
lib<名前>.so または lib<名前>.a という名前のオブジェク
トライブラリをリンクします。このオプションと引数は ld
に渡されます。シンボルは指定された順序にライブラリで解
決されるため、コマンド行でのライブラリの指定順序が重要
になります。このオプションはソースファイル名の後に指定
してください。
-mc オブジェクトファイルの .comment セクションから重複した
文字列を削除することができます。このフラグを使用する
と、 -mcs -c が起動されます。
-misalign
(SPARC) 旧式。このオプションは使わないでください。代わ
りに -xmemalign=1i オプションを使ってください。『C ユー
ザーズガイド』に、旧式のオプションとフラグの全一覧が掲
載されています。
-misalign2
(SPARC) 旧式。このオプションは使わないでください。代わ
りに -xmemalign=2i オプションを使ってください。『C ユー
ザーズガイド』に、旧式のオプションとフラグの全一覧が掲
載されています。
-mr[,<文字列>]
-mr はオブジェクトファイルの .comment セクションからす
べての文字列を削除することができます。このフラグを使用
すると、 mcs -d が起動されます。
-mr,<文字列> はオブジェクトファイルの .comment セクショ
ンからすべての文字列を削除し、代わりに <文字列> を挿入
します。<文字列> に空白が埋め込まれている場合は、二重引
用符で括ります。<文字列> がなければ、.comment セクショ
ンは空になります。このフラグを使用すると、 mcs -d -a が
起動されます。
-mt D_REENTRANT をプリプロセッサに渡し、コマンド行のその他
のユーザーが指定したライブラリすべての後ろに -lthread
を付加します。マルチスレッドのプログラムに対しては、コ
ンパイルおよびリンク時点で -mt オプションを使用しなけれ
ばなりません。コンパイル時とリンク時の両方に指定する必
要があるコンパイラオプションの全一覧は、『C ユーザーズ
ガイド』を参照してください。実行の高速化を実現するに
は、マルチプロセッサシステムが必要です。シングルプロ
セッサシステムの場合は、通常、生成されたバイナリの実行
速度は低下します。
-native
このオプションは、 -xtarget=native と同義です。
-nofstore
(x86) 浮動小数点式または関数がある変数に代入されるか、
より短い型の浮動小数点にキャストされる場合に、代入値の
左の型に変換せずに、コンパイラがその値をレジスタに渡す
ようにします。
-O デフォルトの最適化レベル -xO3 を使用します。マクロは、
-xO2 ではなく、-xO3 に展開されるようになりました。
このデフォルトの変更によって、実行時のパフォーマンスが
向上します。ただし、あらゆる変数を自動的に volatile と
見なすことを前提にするプログラムの場合、-x03 は不適切に
なることがあります。このことを前提とする代表的なプログ
ラムとしては、専用の同期方式を実装するデバイスドライバ
や古いマルチスレッドアプリケーションがあります。回避策
は、-O ではなく、-xO2 を使ってコンパイルすることです。
-o<出力ファイル名>
デフォルトの a.out の代わりに、<出力ファイル> を指定し
ます。cc はソースファイルを上書きしないので、<出力ファ
イル> と<ソースファイル> に同じ名前を指定することはでき
ません。このオプションと引数は、 ld(1) に渡されます。
-P 指定した C ファイルだけを前処理し、その結果を接尾辞 .i
が付いたファイル名に出力します。この出力には、-E と異な
り、前処理の行指令は含まれません。
-p prof(1) によるプロファイルの作成に使用するデータを収集
するためのオブジェクトコードを生成します。また、リンク
を行う場合には、プロファイリングされたシステムライブラ
リを使用します。オブジェクトプログラムの実行が正常に終
了すると、ファイル mon.out が作成されます。これにより、
prof を使って実行プロファイルを生成することができます。
-Q[y|n]
出力ファイルに識別情報を出力するかしないかを指定しま
す。 -Qy を指定すると、起動された各コンパイルツールにつ
いての識別情報を出力ファイルに追加します (デフォルトの
動作)。これは、ソフトウェア管理を行うときに役立ちます。
-Qn を指定すると、この情報の出力が抑制されます。
-qp -p と同じです。
-R <ディレクトリ>[:<ディレクトリ>...]
実行時リンカーがライブラリを検索するディレクトリのリス
ト。各ディレクトリ名はコロンで区切ります。指定したディ
レクトリは、それが NULL でなければ出力されるオブジェク
トファイルに記録され、実行時リンカーに渡されます。
LD_RUN_PATH と -R オプションが同時に指定された場合は -R
オプションが優先されます。
-S 指定した C ファイルのコンパイル行い、アセンブルとリンク
は行いません。アセンブリ言語出力が接尾辞 .s を付けた名
前のファイルに残されます。
-s 出力オブジェクトファイルからすべてのシンボルデバッグ情
報を削除します。このオプションは、 ld(1) に渡されます。
このオプションは、 -g と共に指定することはできません。
-U<名前>
<名前> の定義を無効にします。このオプションは、コマンド
行ドライバにより置かれたものを含む同じコマンド行上の -D
により作成されたプリプロセッサシンボル <名前> の初期定
義を削除します。
-U はソースファイル中のプリプロセッサ指令に影響しませ
ん。複数の -U オプションをコマンド行に追加できます。
同じ <名前> を -D と -U の両方で指定した場合は、指定し
た順序にかかわらず <名前> は定義されません。
-V 起動された各ツールのバージョン情報を、標準エラー出力に
書き込みます。
-v 意味検査をより厳しく行い、指定された C ファイルに対する
lint と同様の検査を可能にします。
-Wc,<引数>
<引数> を c に渡します。各引数は 1 つのコンマだけで区切
らなければなりません (コンマは、直前にバックスラッシュ
文字 (\) を置いてエスケープすることで引数の一部にできま
す)。 -W の引数はすべて、通常のコマンド行引数の後に渡さ
れます。
c には、次のいずれかを指定することができます。
a アセンブラ (fbe) (gas)
c C コードジェネレータ (cg) (SPARC)
d cc ドライバ (1)
h 中間コードの翻訳 (ir2hf)(Intel)
i 手続き間の分析 (ube_ipa)(Intel)
l リンクエディタ (ld)
m mcs
0 内部手続きオプティマイザ (SPARC)
o ポストオプティマイザ
p プリプロセッサ (cpp)
u C コードジェネレータ (ube), (Intel)
0 コンパイラ (acomp) (ssbd SPARC)
2 オプティマイザ (iropt) (SPARC)、
(1) 注: -Wd では、このマニュアルページにリストされてい
る cc オプションを C コンパイラに渡すことはできません。
たとえば、-Wa,-o,<オブジェクトファイル> は、 -o と <オ
ブジェクトファイル> をこの順でアセンブラに渡します。ま
た、-Wl,-I,<名前> とすると、リンク段階で動的リンカーの
デフォルト名 /usr/lib/ld.so.1 が <名前> に変更されま
す。
引数をツールに渡す順序は、指定する他のコマンド行オプ
ションによって変わることがあります。
-w コンパイラの警告メッセージを出力しません。
このオプションは error_messages プラグマより優先されま
す。
-X[c|a|t|s]
ISO C 標準にどの程度準拠するかを指定します。-xc99 の値
は、-X オプションに ISO C 標準のどのバージョンが適用さ
れるかに影響します。
c (conformance - 準拠)
ISO C に厳密に準拠し、K&R C の拡張互換性を含みませ
ん。コンパイラは、ISO C 以外の構造を持つプログラム
に対してエラーメッセージや警告メッセージを出力しま
す。事前定義されたマクロ __STDC__ には、 -Xc オプ
ションと共に 1 の値が含まれています。
a これはデフォルトのコンパイラモードです。ISO C と
K&R C の拡張互換性が含まれます。ISO C に従って意味
処理が行われます。K&R C と ANSI C の意味が異なる場
合、ANSI C に準拠した解釈を行います。 -Xa オプショ
ンを -xtransition オプションと共に使うと、コンパイ
ラは異なる意味に関する警告を発します。これはデフォ
ルトのコンパイラモードです。事前定義されたマクロ
__STDC__ には、 -Xa オプションと共に 0 の値が含ま
れています。
t (transition - 移行)
ISO C と K&R C の拡張互換性が含まれます。ISO C に
従った意味処理の変更は行いません。K&R C と ISO C
の意味が異なる場合、K&R C に準拠した解釈を行いま
す。 -Xt オプションを -xtransition オプションと共
に使うと、コンパイラはこの矛盾に関する警告を発しま
す。事前定義されたマクロ __STDC__ には、 -Xt オプ
ションと共に 0 の値が含まれています。
s (K&R C)
コンパイラは、Sun ISO C と K&R C との間で動作が異
なるすべての言語構造について、警告メッセージを出力
します。このオプションでは前処理用に cpp が呼び出
され、__STDC__ は定義されません。
事前定義されたマクロ __STDC__ の値は、-Xt および -Xa の
場合は 0、-Xc の場合は 1 になります ( -Xs の場合には定
義されません)。動作が異なることに関する警告メッセージ
は、適切なコーディングによって表示されないようにするこ
とができます。たとえば、キャストを使用することによって
整数拡張の変更に対する警告を回避することができます。
-x386
(Intel) 旧式。このオプションは使わないでください。代わ
りに -xchip=generic を使ってください。『C ユーザーズガ
イド』に、旧式のオプションとフラグの全一覧が掲載されて
います。
-x486
(Intel) 旧式。このオプションは使わないでください。代わ
りに -xchip=generic を使ってください。『C ユーザーズガ
イド』に、旧式のオプションとフラグの全一覧が掲載されて
います。
-xa 旧式。このオプションは使わないでください。代わりに
-xprofile=tcov を使ってください。『C ユーザーズガイ
ド』に、旧式のオプションとフラグの全一覧が掲載されてい
ます。
-xalias_level[=a]
a には、any、basic、weak、layout、strict、std、strong
のいずれかを指定します。このフラグを使用すると、指定し
た別名解析のレベルが翻訳単位全体に渡って、つまり、翻訳
単位中のすべてのメモリー参照に対して適用されます。
-xalias_level をを指定しなかった場合は、コンパイラは
-xalias_level=any を適用します。 -xalias_level を値を指
定しないで指定した場合は、コンパイラは
-xalias_level=layout を適用します。
o any
コンパイラは、このレベルでは、すべてのメモリー参照が別
名設定できるとみなします。型に基づいた別名解析は行いま
せん。
o basic
-xalias_level=basic オプションを使用すると、コンパイラ
は、さまざまな C の基本型に関連するメモリー参照が相互に
別名設定しないとみなします。また、コンパイラは、他のす
べての型への参照が C の基本型と同様に相互に別名設定でき
るとみなします。コンパイラは、char * を使用する参照が他
のすべての型を別名設定できるとみなします。
o weak
-xalias_level=weak オプションを使用すると、コンパイラ
は、構造体ポインタですべての構造体の型を指すことができ
るとみなします。コンパイルされるソース内の式として参照
される、あるいはコンパイルされるソースの外部から参照さ
れる型参照を保持する構造体または共用体の型は、コンパイ
ルされるソース内の式の前に宣言されなければなりません。
それには、コンパイルされるソースの式内で参照されるオブ
ジェクトの型を参照する型を含むプログラムのすべてのヘッ
ダーファイルを取り込みます。
-xalias_level=weak のレベルでは、コンパイラは、さまざま
な C の基本型に関連するメモリー参照が相互に別名設定しな
いとみなします。コンパイラは、char * を使用する参照が他
のすべての型に関連するメモリー参照を別名設定するとみな
します。
o layout
コンパイラは、メモリー内で同じ型シーケンスを持つ型に関
連するメモリー参照が相互に別名設定できるとみなします。
コンパイラは、メモリー内で同一に見えない型を保持する 2
つの参照が相互に別名設定するとはみなしません。構造体の
初期メンバーがメモリー内で同一に見える場合は、コンパイ
ラは、さまざまな型の構造体からの
2 つのメモリーアクセスが相互に別名設定するとみなしま
す。ただしこのレベルでは、2 つの構造体の間でメモリー内
では同一に見える共通の初期シーケンスメンバーの外側にあ
る異なる構造体オブジェクトのフィールドには、構造体への
ポインタを使ってアクセスしないでください。コンパイラ
は、このような参照が相互に別名設定するとはみなさないた
めです。
-xalias_level=layout のレベルでは、コンパイラは、さまざ
まな C の基本型に関連するメモリー参照が相互に別名設定す
るとはみなしません。コンパイラは、char * を使用する参照
が他のすべての型に関連するメモリー参照を別名設定できる
とみなします。
o strict
コンパイラは、タグを削除すると同一となる構造体や共用体
などの型に関連するメモリー参照が相互に別名設定できると
みなします。これに反して、コンパイラは、タグの削除後に
同一にならない型に関連するメモリー参照が相互に別名設定
するとはみなしません。ただし、コンパイルされるソースの
式内で参照される、あるいはコンパイルされるソースの外部
から参照されるオブジェクトの一部である型の参照を含む構
造体または共用体の型を、コンパイルされるソースの式の前
に宣言する必要があります。
それには、コンパイルされるソースの式内で参照されるオブ
ジェクトの型を参照する型を含むプログラムのすべてのヘッ
ダーファイルを取り込みます。
-xalias_level=strict のレベルでは、コンパイラは、さまざ
まな C の基本型に関連するメモリー参照が相互に別名設定す
るとはみなしません。コンパイラは、char * を使用する参照
が他のすべての型を別名設定できるとみなします。
o std
コンパイラは、型とタグが同じでなければ別名設定できると
みなしませんが、char * を使用する参照は他のすべての型を
別名設定できるとみなします。この規則は、1999 年制定の
ISO C 標準にあるポインタの非参照に関する制約と同じで
す。この規則に則ったプログラムは移植性が高く、最適化す
ることで大きなパフォーマンス向上が得られます。
o strong
std レベルと同じ制約が適用されるほかに、コンパイラが、
型 char * のポインタの使用を型 char のオブジェクトのア
クセスに限定します。コンパイラは、内部ポインタも存在し
ないものとみなします。内部ポインタは、構造体オブジェク
トのメンバーをポイントするポインタとして定義されます。
関連項目: -xprefetch_auto_type
-xarch=isa
対象となる命令セットアーキテクチャ(ISA) を指定します。
このオプションは、コンパイラが生成するコードを、指定し
た命令セットアーキテクチャの命令だけに制限します。この
オプションを使用すると、ターゲットアーキテクチャに固有
の命令が使用できない可能性があります。このオプション
は、バイナリプログラムの移植性に影響を及ぼす可能性があ
ります。詳細については、この節の最後の「注意」および
「警告」の項を参照してください。
コンパイルとリンクを別々のステップで行う場合、両方のス
テップで -xarch に同じ値を指定する必要があります。コン
パイル時とリンク時の両方に指定する必要があるコンパイラ
オプションの全一覧は、『C ユーザーズガイド』を参照して
ください。
値:
SPARC プラットフォームの場合
値 意味
generic ほとんどの 32 ビットプラットフォームアーキテ
クチャで良好なパフォーマンスを得られるように
パラメータを設定します。
これはデフォルトでなくなりました (v8plus を参
照)。このオプションは、どのプロセッサでも大き
くパフォーマンスを落とさず、またほとんどのプ
ロセッサで良好なパフォーマンスを得られるよう
な最良の命令セットを使用します。「最良な命令
セット」の内容は、新しいリリースごとに調整さ
れる可能性があります。
generic64 大部分の 64 ビットプラットフォームアーキテク
チャで最高のパフォーマンスを得られるようにパ
ラメータを設定します。
このオプションは、大きなパフォーマンスの低下
もなく、64 ビットカーネルを持つ Solaris オペ
レーティングシステムで良好なパフォーマンスを
得るのに最適な命令セットを使用します。新しい
リリースのたびに、最適な命令セットの定義は適
宜調整される可能性があります。現在は、これは
-xarch=v9 と同等です。
native ホスト環境で最良のパフォーマンスを得られるよ
うにパラメータを設定します。コンパイラは、プ
ロセッサが動作しているシステム用の
32 ビットバイナリを生成するのに適した設定を
選択します。
native64 64 ビットホスト環境で最高の性能が得られるよう
にパラメータを設定します。これが -fast オプ
ションのデフォルトです。コンパイラは、プロ
セッサが動作しているシステム用の 64 ビットバ
イナリを生成するのに適した設定を選択します。
v7 SPARC-V7 ISA 用にコンパイルします。(旧式)
最新の Solaris オペレーティングシステムは、
SPARC V7 アーキテクチャをサポートしません。こ
のオプションを付けてコンパイルしたプログラム
は、最新のプラットフォームで実行速度が低下し
ます。デフォルトは、 -xarch=v8plus
です。
例: SPARCstation 1、SPARCstation 2
v8a V8a 版の SPARC-V8 ISA 用にコンパイルします。
定義上、V8a は V8 ISA を意味します。ただし、
fsmuld 命令は含まれていません。V8a ISA 上で良
好なパフォーマンスを得るためのコードを生成し
ます。
例: microSPARC I チップアーキテクチャに基づく
すべてのシステム
v8 SPARC-V8 ISA 用にコンパイルします。
V8 アーキテクチャ上で良好なパフォーマンスを得
るためのコードを生成します。
例: SPARCstation 10
v8plus デフォルトです。このことは、コンパイラが
V8plus バージョンの
SPARC-V9 ISA 用の命令セットを使用することを
意味します。詳細は、下記の「SPARC のデフォル
ト値」のセクションを参照してください。
定義上、V8plus は V9 ISA を意味します。ただ
し、V8plus ISA 仕様で定義されている
32 ビットサブセットに限定されます。さらに、
VIS (Visual Instruction Set) と実装に固有な
ISA 拡張機能は含まれていません。このオプショ
ンは V8plus ISA 上で良好なパフォーマンスを得
るためのコードを生成します。生成されるオブ
ジェクトコードは SPARC-V8+ ELF32 形式であり、
Solaris UltraSPARC 環境でのみ実行できます。つ
まり、V7 または V8 のプロセッサ上では実行でき
ません。
例: UltraSPARC チップアーキテクチャに基づくす
べてのシステム
v8plusa V8plusa 版の SPARC-V9 ISA 用にコンパイルしま
す。
定義上、V8plusa は V8plus アーキテクチャ+ VIS
(Visual Instruction Set) バージョン 1.0 +
UltraSPARC 拡張機能を意味します。このオプショ
ンは UltraSPARC アーキテクチャ上で良好なパ
フォーマンスを得るためのコードを生成します。
ただし、V8plus 仕様で定義されている 32 ビット
サブセットに限定されます。生成されるオブジェ
クトコードは SPARC-V8 + ELF32 形式であり、
Solaris UltraSPARC 環境でのみ実行できます。つ
まり、V7 または V8 のプロセッサ上では実行でき
ません。
例: UltraSPARC チップアーキテクチャに基づくす
べてのシステム
v8plusb UltraSPARC-III 拡張機能を持つ、V8plusb 版の
SPARC-V8plus ISA 用にコンパイルします。
UltraSPARC アーキテクチャ+ VIS (Visual
Instruction Set) バージョン 2.0 +
UltraSPARC-III 拡張機能用のオブジェクトコード
を生成します。生成されるオブジェクトコードは
SPARC-V8 + ELF32 形式です。このコードは
Solaris UltraSPARC-III 環境でのみ実行できま
す。UltraSPARC-III アーキテクチャ上で良好なパ
フォーマンスを得るための最良のコードを使用し
ます。
v9 SPARC-V9 ISA 用にコンパイルします。
V9 SPARC アーキテクチャ上で良好なパフォーマン
スを得るためのコードを生成します。生成される
.o オブジェクトファイルは ELF64 形式です。こ
のファイルは同じ形式の SPARC-V9 オブジェクト
ファイルとしかリンクできません。生成される実
行可能ファイルは、64 ビット対応の Solaris オ
ペレーティング環境が動作する、64 ビットカーネ
ルを持つ UltraSPARC プロセッサ上でしか実行で
きません。
-xarch=v9 は、64 ビット対応の Solaris オペ
レーティング環境でコンパイルする場合にのみ使
用できます。
v9a UltraSPARC 拡張機能を持つ SPARC-V9 ISA 用にコ
ンパイルします。
SPARC-V9 ISA に VIS (Visual Instruction Set)
と UltraSPARC プロセッサに固有の拡張機能を追
加します。V9 SPARC アーキテクチャ上で良好なパ
フォーマンスを得るためのコードを生成します。
生成される .o オブジェクトファイルは ELF64 形
式です。このファイルは同じ形式の SPARC-V9 オ
ブジェクトファイルとしかリンクできません。生
成される実行可能ファイルは、64 ビット対応の
Solaris オペレーティング環境が動作する、64
ビットカーネルを持つ UltraSPARC プロセッサ上
でしか実行できません。
-xarch=v9a は、64 ビット対応 Solaris オペレー
ティング環境でコンパイルする場合にのみ使用で
きます。
v9b UltraSPARC-III 拡張機能を持つ SPARC-V9 ISA 用
にコンパイルします。
V9a 版の SPARC-V9 ISA に UltraSPARC-III 拡張
と VIS バージョン 2.0 を追加します。Solaris
UltraSPARC-III 環境で良好なパフォーマンスを得
るためのコードを生成します。生成される .o オ
ブジェクトファイルは SPARC-V9 ELF64 形式で
す。同じ形式の SPARC-V9 オブジェクトファイル
としかリンクできません。生成される実行可能
ファイルは、64 ビット対応の Solaris オペレー
ティング環境が動作する、64 ビットカーネルを持
つ UltraSPARC-III プロセッサ上でしか実行でき
ません。
-xarch=v9b は、64 ビット対応の Solarisオペ
レーティング環境でコンパイルする場合にのみ使
用できます。
SPARC のデフォルト
SPARC 用の新しい -xarch のデフォルト値は、現在使用され
ているほぼあらゆるマシンでの実行時のパフォーマンスを向
上させます。ただし、UltraSPARC より前のコンピュータへの
配備を意図したアプリケーションは、デフォルトでは、それ
らアプリケーションでは動作しません。そうしたアプリケー
ションが UltraSPARC より前のコンピュータで動作するよう
にするには、 -xarch=v8 を付けてコンパイルします。
v8 システムに配備する場合は、あらゆるコンパイラコマンド
行およびあらゆるリンク時コマンドで -xarch=v8 オプション
を明示的に指定する必要があります。提供されるシステムラ
イブラリは、v8 アーキテクチャで動作します。
v7 システムに配備する場合は、あらゆるコンパイラコマンド
行およびあらゆるリンク時コマンドで -xarch=v7 オプション
を明示的に指定する必要があります。提供されるシステムラ
イブラリは、v8 命令セットを使用します。Sun Studio 9 リ
リースの場合、v7 用にサポートされるオペレーティングシス
テムは Solaris 8 リリースだけです。v8 命令があると、
Solaris 8 オペレーティングシステムはソフトウェアでその
命令を解釈します。プログラムは動作しますが、パフォーマ
ンスは低下します。
注意
o SPARC 命令セットアーキテクチャV7、V8 および V8a は上
位バイナリ互換です。
o v8plus でコンパイルされたオブジェクトバイナリファイル
(.o) と v8plusa でコンパイルした .o ファイルは、SPARC
v8plusa 互換のプラットフォーム上でのみリンク、および
同時に実行できます。
o 互換のプラットフォーム上でのみリンク、および同時に実
行できます。 v8plus 、 v8plusa 、および v8plusb でそ
れぞれコンパイルされたオブジェクトバイナリファイル
(.o) は、SPARC V8plusb 互換プラットフォーム上でのみリ
ンクおよび同時に実行できます。
o -xarch の値 v9 、 v9a および v9b は、UltraSPARC 64
ビット Solaris オペレーティング環境でのみ、指定できま
す。
o v9 と v9a でそれぞれコンパイルされたオブジェクトバイ
ナリファイル (.o) は、SPARC V9a 互換プラットフォーム
上でのみリンクおよび同時に実行できます。
o v9 、 v9a 、および v9b でそれぞれコンパイルされたオブ
ジェクトバイナリファイル (.o) は、SPARC V9b 互換プ
ラットフォーム上でのみリンクおよび同時に実行できま
す。
いずれの場合でも、アーキテクチャが古くなるほど、生成さ
れた実行可能ファイルの実行速度が遅くなる可能性がありま
す。また、多くの命令セットアーキテクチャで 4 倍精度
(REAL*16 と long double) の浮動小数点命令を使用できます
が、コンパイラは生成するコード内でこれらの命令を使用し
ません。
Intel プラットフォームの場合
値 意味
generic 命令セットを Intel x86 アーキテクチャに限定し
ます。これは -xarch=386 と同じオプションです
(デフォルト)。
native このシステムではパフォーマンスを落とさずコン
パイルします。このオプションは、どのプロセッ
サでも大きく性能を落とさず、またほとんどのプ
ロセッサで良好なパフォーマンスを得られるよう
な最良の命令セットを使用します。「最良な」命
令セットの定義は、新しいリリースごとに調整さ
れる可能性があります。
386 命令セットを Intel 386/486 アーキテクチャに限
定します。
pentium_pro
命令セットを pentium_pro アーキテクチャに限定
します。
sse pentium_pro アーキテクチャに sse 命令セットを
追加します。
sse2 pentium_pro アーキテクチャに sse2 命令セット
を追加します。
注意:
Solaris x86 SSE/SSE2 Pentium 4 互換プラット
フォームで動作するよう -xarch={sse| sse2} を
使ってコンパイルしたプログラムは、SSE/SSE2 対
応のプラットフォームでのみ実行する必要があり
ます。SSE/SSE2 に対応していないプラットフォー
ムでそうしたプログラムを実行すると、セグメン
ト例外が発生したり、明示的な警告メッセージな
しに不正な結果が発生したりすることがありま
す。
SSE/SSE2 でコンパイルされたバイナリが
SSE/SSE2 に対応していないプラットフォームで実
行されることのないようにするための OS および
コンパイラに対するパッチが、後日提供されるか
もしれません。
Pentium 4 互換プラットフォームの場合、Solaris
9 update 6 以降の OS リリースが SSE/SSE2 に対
応しています。これより前のバージョンの
Solaris OS は SSE/SSE2 に対応していません。こ
のことは、.il インラインアセンブリ言語関数を
使用しているプログラムや、SSE/SSE2 命令を利用
している __asm() アセンブラコードにも当てはま
ります。
コンパイルとリンクを別々に行う場合は、必ずコ
ンパイラを使ってリンクし、-xarch={sse| sse2}
で適切な起動ルーチンがリンクされるようにして
ください。
新しい sse および sse2 フラグの働きについての詳細は、こ
のマニュアルページ先頭の「x86 版での -xarch、-xtarget、
および -xchip のフラグの追加」を参照してください。
x86 デフォルト:
-xarch=isa が指定されていない場合は、-xarch=generic と
見なされます。
注: x86 で -fast が指定された場合は、-xarch=native に設
定されます。
相互の関連性:
このオプションは単体でも使用できますが、 -xtarget オプ
ションの展開の一部でもあります。したがって、特定の
-xtarget オプションによって設定された -xarch の値を変更
するためにも使用できます。たとえば、 -xtarget=ultra2 は
-xarch=v8 -xchip=ultra2 -xcache=16/32/1:512/64/1 に展開
されます。次のコマンドでは、 -xarch=v8plusb は、
-xtarget=ultra2 の展開で設定された -xarch=v8 より優先さ
れます。
example% cc -xtarget=ultra2 -xarch=v8plusb ...
警告:
このオプションを最適化の指定と一緒に使用する場合、適切
な選択をすれば、指定したアーキテクチャで実行可能ファイ
ルの良好なパフォーマンスが得られます。ただし、適切な選
択をしなかった場合、パフォーマンスが著しく低下するか、
作成されたバイナリプログラムがすべてのターゲットプラッ
トフォーム上では実行できない可能性があります。
-xautopar
(SPARC) 複数のプロセッサの自動並列化を有効にします。依
存関係の解析 (ループの繰り返し内部でのデータ依存依存性
の解析) およびループの再構成を行います。最適化が -xO3
より低い場合は、 -xO3 に上げ、警告を出します。
スレッド管理を独自に行う場合は、 -xautopar は指定しない
でください。
このオプションを指定して作成したプログラムを高速に実行
するには、マルチプロセッサシステムが必要になります。シ
ングルプロセッサシステムで実行すると、生成されたバイナ
リファイルの実行速度は遅くなります。
搭載されているプロセッサの数を確認するには、psrinfo コ
マンドを使用します。
複数のプロセッサの使用を要求するには、PARALLEL 環境変数
を設定します。デフォルトは 1 です。
o 利用可能な数を超えたプロセッサを要求することはできま
せん。
o N がマシン上のプロセッサ数を表わす場合、1 ユーザー、
マルチプロセッサシステムで実行するには、PARALLEL=N-1
と指定します。
-xautopar を使用して、コンパイルとリンクを一度に実行す
る場合、リンク時にマルチタスクライブラリとスレッド環境
で安全な C 実行時ライブラリが自動的に取り込まれます。ま
た -xautopar を使用して、コンパイルとリンクを別々に実行
する場合は、cc -xautopar でリンクする必要があります。コ
ンパイル時とリンク時の両方に指定する必要があるコンパイ
ラオプションの全一覧は、『C ユーザーズガイド』を参照し
てください。
-xbuiltin[=a]
標準ライブラリ関数を呼び出すコードをより高度に最適化し
たい場合は、 -xbuiltin[=(%all|%none)] コマンドを使用し
てください。math.h や stdio.h で定義されているような多
くの標準ライブラリは、さまざまなプログラムで共通して使
用されています。このコマンドを使用すると、パフォーマン
スの向上が期待できる場合、コンパイラが組み込み関数また
はシステム関数を代用します。オブジェクトファイル内のコ
ンパイラのコメントを読み取って、コンパイラが実際に置換
を行う関数を決定する方法については、er_src(1) のマニュ
アルページを参照してください。
ただし、こうした置換によって、errno の設定の信頼性が失
われることがあります。プログラムが errno の値に依存して
いる場合は、このオプションの使用は避けてください。
-fast の __MATHERR_ERRNO_DONTCARE マクロの説明も参照し
てください。
a は (%all|%none) を代用します。
注: -xbuiltin は、システムのヘッダーファイルで定義され
た大域関数だけをインライン化します。ユーザー定義の静的
関数はインライン化しません。
このコマンドの第一のデフォルトは -xbuiltin=%none です。
これは、コンパイラが標準ライブラリの関数をまったく代用
またはインライン化しないことを意味しています。第一のデ
フォルトは、 -xbuiltin が指定されなかった場合に適用され
ます。
このコマンドの第二のデフォルトは -xbuiltin=%all です。
これは、最適化の改善が見込まれる場合に、コンパイラが組
み込み関数を代用するか、標準ライブラリ関数をインライン
化することを意味しています。第二のデフォルトは、
-xbuiltin が引数なしで指定された場合に適用されます。
-fast でコンパイルした場合は、 -xbuiltin の引数は %all
に設定されます。
-xCC -xc99=none と -xCC を指定すると、コンパイラは C++ 形式
のコマンドを受け入れます。特に「//」を使用して、コメン
トの開始を表すことができます。
-xc99[=o]
-xc99 フラグは、C99 標準 (ISO/IEC 9899:1999、プログラミ
ング言語 C) 移行に実装された機能の、コンパイラによる認
識を制御します。
o には、以下の値をコンマで区切って指定することができま
す。
値 意味
[no]lib 1990、1999 C 標準の両方で規定されている
1999 C 標準ライブラリのルーチンのセマン
ティックスを有効にします [しません]。
all 1990 C 規格と 1999 C 規格の両方に規定さ
れているルーチンの 1999 C 標準ライブラリ
意味処理に対応している C99 言語機能を認
識可能にします。
none 1990 C 規格と 1999 C 規格の両方に規定さ
れているルーチンの 1999 C 標準ライブラリ
意味処理に対応している C99 言語機能を認
識不可にします。
-xc99 の指定を省略すると、-xc99=all,nolib がデフォルト
で指定されます。
-xc99 を値なしで指定すると、-xc99=all が設定されます。
NOTE:
コンパイラのサポートレベルは、デフォルトでは C99 規格の
言語機能になりますが、Solaris 8 および 9 で
/usr/include に提供されている標準のヘッダーファイルは、
1999 ISO/IEC C 規格に準拠していません。エラーメッセージ
が生成される場合は、-Xc99=none を指定して、ヘッダーに対
する
1990 ISO/IEC C 規格準拠の動作を有効にしてみてくださ
い。
1990 C 規格と 1999 C 規格の両方に規定されているルーチン
の 1999 C 標準ライブラリ意味処理は、Solaris 8 および 9
では使用できないため、有効にすることはできません。
Solaris 8 または 9 で直接または間接に -xc99=lib が指定
された場合は、エラーメッセージが発行されます。
-xcache=c
オプティマイザ用のキャッシュ特性を定義します。
c は次のいずれか 1 つを指定します。
o generic
o native
o s1/l1/a1
o s1/l1/a1:s2/l2/a2
o s1/l1/a1:s2/l2/a2:s3/l3/a3
si/li/ai は次のように定義されます。
si
レベル i のデータキャッシュのサイズ、キロバイト単位
li
レベル i のデータキャッシュのラインサイズ、バイト単位
ai
レベル i のデータキャッシュのマッピング方法
このオプションは単独でも使用可能ですが、 -xtarget オプ
ションを展開したものの一部です。これは、 -xtarget オプ
ションで指定された値を変更するのが主な目的です。
このオプションは、オプティマイザが使用可能なキャッシュ
特性を指定します。特定のキャッシュ特性が必ず使用される
わけではありません。
-xcache の値は次のとおりです。
generic
ほとんどのアーキテクチャで良好なパフォーマンスを
得られるようにパラメータを設定します。これがデ
フォルトです。
native
現在のホスト環境で良好なパフォーマンスを得られる
ようにパラメータを設定します。
s1/l1/a1
レベル 1 のキャッシュ特性を定義します。
s1/l1/a1:s2/l2/a2
レベル 1 および 2 のキャッシュ特性を定義します。
s1/l1/a1:s2/l2/a2:s3/l3/a3
レベル 1、2、および 3 のキャッシュ特性を定義しま
す。
例: -xcache=16/32/4:1024/32/1 では、次のように指定され
ます。
レベル 1 のキャッシュサイズ: レベル 2 のキャッシュサイ
ズ:
16 K バイト
1024 K バイト
ラインサイズ 32 バイト
ラインサイズ 32 バイト
4 ウェイアソシアティブ
ダイレクトマッピング
-xcg89
(SPARC) 旧式。このオプションは使わないでください。最新
の Solaris オペレーティングシステムは、SPARC V7 アーキ
テクチャをサポートしません。このオプションを付けてコン
パイルしたプログラムは、最新のプラットフォームで実行速
度が低下します。 -xarch、 -xchip、および -xcache のデ
フォルトを活かすには、代わりに -O を使ってください。
-xchar=o
このオプションは、char 型が unsigned と定義されているシ
ステムからのコードの移植を容易にするためのものに過ぎま
せん。このようなシステムからの移植を行わない場合は、こ
のオプションは使用しないでください。char 型の符号に依存
するコードだけを signed と unsigned を明示的に指定する
ために書き換える必要があります。o には以下のいずれかの
値を指定できます。
o signed: 宣言された文字定数と変数を符号付き char とし
て扱います。この設定は、コンパイルされたコードの動作
に影響し、ライブラリルーチンの動作には影響しません。
o s: signed と同じです。
o unsigned: 宣言された文字定数と変数を符号なし char と
して扱います。この設定は、コンパイルされたコードの動
作に影響し、ライブラリルーチンの動作には影響しませ
ん。
o u: unsigned と同じです。
-xchar を指定しないと、コンパイラは -xchar=s とみなしま
す。値を指定せずに -xchar を指定すると、コンパイラは
-xchar=s とみなします。
-xchar オプションは、-xchar を使用してコンパイルされた
コードについてのみ char 型の値の範囲を変更します。この
オプションは、システムルーチンまたはヘッダーファイルに
ついては char 型の値の範囲を変更しません。特に limits.h
によって定義される CHAR_MAX と CHAR_MIN の値は、このオ
プションが使用されても変更されません。このため、
CHAR_MAX と CHAR_MIN は、char で符号化できる値の範囲を
表さなくなります。
-xchar の使用する場合、事前定義されたシステムマクロに対
する char の比較には、特に注意してください。マクロの値
には符号付きのものもあるからです。これは、マクロを通し
てアクセスされるエラーコードを返すどのルーチンにもほと
んど共通なことです。エラーコードはふつう負の値なので、
こうしたマクロの値と char とを比較すると、結果は常に偽
です。負の数が符号なし型と等しくなることは決してありま
せん。
ライブラリからエクスポートされたインタフェースについて
は、-xchar を使用してルーチンをコンパイルすることは絶対
にやめてください。Solaris ABI では char 型を符号付きと
指定しており、それに従ってシステムライブラリが動作しま
す。char 型を符号なしとして扱う場合のシステムライブラリ
への影響は幅広くテストされてはいません。このオプション
を使用するのではなく、char 型が符号付き、符号なしのいず
れでも動作するようにコードを変更してください。char 型の
符号はコンパイラ、オペレーティングシステムによって異な
ります。
-xchar_byte_order=o
指定したバイト順序で複数文字定数の文字を並べることによ
り、整定数を生成します。o には、次の値のいずれかを代入
できます。
o low: 複数文字定数の文字を低位から高位へのバイト順序で
並べます。
o high: 複数文字定数の文字を高位から低位へのバイト順序
で並べます。
o default: 複数文字定数の文字を、コンパイルモード
-X[a|c|s|t] により決定されるバイト順序で並べます。
-xcheck[=n]
(SPARC) シングルスレッド化プログラム内のメインスレッド
のスタックオーバーフローとマルチスレッド化プログラム内
のスレーブスレッドスタックを実行時チェックします。ス
タックオーバーフローが検出されると、SIGSEGV が生成され
ます。アプリケーションが、スタックオーバーフローにより
生成された SIGSEGV をその他のアドレス空間違反の処理とは
異なる方法で処理する必要がある場合は、sigaltstack(2) を
参照してください。
n は以下のいずれかの値でなければなりません。
値 意味
%all すべての -xcheck チェックを実行します。
%none -xcheck を行いません。
stkovf スタックオーバーフローの実行時チェックを
可能にします。
no%stkovf スタックオーバーフローチェックを行いませ
ん。
-xcheck を指定しないと、コンパイラはデフォルトで
-xcheck=%none を設定します。-xcheck を引数なしで指定す
ると、コンパイラはデフォルトで、スタックオーバーフロー
の実行時チェックを行う -xcheck=%all を設定します。
-xcheck オプションは、コマンド行で累積されません。コン
パイラは、コマンドで最後に指定されたものに従ってフラグ
を設定します。
-xchip=c
オプティマイザ用のプロセッサを指定します。
c は以降で説明されている値のいずれかである必要がありま
す。
このオプションは単独でも使用可能ですが、 -xtarget オプ
ションを展開したものの一部です。これは主に、 -xtarget
オプションで指定された値を無効にする(変更する)ために使
用します。
このオプションは、処理対象となるプロセッサを指定するこ
とによって、タイミング特性を指定します。
これは次のことに影響を与えます。
o 命令の順序 (スケジューリング)
o コンパイラが分岐を使用する方法
o 意味的に等しい命令が複数ある場合に、実際に使用する命
令
SPARC プラットフォーム用の、 -xchip の値は次のとおりで
す。
generic
ほとんどの SPARC プラットフォームアーキテクチャ
で良好なパフォーマンスを得られるようにパラメータ
を設定します。これがデフォルトです。
native ホスト環境で良好なパフォーマンスを得られるように
パラメータを設定します。
old SuperSPARC プロセッサより旧式のタイミング特性を
使用します。
super SuperSPARC プロセッサ用に最適化します。
super2 SuperSPARC II プロセッサ用に最適化します。
micro microSPARC(TM) プロセッサ用に最適化します。
micro2 microSPARC II プロセッサ用に最適化します。
hyper hyperSPARC(TM) プロセッサ用に最適化します。
hyper2 hyperSPARC II プロセッサ用に最適化します。
ultra UltraSPARC(TM) プロセッサ用に最適化します。
ultra2 UltraSPARC II プロセッサ用に最適化します。
ultra2e
UltraSPARC IIe プロセッサ用に最適化します。
ultra2i
UltraSPARC IIi プロセッサ用に最適化します。
ultra3 UltraSPARC(TM) III プロセッサ用に最適化します。
ultra3cu
UltraSPARC IIIcu プロセッサ用に最適化します。
ultra3i
UltraSPARC IIIi プロセッサ用に最適化します。
ultra4 UltraSPARC IV プロセッサ用に最適化します。
x86 プラットフォーム用の -xchip の値は次のとおりです。
386 Intel 386 アーキテクチャ用に最適化します。
486 Intel 486 アーキテクチャ用に最適化します。
pentium
Intel Pentium アーキテクチャ用に最適化します。
pentium_pro
Intel pentium_pro アーキテクチャ用に最適化しま
す。
pentium3
Pentium 3 方式のプロセッサ用に最適化します
pentium4
Pentium 4 方式のプロセッサ用に最適化します
新しい pentium3 および pentium4 フラグの働きについての
詳細は、このマニュアルページ先頭の「x86 版での -xarch、
-xtarget、および -xchip のフラグの追加」を参照してくだ
さい。
-xcode=v
コードアドレス空間を指定します SPARC のみ
注: -xcode=pic13 または -xcode=pic32 を指定して共有オブ
ジェクトを構築することを強く推奨します。-xarch=v9
-xcode=abs64 および -xarch=v8 -xcode=abs32 を指定して、
使用可能な共有オブジェクトを構築することはできますが、
効率的ではありません。-xarch=v9 -xcode=abs32 または
-xarch=v9 -xcode=abs44 を使用して構築した共有オブジェク
トは動作しません。
-xcode の値は、次のとおりです。
abs32 32 ビット絶対アドレスを生成します。
コード、データ、bss を合計したサイズは 2**32 (2
の 32 乗) バイトに制限されます。
-xarch=(generic|v8|v8a|8plus|v8plusa|v8plusb)
abs44 44 ビット絶対アドレスを生成します。
コード、データ、bss を合計したサイズは 2**44 バ
イトに制限されます。次に示す 64 ビットアーキテ
クチャだけで利用できます。 -xarch=(v9|v9a|v9b)
abs64 64 ビット絶対アドレスを生成します。
次に示す 64 ビットアーキテクチャだけで利用でき
ます。
-xarch=(v9|v9a|v9b)
pic13 共有ライブラリで使用するための位置独立コード (
小規模モデル) を生成します。
-Kpic と同義です。32 ビットアーキテクチャでは最
大 2**11 まで、64 ビットアーキテクチャでは最大
2**10 までの固有の外部シンボルを参照できます。
pic32 共有ライブラリで使用するための位置独立コード (
大規模モデル) を生成します。
-KPIC と同義です。32 ビットアーキテクチャでは最
大 2**30 まで、64 ビットアーキテクチャでは最大
2**29 までの固有の外部シンボルを参照できます。
V8 では、デフォルトは -xcode=abs32 です。SPARC および
UltraSPARC V9 (-xarch=v9|v9a|v9b) のデフォルトは
-xcode=abs44 に変更されました。
動的共有ライブラリの構築では、abs44 (abs32 ではない) の
デフォルトの -xcode 値は、-xarch=v9、v9a、v9b を指定す
ることはできません。代わりに -xcode=pic13 または
-xcode=pic32 を指定してください。
-xcode=pic13 または -xcode=pic32 のどちらを使用するか決
定する際は、elfdump -c (詳細は elfdump(1) のマニュアル
ページを参照) を使って大域オフセットテーブル Table
(GOT) のサイズを調べ、セクション見出し sh_name: .got を
確認します。sh_size 値は GOT のサイズです。GOT が 8,192
バイトに満たない場合は -xcode=pic13、そうでない場合は
-xcode=pic32 を指定します。
一般に、-xcode の使用方法を決める際は、次の指針に従いま
す。
o 実行可能ファイルを構築する場合は、 -xcode=pic13 と
-xcode=pic32 のどちらも使わない。
o 実行可能ファイルへのリンク専用のアーカイブライブラリ
を構築する場合は、 -xcode=pic13 と -xcode=pic32 のどち
らも使わない。
o 共有ライブラリを構築する場合は、まず -xcode=pic13 を
使い、GOT サイズが 8,192 バイトを超えたら、-xcode=pic32
を使う。
o 共有ライブラリへのリンク用のアーカイブライブラリを構
築する場合は、 -xcode=pic32 だけを使う。
-xcrossfile[=n]
複数のソースファイル全体に対する最適化とインライン化を
有効にします。
n を指定する場合は、0 か 1 のどちらかです。デフォルト
-xcrossfile=0 で、ソースファイル間の最適化を行わないこ
とを指示します。-xcrossfile は -xcrossfile=1 と同等で
す。
通常、コンパイラの解析のスコープは、コマンド行上のファ
イルごとに制限されます。たとえば、 -xO4 の自動インライ
ン化は、同じソースファイル内で定義および参照されるサブ
プログラムに制限されます。
-xcrossfile を指定すると、コンパイラは、コマンド行に指
定したすべてのファイルを (1 つのソースファイルに連結し
たように) 解析します。次のコマンド行例を参考にしてくだ
さい。
example% cc -xcrossfile -xO4 -c f1.c f2.c
example% cc -xcrossfile -xO4 -c f3.c f4.c
f1.c と f2.c 間、および f3.c と f4.c
間でモジュール間の最適化が行われます。f1.c と f3.c
間、または f4.c 間では、最適化は行われません。
-xcrossfile は、-xO4 または -xO5 と併用したときだけ有
効です。
ただし、-S を指定することによってアセンブリソースの生成
が指示されている場合、このオプションは何の働きもしませ
ん。アセンブリ (.s) ファイルは、ソースファイルにまたが
る最適化およびインライン化に関係しません。
このコンパイルから生成されるファイルは、インライン化の
ため、相互に依存しています。したがって、1 つのプログラ
ムにリンクするときには、1 つの単位として扱う必要があり
ます。任意の 1 つのルーチンを変更し、そのファイルを再コ
ンパイルした場合は、すべてのファイルを再コンパイルしな
ければなりません。
つまり、このオプションを使用すると、メークファイルの構
成にも影響があります。
-xldscope も参照してください。
-xcsi
このオプションは C コンパイラに、ISO C ソース文字コード
要件に準拠しないロケールで書かれたソースコードを許可し
ます。これらのロケールは ja_JP.PCK を含んでいます。
注: このようなロケールを扱うために必要なコンパイラの変
換フェーズは、コンパイルに膨大な時間がかかる場合があり
ます。このオプションを使用するのは、これらのロケールの
一つのソース文字を含むソースファイルをコンパイルする場
合だけにしたほうがよいでしょう。
-xcsi を出力しない場合、コンパイラは、ISO C ソース文字
コード要件に準拠しないロケールで書かれたソースコードを
認識しません。
-xdebugformat=[stabs|dwarf]
C コンパイラのデバッガ情報は stabs 形式から dwarf 形式
に移行中です。このリリースでのオプションのデフォルトの
設定は、 -xdebugformat=stabs です。
デバッグ情報を読み取るソフトウェアを保持する場合、この
オプションを使用してツールを stab 形式から dwarf 形式に
変換することができるようになりました。
このオプションは、ツールを移植する目的で新しい形式にア
クセスする方法として使用します。デバッガ情報を読み取る
ソフトウェアを保持しない場合や、上記のどちらかの形式の
デバッガ情報を必要とするツールを使用しない場合は、この
オプションを使用する必要はありません。
-xdebugformat=stabs を指定すると、stabs の標準の形式を
使用してデバッグ情報を生成します。
-xdebugformat=dwarf を指定すると、dwarf の標準の形式を
使用してデバッグ情報を生成します。
-xdebugformat の指定を省略すると、-xdebugformat=stabs
を指定したと見なされます。このオプションを引数なしで指
定することはできません。
このオプションは、-g オプションを指定して記録するデータ
の形式に影響を与えます。-g の指定を省略しても、デバッグ
情報の一部は記録され、その形式はこのオプションを使用し
て制御することができます。したがって、-g が使用されてい
ない場合でも、-xdebugformat はデバッグ情報の形式に影響
を与えます。
dbx とパフォーマンスアナライザは stabs、dwarf のどちら
の形式にも対応しているため、どちらのツールもこのオプ
ションの影響を受けません。
このインタフェースは過渡的なものであるため、マイナーリ
リースにおいても、リリースごとに、互換性のない変更が加
えられる可能性があります。
また、今後、stabs、dwarf の個々のフィールドや値にも変更
が加えられる可能性があります。
-xdepend[=[yes|no] ]
(SPARC) ループを分析して繰り返し間のデータ依存関係を調
べ、ループの再構成を行います。
ループを再構成するには、ループの交換、融合、スカラーの
置き換え、および不要な配列の代入の削除が必要になりま
す。最適化レベルが -xO3 より低い場合は、 -xO3 に上げら
れ、警告が出力されます。
-xdepend の指定を省略すると、デフォルトで -xdepend=no
が設定され、ループのデータ依存関係の分析が行われませ
ん。-xdepend を引数を付けずに指定すると、 -xdepend=yes
が設定され、ループのデータ依存関係の分析が行われます。
依存関係の分析は -xautopar または -xparallel にも含まれ
ており、コンパイル時に実行されます。
依存関係の分析は、シングルプロセッサシステムの場合にも
役立つことがあります。ただし、シングルプロセッサシステ
ム上で -xdepend を使用する場合は、 -xautopar または
-xexplicitpar はいずれも使用しないでください。これらの
いずれかが有効になっていると、 -xdepend による最適化は
マルチプロセッサシステムに対して実行されます。
関連項目: -xprefetch_auto_type
-xdryrun
このオプションは、-### と同義のマクロです。
-xe ソースファイルを対象として構文と意味の検査だけを行い、
オブジェクトファイルや実行可能ファイルを生成しません。
-xexplicitpar
(SPARC) 指定されたループを並行化します。依存関係の分
析、つまり繰り返しの間のループおよびデータ依存関係の分
析は、ユーザーの責任です。ソフトウェアが指定されたルー
プを並行化します。最適化レベルが -xO3 より低い場合は、
-xO3 まで上げられ、警告が出力されます。
スレッド管理を独自に行う場合は、 -xexplicitpar は指定し
ないでください。
このオプションを指定して作成したプログラムを高速に実行
するには、マルチプロセッサシステムが必要になります。シ
ングルプロセッサシステムで実行すると、生成されたバイナ
リファイルの実行速度は遅くなります。
並行化するループを識別し、そのループに依存関係がある場
合、不正な結果が得られ、多くの場合実行するたびに結果が
異なり、警告は出されません。縮約ループには、明示的な並
行プラグマは適用しないでください。明示的な並行化が行わ
れますが、ループの縮約については行われず、結果が不正と
なることがあります。
-xexplicitpar を使用してコンパイルとリンクを一度に実行
する場合は、自動的にマイクロタスク・ライブラリおよびス
レッドに対して安全な C 実行時ライブラリが含まれます。
-xexplicitpar を使用して、個別にコンパイルとリンクを行
う場合は、リンク時にも cc -xexplicitpar を指定する必要
があります。コンパイル時とリンク時の両方に指定する必要
があるコンパイラオプションの全一覧は、『C ユーザーズガ
イド』を参照してください。
-xexplicitpar と -xopenmp を同時に出力しないでくださ
い。
-xF -xF オプションは、リンカーによる関数と変数の最適な再整
理を可能にします。
このオプションは、コンパイラに対して、関数またはデータ
変数を細分化された別々のセクションに配置することを指示
します。リンカーは、リンカーの -M オプションで指定され
たマップファイル内の命令を使用してセクションを再整理
し、プログラムのパフォーマンスを最適化することができま
す。通常、この最適化が効果的なのは、ページフォルト時間
がプログラム実行時間のかなりの割合を占める場合のみで
す。
関数と変数を再整理し、パフォーマンスを最適化するには、
以下の作業を行う必要があります。
1. -xF オプションを使用してコンパイルとリンクを行う。
2.『プログラムのパフォーマンス解析』の指示に従って関数
のマップファイルを生成するか、『リンカーとライブラリ』
の指示に従ってデータのマップファイルを生成する。
3. リンカーの -M オプションを使用して、新しいマップファ
イルにリンクする。
4. プログラムを再実行し、アナライザを使用してパフォーマ
ンスを分析し、パフォーマンスの向上を確認する。
v には、以下の値のいずれかを指定できます。
値 意味
[no%]func 関数を個々のセクションに細分化します[し
ません]。
[no%]gbldata 大域的なデータ (外部リンケージのある変数
) を細分化します[しません]。
%all 関数と大域的なデータを細分化します。
%none 何も細分化しません。
-xF の指定を省略すると、デフォルトで -xF=%none が指定さ
れます。-xF を引数なしで指定すると、デフォルトで
-xF=%none,func が指定されます。
関連項目:
analyzer(1)、 debugger(1)、 ld(1)
-xhelp=f
オンラインヘルプ情報を表示します。
f には、flags または readme のいずれかを指定します。
-xhelp=flags はコンパイラオプションの要約を表示し、
-xhelp=readme は README ファイルを表示します。
-xhwcprof=[enable|disable]
(SPARC) -xhwcprof オプションを使用して、コンパイラが
ハードウェアカウンタのプロファイルをサポートできるよう
にすることができます。
-xhwcprof を有効にすると、コンパイラは、ハードウェアカ
ウンタデータの参照と、失敗したイベントおよびそれに関連
する命令とを、ツールが突き合わせる際に有用な情報を生成
します。シンボリック情報 (-g を指定して生成されます) と
共に、対応するデータ型と構造体のメンバーも明らかにする
ことができます。この情報はパフォーマンス分析において役
立てることができます。コードのアドレス、ソース文、ルー
チンに基づくプロファイルから明らかにするのは簡単ではあ
りません。
-xhwcprof を使用して、指定した複数のオブジェクトファイ
ルをコンパイルすることができますが、-xhwcprof が最も役
立つのは、アプリケーション中のすべてのオブジェクトファ
イルに対して適用する場合です。この場合、アプリケーショ
ンのオブジェクトファイル内に散在するすべてのメモリ参照
とそれらの相関関係が明らかになります。
コンパイルとリンクを別々のステップで行う場合、リンク時
にも -xhwcprof を使用します。将来の -xhwcprof の拡張の
際に、リンク時における使用が義務づけられる可能性があり
ます。コンパイル時とリンク時の両方に指定する必要がある
コンパイラオプションの全一覧は、『C ユーザーズガイド』
を参照してください。
-xhwcprof=enable または -xhwcprof=disable の指定は、同
じコマンド行で以前に行なった -xhwcprof の指定をすべて上
書きします。
デフォルトでは、-xhwcprof は無効に設定されます。
-xhwcprof を引数を付けずに指定すると、-xhwcprof=enable
を指定したと見なされます。
-xhwcprof を使用する場合には、最適化を行い、デバッグ
データの形式を dwarf (-xdebugformat=dwarf) に設定する必
要があります。
-xhwcprof と -g を同時に指定した場合のコンパイラの一時
ファイルの記憶領域の必要量の増加は、-xhwcprof を指定し
た場合の必要量の増加と -g を指定した場合の必要量の増加
の合計よりも大きくなります。
次のコマンドを実行すると、example.c がコンパイルされ、
ハードウェアカウンタプロファイルと、DWARF のシンボルを
使用して行うデータ型と構造体のメンバのシンボリック分析
のサポートが指定されます。
example% cc -c -O -xhwcprof -g -xdebugformat=dwarf
example.c
ハードウェアカウンタプロファイルの詳細については、『プ
ログラムのパフォーマンス解析』を参照してください。
-xildoff
インクリメンタルリンカーを無効にし、 ld を強制的に使用
します。このオプションは、 -g オプションを使用しない、
-G オプションを使用する、またはコマンド行に何らかのソー
スファイルがある、という 3 つの条件のうち 1 つでも当て
はまる場合に、デフォルトになります。ild についての詳細
は、『C ユーザーズガイド』を参照してください。
-xildon
インクリメンタルリンカーを起動し、 ild をインクリメンタ
ルモードで強制的に使用します。このオプションは、 -g オ
プションを使用する、 -G オプションを使用しない、コマン
ド行にソースファイルがないという 3 つの条件がすべて当て
はまる場合に、デフォルトになります。ild についての詳細
は、『C ユーザーズガイド』を参照してください。
-xinline[=v[,v]...]
v には [{%auto,func_name,no%func_name}] を指定します。
-xinline は、リストに指定された関数だけをインライン化し
ようとします。リストは、関数名をコンマで区切ったもの
か、no%func_name 値をコンマで区切ったものか、値 %auto
です。no%func_name を指定すると、コンパイラは指定された
関数をインライン化しません。%auto を指定すると、コンパ
イラはソースファイルにあるすべての関数を自動的にインラ
イン化しようとします。
値のリストは、左から右へ累積されます。したがって
-xinline=%auto,no%foo と指定すると、コンパイラは foo を
除くすべての関数をインライン化しようとします。
-xinline=%bar,%myfunc,no%bar と指定すると、コンパイラは
myfunc のみをインライン化しようとします。
最適化レベルを -xO4 以上に設定してコンパイルする場合、
コンパイラは通常、ソースファイルに定義されている関数へ
のすべての参照をインライン化しようとします。 -xinline
オプションを指定することによって、コンパイラがインライ
ン化する関数セットを制限することができます。-xinline=
だけを指定して、関数名や auto を指定しないと、ソース
ファイルのどのルーチンもインライン化されません。%auto
を指定せずに func_name と no%func_name のリストを指定す
ると、コンパイラはリストに指定された関数だけをインライ
ン化しようとします。最適化レベルが -xO4 以上に設定さ
れ、 -xinline オプションで、値のリストに %auto を指定す
ると、コンパイラは no%func_name により明示的に除外され
ていないすべての関数をインライン化しようとします。
以下のいずれかの場合、関数はインライン化されません(警告
は出力されません)。
o 最適化のレベルが -xO3 より低いとき
o ルーチンが見つからないとき
o iropt によってルーチンのインライン化による効果または
安全性が認められないとき
o ルーチンのソースがコンパイル中のファイルにないとき
(-xcrossfile 参照)
コマンド行に複数の -xinline オプションを指定しても、こ
れらのオプションは累積されません。コンパイラがインライ
ン化を試みる関数は、コマンド行の最後の -xinline によっ
て指定されます。
-xldscope も参照してください。
-xipo[=a]
(SPARC) a は 0 か 1 のいずれかです。引数なしの -xipo は
-xipo=1 と同じです。-xipo=0 はデフォルト設定で、-xipo
を無効にします。
-xipo=1 を指定すると、コンパイラはソースファイル全体の
インライン化を行います。-xipo=2 を指定すると、コンパイ
ラは手続き間の別名解析とメモリー割り当ておよび配置の最
適化を行い、キャッシュのパフォーマンスを向上させます。
コンパイラは、内部手続き解析を起動して、プログラム全体
の最適化を実行します。 -xcrossfile と異なり、-xipo はリ
ンク段階ですべてのオブジェクトファイルの最適化を実行し
ます。コンパイルコマンドが実行対象とするソースファイル
だけに限定されません。ただし、-xcrossfile 同様、-xipo
を付けて行うプログラム全体の最適化には、アセンブラ (.s)
ソースファイルは含まれません。
-xipo はコンパイル時とリンク時の両方で指定する必要があ
ります。コンパイル時とリンク時の両方に指定する必要があ
るコンパイラオプションの全一覧は、『C ユーザーズガイ
ド』を参照してください。
解析と最適化は -xipo でコンパイルされるオブジェクトファ
イルのみに行われます。ライブラリ上のオブジェクトファイ
ルには拡張できません。 -xipo は複数の段階に分割された、
別々のステップでコンパイルおよびリンクを行う場合は、各
ステップで -xipo を指定する必要があります。
-xipo オプションは、ファイルをまたいだ最適化を実行する
ために必要な追加情報を格納するために、かなり大きなオブ
ジェクトファイルを生成します。しかし、この追加情報は、
最終的な実行可能バイナリファイルの一部にはなりません。
実行プログラムのサイズの増加分は、追加で行われた最適化
によるものです。コンパイル段階で作成されるオブジェクト
ファイルには、コンパイル時に生成された、追加の解析情報
が含まれています。この情報によって、ファイルをまたいだ
最適化がリンク段階に実行されます。
以下に、-xipo について考慮すべきいくつかの重要事項を記
述します。
o 少なくとも -xO4 の最適化レベルを必要とします。
o -xcrossfile とは併用できません。同時に使用するとコン
パイルエラーが発生します。
o -xipo なしでコンパイルされるオブジェクトは、-xipo で
コンパイルされるオブジェクトと自由にリンクできます。
次の例では、コンパイルとリンクは単一のステップで行われ
ます。
cc -xipo -xO4 -o prog part1.c part2.c part3.c
次の例では、コンパイルとリンクは別々のステップで行われ
ます。
cc -xipo -xO4 -c part1.c part2.c
cc -xipo -xO4 -c part3.c
cc -xipo -xO4 -o prog part1.o part2.o part3.o
コンパイルの段階で作成されたオブジェクトファイルには、
追加の解析情報が含まれています。これにより、ファイルを
またいだ最適化をリンクの段階で実行できるようになりま
す。
制限事項として、ライブラリは、-xipo でコンパイルされて
いても、ファイルをまたいだ内部手続き解析を行うことがで
きないことが挙げられます。以下に例を示します。
cc -xipo -xO4 one.c two.c three.c
ar -r mylib.a one.o two.o three.o
cc -xipo -xO4 -o myprog main.c four.c mylib.a
ここで、内部手続き最適化は、one.c、two.c、three.c の
間、および main.c、four.c の間で行われます。しかし、
main.c または four.c と mylib.a のルーチンの間では行わ
れません。(最初のコンパイルで、未定義シンボルに関連した
警告が出力される場合があります。しかし、コンパイルおよ
びリンクの両方の段階が対象であるため、内部手続き最適化
は正しく実行されます。)
-xipo=2 による内部手続き解析を行うべきでないケース
内部手続き解析では、コンパイラは、リンクの段階でオブ
ジェクトファイル群を走査しながら、プログラム全体の解析
と最適化を試みます。このとき、コンパイラは、このオブ
ジェクトファイル群に定義されているすべての foo() 関数 (
またはサブルーチン) に関して次の 2 つのことを仮定しま
す。
(1) 実行時、このオブジェクトファイル群の外部で定義され
ている別のルーチンによって foo() が明示的に呼び出されな
い。
(2) オブジェクトファイル群内のルーチンからの foo() 呼び
出しが、そのオブジェクトファイル群の外部に定義されてい
る別のバージョンの foo() からの割り込みを受けない。
アプリケーションに対して仮定 (1) が当てはまらない場合
は、コンパイルで -xipo=2 を使わないでください。
仮定 (2) が当てはまらない場合は、コンパイルで -xipo=1
および -xipo=2 を使わないでください。
1 例として、独自のバージョンの malloc() で関数 malloc()
に割り込むケースを考えてみましょう。-xipo=2 を使ってコ
ンパイルする場合、その独自のコードとリンクされる mal-
loc() を参照する、あらゆるライブラリのあらゆる関数のコ
ンパイルで -xipo=2 を使用する必要があるとともに、リンク
ステップでそれらのオブジェクトファイルが必要になりま
す。システムライブラリでは、このことが不可能なことがあ
り、このため、独自のバージョンの malloc() のコンパイラ
に -xipo=2 を使ってはいけません。
もう 1 つの例として、別々のソースファイルにある foo()
および bar() という 2 つの外部呼び出しを含む共有ライブ
ラリを構築するケースを考えてみましょう。また、bar() は
foo() を呼び出すと仮定します。foo() が実行時に割り込み
を受ける可能性がある場合、foo() および bar() のソース
ファイルのコンパイルで -xipo=1 や -xipo=2 を使ってはい
けません。さもないと、foo() が bar() 内にインライン化さ
れ、不正な結果になる可能性があります。
-xjobs、-xipo_archive も参照してください。
-xipo_archive[=a]
-xipo_archive オプションは、実行可能ファイルを生成する
前に、コンパイラが、-xipo を付けてコンパイルされた、
アーカイブライブラリ (.a) 内のオブジェクトファイルを
使って、リンカーに渡すオブジェクトファイルを最適化する
ことを可能にします。コンパイル中に最適化された、このラ
イブラリ内のオブジェクトファイルは、その最適化された
バージョンに置き換えられます。
a は次のいずれかです。
writeback
コンパイラは、実行可能ファイルを生成する前に、
-xipo を付けてコンパイルされた、アーカイブライ
ブラリ (.a) 内のオブジェクトファイルを使って、
リンカーに渡すオブジェクトファイルを最適化しま
す。コンパイル中に最適化された、このライブラリ
内のオブジェクトファイルは、その最適化された
バージョンに置き換えられます。
readonly
コンパイラは、実行可能ファイルを生成する前に、
-xipo を付けてコンパイルされた、アーカイブライ
ブラリ (.a) 内のオブジェクトファイルを使って、
リンカーに渡すオブジェクトファイルを最適化しま
す。
none アーカイブファイルの処理はありません。
-xipo_archive の値が指定されていない場合、コンパイラは
-xipo_archive=none に設定します。
-xjobs=n
(SPARC) 複数のプロセッサを使用してコンパイルを行いま
す。
-xjobs オプションを指定して、コンパイラが作業を完了する
ために作成するプロセスの数を設定します。このオプション
を使用して、マルチ CPU マシンにおける構築時間を短縮する
ことができます。現在、-xjobs を使用する場合には、-xipo
オプションも指定する必要があります。-xjobs=n を指定する
と、内部手続きオプティマイザは、複数のファイルをコンパ
イルするために起動するコードジェネレータの最大数として
n を使用します。
一般的に、n には、使用可能なプロセッサの 1.5 倍の数値を
指定するのが安全です。使用可能なプロセッサの数倍の数値
を指定すると、生成された複数のジョブ間でのコンテキスト
切り替えのオーバーヘッドが発生し、パフォーマンスの低下
につながります。また、非常に大きな数値を指定すると、ス
ワップ空間をはじめとするシステム資源の限界を超過する可
能性があります。
-xjobs は必ず値を指定して使用します。値を指定しないとエ
ラー診断が出て、コンパイルが異常終了します
コマンド行で -xjobs を複数指定すると、一番右以外の指定
は無効になります。
たとえば、2 つのプロセッサを搭載したシステムの場合、次
のコマンドは、-xjobs オプションを指定せずに実行した場合
よりも高速にコンパイルを行います。
example% cc -xipo -xO4 -xjobs=3 t1.c t2.c t3.c
-xldscope={v}
外部シンボルの定義のデフォルトのリンカーのスコープを変
更します。デフォルトを変更することによって、実装の隠蔽
が向上し、共有ライブラリがさらに高速かつ安全になる可能
性があります。
v には、以下の値のいずれかを指定します。
値 意味
global 大域的リンカースコープは、制限が最も少な
いスコープです。シンボルの参照はすべて、
シンボルを定義する最初の動的モジュール内
の定義に結びつけられます。このリンカーの
スコープが、外部シンボルの現在のリンカー
のスコープです。
symbolic シンボリックリンカースコープを意味し、大
域的リンカースコープよりも制限されていま
す。リンクされている動的モジュール内から
のシンボルの参照はすべて、そのモジュール
内で定義されているシンボルに結びつけられ
ます。このシンボルは、モジュールの外部で
は大域的に見えます。このリンカースコープ
は、リンカーのオプション
-Bsymbolic に相当します。
hidden 隠蔽リンカースコープは、シンボリックリン
カースコープ、大域的リンカースコープより
もさらに制限されています。動的モジュール
内の参照はすべて、そのモジュール内の定義
に結びつけられます。シンボルはモジュール
の外部では見えません。
-xldscope の指定を省略すると、-xldscope=global を指定し
たと見なされます。-xldscope を引数を付けずに指定するこ
とはできません。引数を付けずに -xldscope を指定すると、
コンパイラはエラーを出力します。コマンド行でこのオプ
ションを複数指定すると、一番右以外の指定は無効になりま
す。
クライアントからライブラリ内の関数をオーバーライドする
ことを許可しようとする場合、ライブラリの構築中にその関
数がインライン生成されないようにする必要があります。関
数名を -xinline を付けて指定した場合、#pragma inline を
使用した場合、インライン化が自動的に発生する -xO4 以上
でコンパイルを行なった場合、インライン指示子を使用した
場合、クロスファイルの最適化を使用する場合には、コンパ
イラは関数をインライン化します。
たとえば、ライブラリ ABC にはデフォルトのアロケータ関数
があり、それをクライアントから使用でき、なおかつライブ
ラリ内でも使用されるる場合を想定します。
void* ABC_allocator(size_t size) { return malloc(size);
}
ライブラリを -xO4 以上で構築すると、コンパイラは、ライ
ブラリコンポーネント内で発生する ABC_allocator の呼び出
しをインライン化します。ライブラリのクライアントが
ABC_allocator をカスタマイズしたバージョンで置き換えよ
うとした場合、ABC_allocator を呼び出したライブラリコン
ポーネント内では置き換えは行われません。したがって、最
終的なプログラムには、この関数の相異なるバージョンが含
まれることになります。
指示子 __hidden または __symbolic を使用して宣言したラ
イブラリ関数は、ライブラリの構築時にインライン生成され
る可能性があります。このような関数がクライアントから
オーバーライドされることは、サポートされていません。詳
細については、『C ユーザーズガイド』の第 2 章「Sun の実
装に固有のC コンパイラ情報」を参照してください。
指示子 __global を使用して宣言したライブラリ関数はイン
ラインとして宣言しはなりません。また、コンパイラの
-xinline オプションを使用したインライン化も防ぐ必要があ
ります。
関連項目
-xinline、-xO、-xcrossfile、ld(1)
-xlibmieee
例外的な場合に、数学ルーチンの戻り値を強制的に IEEE 754
形式にします。その場合、例外メッセージは出力されず、
errno も設定されません。
-xlibmil
数学ライブラリ用のインライン化テンプレートを取り込みま
す。このオプションは、浮動小数点オプションとシステムの
プラットフォームに適切なアセンブリ言語インラインテンプ
レートを選択します。 -xlibmil は、-xinline フラグの一部
である関数の指定に関係なく、関数をインライン化します。
ただし、こうした置換によって、errno の設定の信頼性が失
われることがあります。プログラムが errno の値に依存して
いる場合は、このオプションの使用は避けてください。
-fast の __MATHERR_ERRNO_DONTCARE マクロの説明も参照し
てください。
-xlibmopt
このオプションは、コンパイラが最適化された数学ルーチン
ライブラリを使用することを可能にします。このオプション
を使用する場合は、 -fround=nearest を指定することによっ
て、デフォルトの丸めモードを使用する必要があります。
数学ルーチンライブラリは、パフォーマンスの面で最適化さ
れており、通常より高速なコードを生成します。ただし、結
果は、通常の数学ライブラリで生成されるものと少し異なる
ことがあります。その場合は、通常、最終ビットが異なって
います。
ただし、こうした置換によって、errno の設定の信頼性が失
われることがあります。プログラムが errno の値に依存して
いる場合は、このオプションの使用は避けてください。
-fast の __MATHERR_ERRNO_DONTCARE マクロの説明も参照し
てください。
このライブラリオプションのコマンド行での順序は、重要で
はありません。
相互の関連性:
このオプションは、 -fast によって暗黙で指定されます。
関連項目:
-fast
-xnolibmopt
-xlic_lib=sunperf
(SPARC) Sun が提供する Performance Library とリンクしま
す。
-xlicinfo
ライセンスシステムに関する情報を返します。
このオプションではコンパイルは行われず、ライセンスも検
査されません。
-xlinkopt[=level]
(SPARC) コンパイラに対して、リンク時に再配置可能なオブ
ジェクトファイルの最適化を行うよう指示します。
ポストオプティマイザは、リンク時に、バイナリオブジェク
トコードの高度なパフォーマンス最適化を行います。level
には、実行する最適化のレベルとして、0、1、2 のいずれか
を指定します。
最適化のレベル
0 ポストオプティマイザが無効になります (デフォル
ト値)。
1 リンク時に、命令キャッシュカラーリング、分岐の
最適化など、制御フロー分析に基づく最適化を実行
します。
2 デッドコードの除去とアドレス計算の簡素化など、
より詳細なデータ制御分析に基づいて、リンク時の
最適化を行います。
level の値を指定せずに -xlinkopt を使用した場合、
-xlinkopt=1 を指定したと見なされます。
こうした最適化はオブジェクトバイナリコードを分析して、
リンク時に実行されます。このオブジェクトファイルは書き
直されませんが、結果として出力される実行可能コードは、
元のオブジェクトコードとは異なる可能性があります。
このオプションは、プロファイルフィードバックを使用して
プログラム全体のコンパイルを行う際に使用するのが最も効
果的です。
コンパイルを複数の段階に分けて行う場合、コンパイル、リ
ンクの両段階で -xlinkopt を使用する必要があります。
example% cc -c -xlinkopt a.c b.c
example% cc -o myprog -xlinkopt=2 a.o
コンパイル時とリンク時の両方に指定する必要があるコンパ
イラオプションの全一覧は、『C ユーザーズガイド』を参照
してください。
level の値は、コンパイラがリンクを行う際にだけ使用され
ることに注意してください。上記の例では、オブジェクトバ
イナリは最適化レベル 1 を指定したとみなされコンパイルさ
れていますが、最適化のレベルとして 2 が使用されていま
す。
リンク時にポストオプティマイザをインクリメンタルリン
カー ild と共に使用することはできません。 -xlinkopt
は、デフォルトのリンカーを ld に設定します。 -xildon を
使用してインクリメンタルリンカーを明示的に有効にし、さ
らに -xlinkopt を指定すると、-xlinkopt が無効になりま
す。
-xlinkopt を使用してコンパイルを行う場合、リンカーオプ
ション -zcompreloc は使用しないでください。
-xlinkopt がリンク時に効果を発揮できるようにするには、
少なくともいくつかのコンパイルコマンドで -xlinkopt を使
用しなければなりません。オプティマイザは、-xlinkopt を
指定せずにコンパイルしたオブジェクトバイナリについて
も、限定的な最適化を行うことができます。
-xlinkopt は、コンパイラのコマンド行で指定された静的な
ライブラリのコードを最適化しますが、コマンド行で指定さ
れた共有 (動的な) ライブラリのコードはスキップし、最適
化しません。また、共有ライブラリを構築する場合 ( -G を
使用してコンパイルする場合)、にも -xlinkopt を使用する
ことができます。
リンク時のポストオプティマイザは、実行時プロファイルの
フィードバックと共に使用すると最も効果的です。プロファ
イルを行うことによって、コードの最も使用される部分と最
も使用されない部分を明らかにし、その結果に従ってオプ
ティマイザを集中的に動作させることができます。これは、
リンク時にコードの最適な配置を行うことによって命令
キャッシュのミスを低減できる大きなアプリケーションにお
いてはとくに重要です。通常、このコンパイルは次のように
行います。
example% cc -o progt -xO5 -xprofile=collect:prog file.c
example% progt
example% cc -o prog -xO5 -xprofile=use:prog -xlinkopt file.c
プロファイルのフィードバックの使用の詳細については、
-xprofile を参照してください。
このオプションを指定してコンパイルを行うと、リンク時間
が若干増加することに注意してください。オブジェクトファ
イルのサイズも増加しますが、実行可能ファイルのサイズは
変わりません。 -xlinkopt と -g を指定してコンパイルを行
うと、デバッグ情報が含まれるので、実行可能ファイルのサ
イズが大きくなります。
-xloopinfo
(SPARC) 並行化されているループと並行化されていないルー
プを表示します。このオプションは通常、-xautopar および
-xexplicitpar オプションと共に使用します。Sun WorkShop
には、マルチプロセッサ C を使用する場合に必要なライセン
スが含まれています。
-xM 指定された C プログラムに対してのみプリプロセッサを実行
し、Makefile 用の依存関係の生成と、結果の標準出力への送
出を要求します (Makefile と依存関係の詳細については
make(1) を参照してください)。
-xM1 -xM と同じ。ただし、-xM1 は、-Xs モードではサポートされ
ておらず、また、ヘッダーファイル /usr/include の依存性
を報告しません。次に例を示します。
example% more hello.c
#include <stdio.h>
main()
{
(void) printf ("hello\n");
}
example% cc -xM hello.c
hello.o: hello.c
hello.o: /usr/include/stdio.h
次のように -xM1 を使ってコンパイルすると、ヘッダーファイルの
依存性は報告されません。
example% cc -xM1 hello.c
hello.o: hello.c
-xMerge
cc は、データセグメントをテキストセグメントにマージしま
す。このコンパイルによって生成されたオブジェクトファイ
ルで初期化されたデータは読み取り専用と
なり、(ld -N によってリンクされないかぎり) プロセス間で
共有されます。
-xmaxopt[=v]
このコマンドはプラグマ opt のレベルを、指定されたレベル
に制限します。デフォルト値は -xmaxopt=off で、プラグマ
opt は無視されます。引数なしで -xmaxopt を指定すると、
-xmaxopt=5 が使用されます。
-xO と -xmaxopt の両方を指定する場合、 -xO で設定する最
適化レベルが -xmaxopt 値を超えてはいけません。
-xmemalign=ab
(SPARC) このコマンドは、想定する最大メモリー境界整列
と、境界整列に失敗したデータがアクセスされた際の動作を
指定します。
コンパイル時に境界整列を判別できるメモリーアクセスの場
合、コンパイラはそのデータの境界整列に適切なロードおよ
びストア命令シーケンスを生成します。
コンパイル時に境界整列を判別できないメモリーアクセスの
場合、コンパイラは、必要なロードおよびストア命令シーケ
ンスを生成するために境界整列を想定する必要があります。
このように境界整列を判別できない状況では、 -xmemalign
オプションを使用して、コンパイラが想定すべきデータの最
大メモリー境界整列を指定します。また、整列に失敗したメ
モリーアクセスが実行時に発生した場合、従うべきエラー動
作も指定できます。
値
次に、 a に指定できる値を示します。
1 最大 1 バイトの境界整列を想定します。
2 最大 2 バイトの境界整列を想定します。
4 最大 4 バイトの境界整列を想定します。
8 最大 8 バイトの境界整列を想定します。
16 最大 16 バイトの境界整列を想定します。
次に、 b に指定できる値を示します。
i アクセスを解釈して実行を続けます。
s シグナル SIGBUS を発生させます。
f 境界整列が 4 バイト以下の場合に、シグナル
SIGBUS を発生させます。4 より大きい場合、アク
セスを解釈して実行を続けます。
b の値を i または f に設定してコンパイルしたオブジェク
トファイルにリンクする場合は、-xmemalign も指定する必要
があります。コンパイル時とリンク時の両方に指定する必要
があるコンパイラオプションの全一覧は、『C ユーザーズガ
イド』を参照してください。
デフォルト
v8 アーキテクチャでは、デフォルトは -xmemalign=8i で
す。v9 アーキテクチャでは、-xmemalign=8s になります。
-xmemalign を指定することは、-xmemalign=1i を指定するこ
とと同等です。
-xnativeconnect[=a[,a]...] ]
インタフェース情報をオブジェクトファイルと後続の共用ラ
イブラリ内に取り込んで、共用ライブラリを Java[tm] プロ
グラミング言語で書かれたコード (Java コード) から使用で
きるようにするには、-xnativeconnect オプションを使用し
ます。cc -G コマンドを使用して共用ライブラリを構築する
場合も、 -xnativeconnect を含める必要があります。
-xnativeconnect を使用してコンパイルする場合、ネイティ
ブコードインタフェースの外部に対する可視性が最大になり
ます。Native Connector Tool(NCT) を使用すると、Java
コードの自動生成と Java[tm] Native Interface (JNI) が使
用可能になり、C 共用ライブラリを Java コードから呼び出
せるようになります。NCT の使用方法の詳細については、IDE
のオンラインヘルプを参照してください。
a には、次のいずれかの値を指定します。
%all|%none|[no%]interfaces
%all -xnativeconnect の個々のオプションに記述された各
種データをすべて生成します。
%none -xnativeconnect の個々のオプションに記述された各
種データを何も生成しません。
[no%]inlines
参照されたインライン関数の行外のインスタンスを強
制的に生成します。これにより、ネイティブコネクタ
の一部として生成された外部関数を行外のインスタン
スに結合できます。呼び出し側でのこれら関数の通常
のインライン化が、この影響を受けることはありませ
ん。[no%]interfaces バイナリインタフェース記述子
(BIDS) を強制的に生成します。
-xnativeconnect を指定しないと、コンパイラはこのオプ
ションを -xnativeconnect=%none に設定します。
-xnativeconnect だけを指定すると、コンパイラはこのオプ
ションを -xnativeconnect=interfaces に設定します。
-xnativeconnect=interfaces は、バイナリインタフェース記
述子 (BIDS) を強制的に生成します。
-xnolib
デフォルトのライブラリをリンクしません。すなわち、ld に
-l オプションを渡しません。通常、cc ドライバは ld に
-lc を渡します。
-xnolib を使用した場合は、-l オプションをすべて自分で渡
す必要があります。
-xnolibmil
数学ライブラリルーチンをインライン化しません。このオプ
ションは、 cc -fast -xnolibmil ... のように、 -fast オ
プションの後ろで指定してください。
-xnolibmopt
以前に -xlibmopt オプションが指定されている場合は、その
指定を無効にし、数学ルーチンライブラリを使用しません。
次のように、このオプションはコマンド行の -fast オプショ
ンの後に使用します。
example% cc -fast -xnolibmopt ...
-xOn 最適化レベル (n) を指定します。大文字のオー(O) の後に数
字の 1 〜 5 を指定してください。
一般的に、プログラムのコンパイル時の最適化レベルが高け
れば高いほど、実行時のパフォーマンスは向上します。しか
し最適化レベルが高いと、コンパイル時間が長くなり、実行
可能ファイルのサイズが大きくなる可能性が高まります。
-xOn には、5 段階の最適化レベルを指定できます。次の節で
は、SPARC プラットフォーム用および x86 プラットフォーム
用の各最適化レベルについて説明します。各レベルで実施に
行われる最適化の内容は、コンパイラのリリースによって異
なる可能性があります。
オプティマイザは、メモリーが足りなくなると最適化レベル
を下げて現在の手順を再試行し、コマンド行オプションで指
定された元のレベルでそれ以降の手続きを再開します。
値:
SPARC プラットフォームの場合
-xO1 基本的な局所的最適化 (ピープホール) を行います。
-xO2 基本的な局所的および大域的な最適化を行います。これ
には、帰納関数の除去、局所的および大域的な共通部分
式の除去、算術の簡素化、コピーおよび定数の伝播、可
変ループ最適化、レジスタの割り当て、基本ブロックの
マージ、再帰的末尾の除去、無意味なデッドコードの除
去、末尾呼び出しの除去、素数式の展開が含まれていま
す。
このレベルでは、大域、外部、間接の参照および定義を
レジスタに割り当てません。これらの参照や定義は、
volatile 型として宣言されたかのように取り扱われま
す。一般に、-xO2 レベルでは、コードサイズはもっと
も小さくなります。
-xO3 -xO2 レベルで行われる最適化に加えて、外部変数に対
する参照および定義も最適化されます。ループの展開や
ソフトウェアのパイプライン化も実行されます。このレ
ベルでは、ポインタ代入の影響は追跡されません。デバ
イスドライバをコンパイルするとき、またはシグナルハ
ンドラの内部から外部変数を変更するプログラムをコン
パイルするときは、volatile 型の修飾子を使用してオ
ブジェクトが最適化されないようにする必要がありま
す。一般に、-xO3 レベルでは、コードサイズが増えま
す。
-xO4 -xO3 レベルで行われる最適化に加えて、同じファイル
にある関数を自動的にインライン化します。関数のイン
ライン化を制御する方法は、このマニュアルページの
-xinline オプションの説明を参照してください。この
レベルでは、ポインタ代入の影響は追跡されません。ま
た、一般的に生成されるコードのサイズが大きくなりま
す。
-xO5 最高レベルの最適化を行います。このレベルは、プログ
ラムの中でも、その実行にコンピュータ時間の大部分を
要する、ごく少量のコードに対してのみより長いコンパ
イル時間を要する最適化アルゴリズム、または実行時間
が確実に改善されるかが不明な最適化アルゴリズムを使
用します。このレベルでより確実にパフォーマンスを向
上させるには、プロファイルのフィードバックを使用し
てください。詳細については -xprofile=collect|use
のセクションを参照してください。
x86 プラットフォームの場合:
-xO1 単一パスのデフォルトの最適化に加えて、メモリーから
の引数の事前ロードと、クロスジャンプ (末尾融合) を
行います。
-xO2 高レベルと低レベル両方の命令をスケジューリングし、
改良されたスピルコードの解析、ループ中のメモリー参
照の除去、レジスタの有効期間解析、強化されたレジス
タ割り当て、大域的な共通部分式の除去を行います。
-xO3 -xO2 で行われる最適化に加えて、ループの強度低下と
帰納的変数の除去を行います。
-xO4 -xO3 レベルで行われる最適化レベルに加えて、同じ
ファイルに含まれる関数の自動的なインライン化を行い
ます。通常、この自動的なインライン化によって実行速
度が速くなりますが、遅くなることもあります。このレ
ベルでは、一般用途のフレームポインタレジスタ (edp)
の解放も行われます。一般に、このレベルを使用する
と、コードサイズが大きくなります。
警告: 直接かコールバック、割り込み、関数ポインタの
いずれで、C++ 例外で終了する可能性がある C++ 関数
を呼び出す可能性がある C コードのコンパイルでは、
-xO4 を指定しないでください。例外をスローする
C++ ルーチンはフレームポインタの存在を前提として
おり、フレームポインタがないとコアダンプします。
-xO5 最高レベルの最適化を行います。このレベルでは、コン
パイル時間が長くなる可能性があり、実行時間が確実に
改善されるかどうか不明な最適化アルゴリズムを使用し
ます。たとえば、エクスポートされた関数が局所的に呼
び出されるような関数の入口を設定する、スピルコード
を最適化する、命令スケジュールを向上するための解析
を追加するなどがあります。
デフォルトでは最適化を行いません。ただし、このデフォル
トの設定は、最適化レベルを指定しない場合のみ適用されま
す。最適化レベルを指定した場合には、最適化を行わないよ
うにすることはできません。
最適化レベルの設定を行いたくない場合には、最適化レベル
を指定したと見なされる可能性のあるオプションを指定しな
いようにしてください。たとえば、-fast は、最適化レベル
として -xO5 を設定するマクロオプションです。最適化レベ
ルを指定したと見なされる可能性のある他のすべてのオプ
ションは、最適化レベルが設定されたことを示す警告メッ
セージを表示します。最適化を行わずにコンパイルを行う唯
一の方法は、コマンド行からすべてのオプションを削除する
か、最適化レベルを指定する Make ファイルを削除すること
です。
-g を使用していて、最適化レベルが -xO3 以下の場合、コン
パイラは、ほぼ完全な最適化によって最大限のシンボル情報
を提供します。末尾呼び出しの最適化とバックエンドのイン
ライン化は無効です。
-g を使用していて、最適化レベルが -xO4 以上の場合、コン
パイラは、完全な最適化によって最大限のシンボル情報を提
供します。
-g オプション付きでデバッグしても -xOn に影響はありませ
んが、 -xOn によって、-g オプションが制限を受けます。た
とえば、最適化オプションを使用すると dbx からの変数を表
示できないといった、デバッグの機能の制限が発生します。
ただし、dbx where コマンドを使用してシンボルのトレース
バックを得ることはできます。詳細については『dbx コマン
ドによるデバッグ』を参照してください。
-xO と -xmaxopt の両方を指定する場合、 -xO で設定する最
適化レベルが -xmaxopt 値を超えてはいけません。
関連項目:
-xldscope、 -fast、 -xprofile=p、 csh(1) マニュアルペー
ジ
『プログラムのパフォーマンス解析』では、最適化の各レベ
ルがアナライザのデータに及ぼす影響について説明していま
す。
-xopenmp[=i]
(SPARC)
-xopenmp オプションを指定して、OpenMP 指令を使用して明
示的な並列化を行うことができます。
-xopenmp には以下の値を指定することができます。
parallel OpenMP プラグマを認識できるようにします。
-xopenmp=parallel を指定した場合の最適化レベル
は -x03 です。コンパイラは、必要に応じて最適化
レベルを -x03 に変更し、警告を発生します。
noopt OpenMP プラグマを認識できるようにします。最適
化レベルが -O3 よりも低い場合、コンパイラは最
適化レベルを上げません。cc -O2 -xopenmp=noopt
と指定し、 -O3 よりも低い最適化レベルを明示的
に設定した場合、コンパイラはエラーを発生させま
す。 -xopenmp=noopt を使用して最適化レベルを指
定しない場合、OpenMP プラグマは認識され、それ
に従ってプログラムの並列化が行われますが、最適
化は行われません。
stubs OpenMP プラグマの認識を無効にし、スタブライブ
ラリルーチンにリンクし、最適化レベルは変更しま
せん。OpenMP の実行時ライブラリルーチンを明示
的に呼び出すアプリケーションをコンパイルし、呼
び出しを直列に実行したい場合に、このオプション
を使用します。 -xopenmp=stubs コマンドは、
_OPENMP プリプロセッサトークンも定義します。
none OpenMP プラグマの認識を有効にせず、プログラム
の最適化レベルを変更せず、プリプロセッサトーク
ンの事前定義を行いません。
-xopenmp を値なしで指定すると、 -xopenmp=parallel を指
定したと見なされます。 -xopenmp の指定を省略すると、
-xopenmp=none を指定したと見なされます。
dbx を使用して OpenMP プログラムをデバッグする場合、 -g
-xopenmp=noopt を使用してコンパイルを行い、並列領域内に
ブレークポイントを設定し、変数の内容を表示することがで
きます。
-xopenmp を -xparallel または -xexplicitpar と共に指定
しないようにしてください。
将来のリリースでは、-xopenmp のデフォルトの設定が変更さ
れる可能性があります。適切な最適化レベルを指定すること
によって、警告メッセージの表示を防止することができま
す。
その実行可能ファイルのリンクで -xopenmp を使用する必要
があります。実行可能ファイルのコンパイラは、-xopenmp を
付けて .so を構築したコンパイラより古くてはいけません。
このことは、OpenMP 指令を含むライブラリをコンパイルする
とき特に重要です。
OpenMP の C における実装に固有の情報については、『C
ユーザーズガイド』を参照してください。
多重処理アプリケーションを構築するための OpenMP Fortran
95、C、C++ の API (Application Program Interface) の概
要については、『OpenMP API ユーザーズガイド』を参照して
ください。
-xP K&R C の関数のプロトタイプを表示するにあたって、ソース
ファイルに構文および意味上の検査のみ行います。このオプ
ションは、オブジェクトおよび実行可能コードのどちらも生
成しません。
-xpagesize=n
(SPARC) スタックとヒープの優先ページサイズを設定しま
す。
The n には、以下のいずれかの値を指定します。
8K、64K、512K、4M、32M、256M、2G、16G または default
対象となるプラットフォーム上の Solaris オペレーティング
環境で有効なページサイズを指定する必要があります。
getpagesize(3C) を使用するとそのサイズがわかります。有
効なページサイズを指定しなかった場合、その要求は実行時
に無視され、メッセージは出力されません。Solaris オペ
レーティングシステムでは、ページサイズ要求が優先される
ことを保証してはいません。
pmap(1) または meminfo(2) を使用して、対象となるプラッ
トフォームのページサイズを確認することができます。
-xpagesize オプションは、コンパイルおよびリンク時に使わ
ないと効果はありません。コンパイル時とリンク時の両方に
指定する必要があるコンパイラオプションの全一覧は、『C
ユーザーズガイド』を参照してください。
この機能は Solaris 8 オペレーティングシステムでは利用で
きません。このオプションを使ってコンパイルされたプログ
ラムは、Solaris 8 オペレーティングシステム上でリンクで
きません。
-xpagesize=default を指定すると、オペレーティング環境に
よってページサイズが設定されます。
このオプションを指定してコンパイルを行うと、同等のオプ
ションを使用して環境変数 LD_PRELOAD を設定するか、プロ
グラムの実行前に Solaris 9 のコマンド ppgsz(1) を同等の
オプションを指定して実行するのと同じ効果が得られます。
詳細については、Solaris 9 のマニュアルページを参照して
ください。
このオプションは、-xpagesize_heap と -xpagesize_stack
と同義のマクロです。この 2 つのオプションでは、
-xpagesize と同じく、8K、64K、512K、4M、32M、256M、2G、
16G、default という引数を指定することができます。
-xpagesize=n を使用して、この 2 つのオプションに同じ値
を設定することができます。また、2 つのオプションを個別
に指定し、異なる値を設定することもできます。
-xpagesize_heap=n
(SPARC) メモリー内でヒープ用に使用するページサイズを設
定します。 n には、次のいずれかを指定する必要がありま
す。8K、64K、512K、4M、32M、256M、2G、16G または
default。対象となるプラットフォームの Solaris オペレー
ティングシステムで有効なページサイズを指定しなければな
りません。この値は getpagesize(3C) で確認できます。有効
なページサイズを指定しなかった場合、その要求は実行時に
無視され、メッセージは出力されません。
pmap(1) または meminfo(2) を使用して、対象となるプラッ
トフォームのページサイズを確認することができます。
-xpagesize_heap=default を指定すると、Solaris オペレー
ティングシステムによってページサイズが設定されます。
このオプションを指定してコンパイルを行うと、同等のオプ
ションを使用して環境変数 LD_PRELOAD を設定するか、プロ
グラムの実行前に Solaris 9 のコマンド ppgsz(1) を同等の
オプションを指定して実行するのと同じ効果が得られます。
詳細については、Solaris 9 のマニュアルページを参照して
ください。
この機能は、Solaris 8 オペレーティングシステムでは使用
できないことに注意してください。このオプションを使用し
てコンパイルしたプログラムは、Solaris 8 ではリンクでき
ません。
コンパイル時とリンク時の両方に使用されない限り、
-xpagesize_heap オプションは、何の働きもしません。コン
パイル時およびリンク時両方に指定する必要があるコンパイ
ラオプションの全一覧は、『C ユーザーズガイド』を参照し
てください。
-xpagesize_stack=n
(SPARC) メモリー内でスタック用に使用するページサイズを
設定します。The n には、以下のいずれかの値を指定しま
す。8K、64K、512K、4M、32M、256M、2G、16G または
default。対象となるプラットフォーム上の Solaris オペ
レーティング環境で有効なページサイズを指定する必要があ
ります。 getpagesize(3C) を使用するとそのサイズがわかり
ます。有効なページサイズを指定しなかった場合、その要求
は実行時に無視され、メッセージは出力されません。
pmap(1) または meminfo(2) を使用して、対象となるプラッ
トフォームのページサイズを確認することができます。
-xpagesize_stack=default を指定すると、Solaris オペレー
ティング環境によってページサイズが設定されます。
このオプションを指定してコンパイルを行うと、同等のオプ
ションを使用して環境変数 LD_PRELOAD を設定するか、プロ
グラムの実行前に Solaris 9 のコマンド ppgsz(1) を同等の
オプションを指定して実行するのと同じ効果が得られます。
詳細については、Solaris 9 のマニュアルページを参照して
ください。
コンパイル時とリンク時の両方に使用されない限り、
-xpagesize_stack オプションは、何の働きもしません。コン
パイル時およびリンク時両方に指定する必要があるコンパイ
ラオプションの全一覧は、『C ユーザーズガイド』を参照し
てください。
この機能は、Solaris 8 オペレーティングシステムでは使用
できないことに注意してください。このオプションを使用し
てコンパイルしたプログラムは、Solaris 8 オペレーティン
グシステムではリンクできません。
-xparallel
(SPARC) コンパイラによる自動的な方法と明示指定による方
法の両方でループの並列化を行います。このオプションはマ
クロで、 -xautopar、 -xdepend、および
-xexplicitpar
の 3 つをすべて指定するのと同じです。明示的な並列化で
は、不正な結果が生じる危険性があります。
最適化レベルが -xO3 以下の場合は、レベルが -xO3 に引き
上げられて、警告が発行されます。
独自のスレッド管理を行う場合は、 -xparallel を使わない
でください。-xopenmp を指定する場合も、指定しないでくだ
さい。 -xparallel は、-xopenmp を指定した場合に発行され
てはならない -xexplicitpar を設定します。
コードの実行速度を高めるには、マルチプロセッサシステム
の SPARC システムでこのオプションを使ってください。シン
グルプロセッサシステムでは、通常、生成されたコードの実
行速度が低下します。
コンパイルとリンクを 1 度に実行した場合、-xparallel が
指定されていると、マイクロタスクライブラリとスレッド
セーフな C 実行時ライブラリを使ってリンクが行われます。
コンパイルとリンクを別々に行い、コンパイルで -xparallel
を指定する場合は、リンクでも -xparallel を指定します。
コンパイル時およびリンク時両方に指定する必要があるコン
パイラオプションの全一覧は、『C ユーザーズガイド』を参
照してください。
-xpch=v
このコンパイラオプションは、プリコンパイル済みヘッダー
機能を有効にします。v は、auto、autofirst、
collect:pch_filename、use:pch_filename のいずれかです。
-xpch および -xpchstop オプションを #pragma hdrstop 指
令と併用することによって、この機能の活かすことができま
す。
-xpch オプションを使用してプリコンパイル済みヘッダー
ファイルを作成し、コンパイル時間を短縮することができま
す。プリコンパイル済みヘッダーファイルは、ソースファイ
ルが大量のソースコードが含まれている複数のインクルード
ファイルを共有するアプリケーションのコンパイル時間を短
縮する目的で設計されています。プリコンパイル済みヘッ
ダーファイルを作成することによって、1 つのソースファイ
ルからヘッダーファイルに関する情報を収集し、そのソース
ファイルを再コンパイルする場合や同じヘッダーが記述され
ている他のソースファイルをコンパイルする場合にその情報
を使用することができます。
プリコンパイル済みヘッダーファイルの自動作成
コンパイル済みヘッダーファイルをコンパイラに自動的に生
成させることができます。方法は 2 通りあります。1 つは、
ソースファイルから最初に検出されたインクルードファイル
からプリコンパイル済みヘッダーファイルをコンパイラに作
成させる方法。もう 1 つは、ソースファイルから最初に検出
されたインクルードファイルから、最後のインクルードファ
イルを示す綿密な定義ポイントに基づいて決定される範囲か
らコンパイラにインクルードファイルを選択させる方法で
す。次の 2 つのフラグのいずれかを使って、プリコンパイル
済みヘッダーの自動生成でコンパイラが使用する方法を指定
します。
-xpch=auto
プリコンパイル済みヘッダーファイルの内容は、コンパ
イラがソースファイルから検出したうちで最も長い活性
文字列 (viable prefix) に基づいています (活性文字
列の識別方法については、次のセクションを参照)。こ
のフラグは、最大可能数のヘッダーファイルからなるプ
リコンパイル済みヘッダーファイルを生成します。
-xpch=autofirst
このフラグは、ソースファイルから最初に検出された
ヘッダーのみを含むプリコンパイル済みヘッダーファイ
ルを生成します。
プリコンパイル済みヘッダーファイルの手動作成
プリコンパイル済みヘッダファイルを手動で作成する場合
は、-xpch
を使用し、その後で collect モードを指定する必要があり
ます。 -xpch=collect を指定するコンパイルコマンドでは、
ソースファイルを 1 つだけ指定する必要があります。次の例
では、-xpch オプションによって、ソースファイル a.c に基
づいて myheader.cpch というプリコンパイル済みヘッダー
ファイルが作成されます。
cc -xpch=collect:myheader a.c
有効なプリコンパイル済みヘッダーファイルのファイル名に
は、接尾辞を自分で付けることができます。省略すると、コ
ンパイラによって自動的に付けられます。たとえば、cc
-xpch=collect:foo a.c と指定すると、プリコンパイル済み
ヘッダーファイルの名前は foo.cpch になります。
コンパイラによる既存のプリコンパイル済みヘッダーファイ
ルの取り扱い
-xpch=auto および -xpch=autofirst のときにプリコンパイ
ル済みヘッダーファイルを使用できない場合、コンパイラは
新しいプリコンパイル済みヘッダーファイルを生成します。
-xpch=use のときにプリコンパイル済みヘッダーファイルを
使用できない場合は、警告が発行され、実際のヘッダーを
使ってコンパイルが行われます。
特定のプリコンパイル済みヘッダーファイルの使用の指示
特定のプリコンパイル済みヘッダーファイルを使用するよう
コンパイラに指示することもできます。プリコンパイル済み
ヘッダーファイルを使用するには、 -xpch=use:pch_filename
を指定します。プリコンパイル済みヘッダーファイルの作成
に使用したソースファイルと同じインクルードファイルを使
用するソースファイルをいくつでも指定できます。たとえ
ば、プリコンパイル済みヘッダーファイルを使用するコマン
ドは次のようになります。
cc -xpch=use:foo.cpch foo.c bar.c foobar.c
以下の項目がすべて当てはまる場合には、既存のプリコンパ
イル済みヘッダーファイルのみを使用します。1 つでも当て
はまらない項目がある場合には、プリコンパイル済みヘッ
ダーファイルを再度作成します。
- プリコンパイル済みヘッダーファイルの作成に使用したコ
ンパイラを使用して、プリコンパイル済みヘッダーファイル
にアクセスする。プリコンパイル済みヘッダーファイルは、
その作成に使用したコンパイラとバージョンが異なるコンパ
イラからはアクセスできない場合があります。
- -xpch オプションを除いて、-xpch=use を使用して指定す
るコンパイラオプションは、プリコンパイル済みヘッダー
ファイルの作成時に指定したオプションと同じでなければな
らない。
- -xpch=use を使用して指定するインクルード済みヘッダー
は、プリコンパイル済みヘッダーの作成時に指定したヘッ
ダーと同じでなければならない。
- -xpch=use を使用して指定するインクルード済みヘッダー
の内容は、プリコンパイル済みヘッダーの作成時に指定した
インクルード済みヘッダーの内容と同じでなければならな
い。
- カレントディレクトリ (コンパイルを行い、指定したプリ
コンパイル済みヘッダーファイルを使用するディレクトリ)
が、プリコンパイル済みヘッダーファイルを作成したディレ
クトリと同じである。
- -xpch=collect を使用して指定したファイル内の事前処理
指令 (#include 指令を含む) の順序が、 -xpch=use を使用
して指定したファイル内の事前処理指令の順序と同じであ
る。
活性文字列 (Viable Prefix)
複数のソースファイル間でプリコンパイル済みヘッダーファ
イルを共有するには、それらのソースファイルが、その初期
トークンシーケンスして共通のインクルードファイル群を共
有している必要があります。トークンは、キーワードや名
前、および適切な記号の組み合わせから成ります。コンパイ
ラは、コメントおよび、#if 指令によって除外されている
コードをトークンとして認識しません。この初期トークン
シーケンスは、活性文字列と呼ばれます。言い替えれば、活
性文字列は、すべてのソースファイルの先頭に共通に存在す
る部分です。コンパイラは、プリコンパイル済みヘッダー
ファイルを作成し、ソースからプリコンパイルされている
ヘッダーファイルを特定する際の基礎情報としてこの活性文
字列を利用します。
現在のコンパイル中にコンパイラが検出する活性文字列は、
プリコンパイル済みヘッダーファイルの作成に使用された活
性文字列と一致している必要があります。言い替えれば、同
じプリコンパイル済みヘッダーファイルを使用しているどの
ソースファイルについても、コンパイラがその活性文字列の
一貫した解釈ができる必要があります。
活性文字列は、次のプリプロセッサ指令のいずれかで構成さ
れます。
#include
#if/ifdef/ifndef/else/elif/endif
#define/undef
#ident
#pragma
これらの指令は、マクロを参照することができます。#else、
#elif、#endif は、活性文字列内で適切に組み合わせて使用
する必要があります。コメントは無視されます。
-xpch=auto か -xpch=autofirst が指定されていて、活性文
字列が次のように定義されている場合、コンパイラは自動的
に活性文字列の終わりを特定します。 -xpch=collect または
-xpch=use の場合、活性文字列は #pragma hdrstop で終わ
る。
- 最初の宣言/定義文
- 最初の #line 指令
- #pragma hdrstop 指令
- -xpch=auto および -xpchstop が指定されている場合は、
指定されているインクルードファイルの後
- -xpch=autofirst が指定されている場合は最初のインク
ルードファイル
注: 条件文内に終わりがある場合は、警告が生成され、プリ
コンパイル済みヘッダーファイルの自動作成は無効になりま
す。また #pragma hdrstop
と -xpchstop オプションの両方が指定されている場合、コ
ンパイラは 2 つの停止点のうちの前の方を使って、活性文字
列を終了します。
プリコンパイル済みヘッダーファイルを共有する各ファイル
の活性文字列内では、対応する #define、#undef 指令はそれ
ぞれ同じシンボルを参照する必要があります (#define の場
合、それぞれが同じ値を参照する必要があります)。また、そ
れぞれの活性文字列内での登場の順序も同じでなければなり
ません。また、プリコンパイル済みのヘッダーを共有するす
べてのファイルにおいて、対応するプラグマは同じであり、
同じ順番で登場する必要があります。
ヘッダーファイルの妥当性の判定
ヘッダーファイルがプリコンパイル可能となる条件。それ
は、どのソースファイルでも、ヘッダーファイルの一貫した
解釈ができることです。具体的には、完全な宣言だけが含ま
れていることです。すなわち、どのファイルの宣言も有効な
宣言として独立している必要があります。struct S; などの
不完全な型宣言は有効な型宣言です。この完全な型宣言は他
のファイルに存在している可能性があります。次のヘッダー
ファイル例を参考にしてください。
file a.h
struct S {
#include "x.h" /* not allowed */
};
file b.h
struct T; // ok, complete declaration
struct S {
int i;
[end of file, continued in another file] /* not allowed
*/
プリコンパイル済みヘッダーファイルに組み込まれるヘッ
ダーファイルは、以下の条件を満たす必要があります。条件
を満たさないプログラムのコンパイル結果は不定です。
- ヘッダーファイルでは、__DATE__ と __TIME__ を使用して
はならない。
- ヘッダーファイルには、#pragma hdrstop を含めてはなら
ない。
プリコンパイル済みヘッダーファイルのキャッシュ
プリコンパイル済みヘッダーファイルを自動的に作成したと
き、コンパイラはそのファイルを SunWS_cache ディレクトリ
に書き込みます。このディレクトリはつねに、オブジェクト
ファイルが作成される場所に置かれます。dmake の下で適切
に機能するよう、ファイルの更新はロックして行われます。
強制的に再構築させる必要がある場合は、CCadmin ツールを
使って、この PCH キャッシュディレクトリをクリアすること
ができます。詳細は、CCadmin(1) のマニュアルページを参照
してください。
警告
o 矛盾する -xpch フラグをコマンド行に指定してないでくだ
さい。たとえば -xpch=collect と -xpch=auto の両方を指定
したり、 -xpchstop=<include> を付けて -xpch=autofirst
を指定したりすると、エラーになります。
o -xpch=autofirst を指定するか、-xpchstop なしで
-xpch=auto を指定した場合、最初のインクルードファイル、
あるいは -xpch=auto に -xpchstop を付けて指定したインク
ルードファイルの前に宣言や定義、#line 指令があると、エ
ラーになり、プリコンパイル済みヘッダーファイルの自動生
成が無効になります。
o -xpch=autofirst または -xpch=auto で、最初のインク
ルードファイルの前に #pragma hdrstop があると、プリコン
パイル済みヘッダーファイルの自動生成が無効になります。
プリコンパイル済みヘッダーファイルの依存関係とメーク
ファイル
-xpch=collect が指定されている場合、コンパイラはプリコ
ンパイル済みヘッダーファイル用の依存関係情報を生成しま
す。この依存関係情報を活用するには、make ファイル内に適
切な規則を作成する必要があります。次の make ファイル例
を参考にしてください。
%.o : %.c shared.cpch
$(CC) -xpch=use:shared -xpchstop=foo.h -c $<
default : a.out
foo.o + shared.cpch : foo.c
$(CC) -xpch=collect:shared -xpchstop=foo.h foo.c -c
a.out : foo.o bar.o foobar.o
$(CC) foo.o bar.o foobar.o
clean :
rm -f *.o shared.cpch .make.state a.out
コンパイラによって生成された依存関係情報とともに、これ
らの make 規則があると、-xpch=collect で使用されたソー
スファイル、またはプリコンパイル済みヘッダーファイルを
構成するヘッダーのどれかに変更があった場合、手動で作成
されたプリコンパイル済みヘッダーファイルが強制的に再作
成されます。これにより、古いプリコンパイル済みヘッダー
ファイルの使用が防止されます。
-xpch=auto または -xpch=autofirst ではメークファイルに
追加の
make 規則を作成する必要はありません。
関連項目: -xpchstop
-xpchstop=[file|<include>]
file には、プリコンパイル済みヘッダーファイルの作成時に
最後に使用されるインクルードファイルを指定します。コマ
ンド行で -xpchstop を使用すると、cc コマンドを使用して
指定したソースファイルでファイルを参照する最初のインク
ルード指令の後ろに hdrstop プラグマ (『C ユーザーズガイ
ド』を参照) を配置するのと同じ結果になります。
<include> までのヘッダーファイルに基づくプリコンパイル
済みヘッダーファイルを作成するには、-xpchstop=<include>
と
-xpch=auto を組み合わせます。このフラグは、可変接頭部
全体に含まれているすべてのヘッダーファイルを使用するデ
フォルトの -xpch=auto の動作に優先します。
関連項目: -xpch, -xhelp=readme
-xpentium
(x86) Pentium プロセッサ用のコードを生成します。
-xpg gprof(1) を使ってプロファイリングするためのデータを収集
するオブジェクトコードを作成します。正常終了時にファイ
ル gmon.out を生成する実行時記録メカニズムを呼び出しま
す。
-xprefetch[=val[,val]]
(SPARC) 先読みをサポートしている UltraSPARC II などの
アーキテクチャ (-xarch=v8plus、 v9plusa、 v9、 v9a のい
ずれか) において、先読み命令を有効にします。
明示的な先読みは、パフォーマンスが実際に向上する特別な
環境だけで使用してください。
val には次のうちの 1 つを指定します。
auto 先読み命令の自動生成を有効にします。
no%auto 先読み命令の自動生成を無効にします。
explicit 明示的な先読みマクロを有効にします。
no%explicit 明示的な先読みマクロを無効にします。
latx:factor このオプションは、-xprefetch=auto との併
用できます。コンパイラによるロード命令と
ストア命令に対する先読み命令の、「潜在期
間」の仮定値を、指定された係数 (factor)
で調整します。factor は、 n.n という形式
の整数でなければなりません。
先読み命令の「潜在期間」とは、先読み命令
が実行された時点から、先読み命令の対象で
あるデータが実際にキャッシュに入れられる
時点までの、ハードウェアに起因する時間の
ずれを指します。
コンパイラは、先読み命令の挿入位置と、先
読みされたデータを使用するロードまたはス
トアの命令文の位置がどれだけ離れているか
を確認して、先読みの潜在期間を仮定しま
す。
注意 - 仮定される先読みの潜在期間は、
ロード命令とストア命令では異なる場合があ
ります。
コンパイラは、広範囲に渡るマシンおよびア
プリケーションに対して適切になるように、
先読みのメカニズムを調整しています。この
ため現在の機能が、すべてのマシンまたはア
プリケーションで最良であるとは限りませ
ん。メモリーを大量に消費するアプリケー
ション、特に大規模な複数のプロセッサで実
行するアプリケーションの場合は、先読みの
潜在期間を示す値を増加させた方が、パ
フォーマンスが向上する可能性があります。
先読みの潜在期間を増加させるには、 fac-
tor の値を 1 より大きい値にします。 .5
から 2.0 の間の値にすると、ほぼ確実に最
高のパフォーマンスが得られます。
完全に外部のキャッシュに存在するデータ
ベースを扱うアプリケーションの場合は、先
読みの潜在期間を減少させた方が、パフォー
マンスが向上する可能性があります。先読み
の潜在期間を減少させるには、 factor の値
を 1 より小さい値にします。
latx:factor サブオプションを使用する場合
は、まず factor の値を 1.0 に近い値に設
定して、対象のアプリケーションに対するパ
フォーマンスを調べます。そして徐々にその
値を変化させていき、パフォーマンスの変化
を確認します。最良のパフォーマンスが得ら
れるまでテストを繰り返し、適切な factor
の値を特定します。 factor の値を細かく変
更した場合は、しばらくの間パフォーマンス
の変化はまったく見られませんが、ある値で
突然高くなります。続けて値を増加または減
少させていくと、パフォーマンスは再び下が
ります。
yes 旧式 - 使わないでください。代わりに
-xprefetch=auto,explicit を使ってくださ
い。
no 旧式 - 使わないでください。代わりに
-xprefetch=no%auto,no%explicit を使って
ください。
デフォルト
-xprefetch を指定しなかった場合のデフォルトは、
-xprefetch=yes ではなく -xprefetch=auto,explicit に変更
されています。 -xprefetch_auto_type に値が指定されな
かった場合も、-xprefetch=auto,explicit と同等です。この
変更は、基本的に非リニアのメモリーアクセスパターンを
持っているアプリケーションに良くない影響を及ぼします。
この変更を無効にするには、
-xprefetch=no%auto,no%explicit を指定します。
The sun_prefetch.h ヘッダーファイルには、明示的な先読み
命令を指定するために使用できるマクロが含まれています。
先読み命令は実行コードにおいて、マクロの位置に対応する
場所の付近に挿入されます。
-xprefetch_auto_type=[a]
(SPARC) a は [no%]indirect_array_access です。
このオプションは、直接メモリーアクセス用の先読み命令の
生成と同じようにして、コンパイラに -xprefetch_level オ
プションの指示するループに対して間接先読みを生成させる
かどうかを指定するのに使用します。
-xprefetch_auto_type に値が指定されなかった場合、コンパ
イラは -xprefetch_auto_type=no%indirect_array_access に
設定します。
メモリー使用に関する別名解析のあいまいさを排除できる可
能性が高まるため、 -xdepend、-xrestrict、-xalias_level
などのオプションが、間接先読み命令の候補の計算の積極
性、つまりは、自動的な間接先読み命令の挿入の積極性に影
響することがあります。
-xprefetch_level=l
(SPARC) -xprefetch=auto によって決定された prefetch 文
の自動挿入の程度を制御するには、このオプションを使用し
ます。
l は 1、2、3 のいずれかです。
最適化レベル 3 以上でコンパイルするか、prefetch をサ
ポートするプラットフォーム (v8plus、v8plusa、v9、v9a、
v9b、generic64、native64) のコードを生成する必要があり
ます。
-xprefetch_level=1 を指定すると、prefetch の自動生成が
可能になります。 -xprefetch_level=2 を指定すると、レベ
ル 1 を超える追加生成が可能になり、 -xprefetch=3 を指定
すると、レベル 2 を超える追加生成が可能になります。
-xprefetch=auto を指定する場合、デフォルトは
-xprefetch_level=1 です。
-xprofile=p
プロファイル用のデータを収集する、または最適化を行うた
めにプロファイルを使用します。
p には、 collect[:<名前>] 、 use[:<名前>] または tcov
を指定します。
このオプションを使用すると、実行時に実行頻度のデータが
収集されて保存されます。このデータは以降の実行パフォー
マンスを向上させるために使用することができます。プロ
ファイルの収集は、マルチスレッドアプリケーションを使用
した場合であっても安全です。マルチタスク (-mt) を実行す
るプログラムを使用した場合、正確な結果が得られます。こ
のオプションは、-xO2 以上のレベルの最適化を指定する場合
にのみ有効です。
コンパイルとリンクを別の段階で行う場合、コンパイル時に
は、リンクの段階で使用したものと同じ -xprofile オプショ
ンを使用しなければなりません。
collect[:<名前>]
-xprofile=use で使用できるように、実行頻度の情報を
収集および保存します。コンパイラは、文の実行頻度を
測定するためのコードを生成します。
<名前> には、実行頻度のフィードバックデータを格納
する .profile ディレクトリの名前を指定します。この
名前の指定は省略可能です。<名前> の指定を省略する
と、実行可能ファイルの名前 (-o オプションで指定し
た名前、または -o オプション省略時は a.out) に接尾
辞 .profile を付けた名前のサブディレクトリが、プロ
グラムを実行したディレクトリに作成されます。
-xprofile=collect でコンパイルされたプログラムがプ
ロファイルデータを保存するのを制御するために、環境
変数 SUN_PROFDATA および SUN_PROFDATA_DIR を設定で
きます。設定すると、-xprofile=collect データは
SUN_PROFDATA_DIR/SUN_PROFDATA に書き込まれます。
この環境変数は、 tcov により記述されたプロファイル
データファイルのパスと名前を、tcov(1) のマニュアル
ページに記述されているのと同様に制御します。
この環境変数が設定されていない場合、プロファイル
データはカレントディレクトリの
name.profile/feedback に書き込まれます。ここで、
name は実行可能ファイル、または
-xprofile=collect:name フラグに指定された名前で
す。 -xprofile は name がすでに .profile で終了し
ている場合に、name に .profile を付加しません。プ
ログラムを複数回実行した場合、実行頻度のフィード
バックデータはフィードバックファイルに蓄積されるの
で、前回のデータは失われません。
コンパイルとリンクを別々のステップで行う場合には、
-xprofile=collect を使用してコンパイルしたオブジェ
クトファイルも -xprofile=collect を使用してリンク
する必要があります。コンパイル時とリンク時の両方に
指定する必要があるコンパイラオプションの全一覧は、
『C ユーザーズガイド』を参照してください。
use[:<名前>]
実行頻度データを利用して、有効に最適化を行います。
<名前> には、フィードバックデータが格納されている
.profile ディレクトリの名前を指定してください。こ
の名前は省略可能です。<名前> の指定を省略すると、
a.out.profile がフィードバックデータのあるディレク
トリとみなされます。
-xprofile=collect でコンパイルしたプログラムを前回
実行した結果として feedback ファイルに生成および保
存された実行頻度データをもとにして、プログラムが最
適化されます。
-xprofile オプションを除いて、ソースファイルおよび
その他のコンパイラオプションは、feedback ファイル
を生成したコンパイル済みプログラムを生成したコンパ
イル時に使用されたオプションと同じものを指定する必
要があります。collect ビルドと use ビルドには同じ
コンパイラバージョンを使用しなければなりません。
-xprofile=collect:<名前> でコンパイルした場合、最
適化コンパイルでは同じ <名前>、すなわち
-xprofile=use:<名前> を指定する必要があります。
collect 段階と use 段階の間のコンパイルの高速化に
ついては、-xprofile_ircache も参照してください。
tcov 新しい形式の tcov を使用した基本的なブロックカバ
レージ分析を行います。
-xprofile=tcov オプションは、tcov のプロファイルの
作成に使用する新しい形式の基本ブロックです。 -xa
オプションと同じ機能がありますが、ヘッダーファイル
にソースコードが含まれているプログラムのデータを正
確に収集します。旧形式のプロファイルについての詳細
は、tcov(1) のマニュアルページ、および『プログラム
のパフォーマンス解析』を参照してください。
コード生成は -xa オプションと同じように実行されま
すが、.d ファイルは生成されません。代わりに単一の
ファイルが生成されます。ファイル名は、対応する実行
可能形式のファイルの名前にもとづいて付けられます。
たとえば、プログラムが /foo/bar/myprog.profile か
ら実行されている場合、データファイルは
/foo/bar/myprog.profile/myprog.tcovd に格納されま
す。
-xprofile=tcov および -xa オプションは、1 つの実行
可能ファイル内で両方を指定することができます。すな
わち、-xprofile=tcov オプションでコンパイルされた
ファイルと、 -xa オプションでコンパイルされたファ
イルをリンクして、プログラムを作成することができま
す。1 つのファイルで両方のオプションを使用してコン
パイルすることはできません。
tcov を実行する時には、新しい形式のデータが使用さ
れるように -x オプションを指定してください。指定し
ない場合、tcov は旧式の .d ファイル(存在する場合)
を使用します。この場合は、予想外の結果が生じること
があります。
-xa オプションとは異なり、TCOVDIR 環境変数はコンパ
イル時間には影響しません。ただし、この環境変数の値
はプログラムの実行時に使用されます。詳細は、
tcov(1) のマニュアルページおよび『プログラムのパ
フォーマンス解析』を参照してください。
注: -xO4 以上の最適化または -xinline を使用したた
めに関数のインライン化が存在する場合、tcov のコー
ドカバレージ解析のデータは不正確になる可能性があり
ます。
-xprofile=collect を使用してプロファイル収集用プログラ
ムをコンパイルし、 -xprofile=use を使用してプロファイル
フィードバック用プログラムをコンパイルする場合、ソース
ファイルと、-xprofile=collect および -xprofile=use 以外
のコンパイラオプションは、どちらのコンパイルでも同じで
なければなりません。
-xprofile=use:<名前> オプションにより指定されるプロファ
イルフィードバックディレクトリ名は、コンパイラの 1 回の
起動におけるすべてのオプションのインスタンスから累積さ
れます。たとえば、プロファイルディレクトリ a.profile、
b.profile、および c.profile が、プロファイルされたバイ
ナリ名 a、b、c の実行結果として作成されたとします。
cc -O -c foo.c -xprofile=use:a -xprofile=use:b -xprofile=use:c
3 つのプロファイルディレクトリがすべて使用されます。特
定のオブジェクトファイルに属す有効なプロファイルフィー
ドバックデータは、オブジェクトファイルがコンパイルされ
ると、指定されたフィードバックディレクトリから累積され
ます。
-xprofile=collect と -xprofile=use が同じコマンド行に指
定されると、コマンド行の右端の -xprofile オプションが以
下のように適用されます。
右端の -xprofile オプションが -xprofile=use の場合、
-xprofile=use オプションにより指定されるすべてのプロ
ファイルフィードバックディレクトリ名は、フィードバック
指定最適化に使用され、その前の -xprofile=collect オプ
ションは無視されます。
右端の -xprofile オプションが -xprofile=collect の場
合、 -xprofile=use オプションにより指定されるすべてのプ
ロファイルフィードバックディレクトリ名が無視され、プロ
ファイル生成の計測が有効になります。
-xprofile_ircache[=path]
(SPARC) -xprofile_ircache[=path] と
-xprofile=collect|use を使用して、収集段階に保存したコ
ンパイルデータを再利用し、使用段階においてコンパイル時
間を短縮することができます。
大きなプログラムでは、中間データが保存されるため、使用
段階におけるコンパイル時間が大幅に短縮されます。データ
を保存するので、必要なディスク空間が大幅に増加する可能
性があることに注意してください。
-xprofile_ircache[=path] を指定すると、キャッシュファイ
ルの保存場所ではなく path が使用されます。デフォルトで
は、キャッシュファイルはオブジェクトファイルと同じ場所
に保存されます。収集段階と使用段階で使用するディレクト
リが異なる場合、パスを指定すると便利です。
典型的なコマンドの流れを以下に示します。
example% cc -xO5 -xprofile=collect -xprofile_ircache t1.c t2.c
example% a.out // フィードバックデータの収集を実行
example% cc -xO5 -xprofile=use -xprofile_ircache t1.c t2.c
-xprofile_pathmap=collect_prefix:use_prefix
(SPARC) -xprofile_pathmap オプションは、-xprofile=use
コマンドの指定時に使用します。以下の 2 つの条件が当ては
まり、 -xprofile=use を指定してコンパイルしたオブジェク
トファイルのプロファイルデータをコンパイラが検出できな
い場合、 -xprofile_pathmap を使用します。
o 以前に -xprofile=collect を使用してオブジェクトファ
イルをコンパイルしたディレクトリとは異なるディレクト
リで -xprofile=use を使用してオブジェクトファイルを
コンパイルする。
o プロファイル内で、オブジェクトファイルは共通のベース
名を持つが、保存されているディレクトリによって区別さ
れる。
collect-prefix には、-xprofile=collect を使用してオブ
ジェクトファイルのコンパイルを行なったディレクトリの
UNIX パス名の接頭辞を指定します。
use-prefix には、-xprofile=use を使用してオブジェクト
ファイルのコンパイルを行うディレクトリの
UNIX パス名の接頭辞を指定します。
-xprofile_pathmap を複数指定すると、指定した順番に処理
が行われます。-xprofile_pathmap に指定された use-prefix
は、オブジェクトファイルのパス名と比較されます。比較
は、オブジェクトファイルのパス名と一致する use-prefix
が見つかるまで、または、最後に指定された use-prefix に
達し、一致がなくなるまで行われます。
-xreduction
(SPARC) 自動並列化の縮約のループを分析します。このオプ
ションは、 -xautopar または -xparallel が同時に指定され
ている場合に限り有効になります。これ以外の場合、コンパ
イラは警告を出します。
縮約の認識が有効になっている場合、コンパイラはドット
積、最大値と最小値の検出などの縮約を並列化します。これ
らの縮約の結果は、並列化していないコードで得られる値を
四捨五入した結果とは異なります。
-xregs=r[,r...]
生成されたコードでのレジスタの使用方法を指定します
(SPARC のみ)。
r には [no%]appl と [no%]float の 1 つまたは両方をコン
マで区切って指定します。
例: -xregs=appl,no%float
-xarch の各値に対する -xregs の意味は次のとおりです。
[no%]appl
アプリケーションレジスタをスクラッチレジスタと
して使用するコードをコンパイラが生成することを
許可します[しません]。アプリケーションレジスタ
は以下のとおりです。
g2, g3, g4 (v8a, v8, v8plus, v8plusa, v8plusb)
g2, g3 (v9, v9a, v9b)
すべてのシステムソフトウェアとライブラリは必ず
-xreg=no%appl を使用してコンパイルしてくださ
い。システムソフトウェア (共用ライブラリを含む
) は、アプリケーションに対してこれらのレジスタ
値を保持する必要があります。これらの値の使用は
コンパイルシステムにより制御され、アプリケー
ション全体で一貫していなければなりません。
SPARC ABI では、これらのレジスタはアプリケー
ションレジスタと表現されます。これらのレジスタ
を使用すると、必要なロード、ストア命令の数が減
るので、パフォーマンスが向上します。ただし、こ
のような使用は、アセンブリコードで記述された古
いライブラリプログラムの一部と衝突する場合があ
ります。
SPARC の命令セットの詳細については、 -xarch の
節を参照してください。
[no%]float
コンパイラが浮動小数点レジスタを整数値のスク
ラッチレジスタとして使用してコードを生成するこ
とを許可します[しません]。このオプションの指定
の有無にかかわらず、浮動小数点値を使用すると、
これらのレジスタが使用される可能性があります。
浮動小数点レジスタに対するすべての参照をコード
から排除する場合は、 -xregs=no%float を使用す
るのとともに、決して浮動小数点型をコードで使わ
ないようにする必要があります。
デフォルトは -xregs=appl,float です。
アプリケーションとリンクする共用ライブラリ用のコード
は、必ず -xregs=no%appl,float を使用してコンパイルして
ください。ライブラリとリンクするアプリケーションが問題
の対処方法を理解できるように、少なくとも共用ライブラリ
にはアプリケーションレジスタの使用法を明示的に文書化し
てください。
たとえば、レジスタを広域的に使用する (たとえばレジスタ
を使って重要なデータ構造をポイントする) アプリケーショ
ンは、-xregs=no%appl を使用しないでコンパイルされたコー
ドを持つライブラリに安全にリンクするために、そのライブ
ラリがアプリケーションレジスタをどのように使用するかを
正確に知る必要があります。
-xrestrict[=f]
(SPARC) ポインタ値の関数引数を制限付き (restricted) ポ
インタとして扱います。f には、%all、%none または、1 つ
または複数の関数名をコンマで区切ったリストを指定しま
す。このコマンド行オプションは、単独でも使用できます
が、-xO3 以上の最適化レベルと共に使用するのが最適です。
このオプションに関数リストが指定されると、指定された関
数内のポインタパラメータは制限付きとして扱われます。
-xrestrict=%all が指定されると、C ファイル全体のすべて
のポインタパラメータが制限付きとして扱われます。
デフォルト値は %none です。-xrestrict を指定するのは、
-xrestrict=%all を指定することと同等です。
関連項目:『C ユーザーズガイド』の「制限付きポインタ」
-xs dbx がオブジェクトファイルなしでデバッグを行うことを許
可します。
このオプションを指定すると、すべてのデバッグ情報が実行
可能ファイルにコピーされます。dbx のパフォーマンスやプ
ログラムの実行時パフォーマンスへの影響はほとんどありま
せんが、ディスクの使用量が増加します。
-xsafe=mem
(SPARC プラットフォーム) メモリー保護違反が発生しないこ
とを前提として、コンパイラを動作させます。
このオプションは、コンパイラが、SPARC V9 アーキテクチャ
で障害発生を想定しないロード命令を使用することを許可し
ます。
障害発生を想定しないロード命令は、アドレス割り当ての失
敗やセグメント違反のような障害が発生した場合でも、ト
ラップを発生させません。そのためこのオプションは、その
ような障害が起こり得ないプログラムでのみ使用してくださ
い。メモリーに基づいたトラップを発生させるプログラムは
ごく少数なので、このオプションはほとんどのプログラムで
安全に使用できます。しかし、例外的な状態を処理するため
に、メモリーに基づいたトラップを明示的に使用しているプ
ログラムでは、このオプションは使用しないでください。
このオプションは、 -xO5 の最適化レベルで、かつ、次のい
ずれかの値をとる -xarch オプションと一緒に使用された場
合にのみ有効です。
v8plus、 v8plusa、 v8plusb、 v9、 v9a、 v9b
-xsb このオプションを使用して、ソースブラウザのシンボルテー
ブルの追加情報を生成することができます。このオプション
は、 -Xs モードとの互換性はありません。
コンパイルとリンクを別々のステップで行う場合、コンパイ
ルステップとリンクステップの両方で -xsb を指定しない
と、リンカーがエラーメッセージを表示します。コンパイル
時とリンク時の両方に指定する必要があるコンパイラオプ
ションの全一覧は、『C ユーザーズガイド』を参照してくだ
さい。
-xsb を指定して、-xsb を使用してコンパイルしたオブジェ
クトへのリンクを行わない場合、ソースブラウザのデータの
参照はリンクステップで作成した実行可能ファイルからしか
行えません。また、コンパイルステップとリンクステップの
両方で -xsb を指定しないと、ソースブラウザデータベース
中のシンボル参照の一部が失われる可能性があります。
コンパイルステップとリンクステップの両方で -xsb を使用
する場合には次の点に留意してください。オブジェクトが同
じディレクトリ内で異なる方法でコンパイルされ、異なる実
行可能ファイルにリンクされる場合には、ソースブラウザで
両方のオブジェクト内のすべてのシンボル参照が見えるよう
にする必要があります。
-xsbfast
ソースブラウザ用データベースを作成しますが、実際にはコ
ンパイルしません。このオプションは、コンパイラの -Xs
モードが指定されていると、無効になります。
-xsfpconst
接尾辞を持たない浮動小数点定数を、デフォルトモードの倍
精度ではなく、単精度として表現します。これは、 -Xc と共
に使用することはできません。
-xspace
コードサイズを拡大するような最適化や並列化を行いませ
ん。たとえば、ループの展開は行いません。
-xstrconst
デフォルトのデータセグメントではなくテキストセグメント
の読み出し専用データセクションに、文字列リテラルを挿入
します。重複する文字列は削除され、残りのコピーはコード
の参照に共有されます。
-xtarget=t
命令セットと最適化の対象となるシステムを指定します。
t には、 native、 generic、 <システム名> のいずれか 1
つを指定します。
-xtarget オプションを使用すると、実際のシステムで発生す
る -xarch、 -xchip、および -xcache の組み合わせを容易に
指定することができます。 -xtarget の意味は、= の後に指
定した値を展開したものにあります。
-xtarget=native と指定するのは、-xarch=native,
-xchip=native, -xcache=native と指定することと同じで
す。
-xtarget=generic と指定するのは、-xarch=generic,
-xchip=generic, -xcache=generic と指定することと同じで
す。
-fast マクロオプションには、 -xtarget=native が含まれて
います。
-xtarget コマンド自体は、コマンド行において -xarch、
-xchip、および -xcache オプションをマクロ展開します。し
たがって、 -xtarget の後に必要なオプションを指定すれ
ば、マクロに含まれるオプションの設定を変更できます。
fpversion(1) コマンドを使用して、動作中のシステムにおけ
る -xtarget=native の展開を確認することができます。 注:
ホストプラットフォームによっては、コンパイルの際に
-xtarget=native を指定しても、-xarch、-xchip、または
-xcache が同じ設定にならない場合があります。
SPARC の -xtarget では以下の値を指定することができま
す。
native 現在のホスト環境 (32 ビット環境と仮定する) で
良好なパフォーマンスを得られるようにパラメータ
を設定します。
generic ほとんどの 32 ビットプラットフォームアーキテク
チャで良好なパフォーマンスを得られるようにパラ
メータを設定します。これがデフォルトです。
<システム名>
指定されたシステムについて最高のパフォーマンス
を得ます。
SPARC で使用できるシステム名は次のとおりです。
sun4/15、sun4/20、sun4/25、sun4/30、sun4/40、
sun4/50、sun4/60、sun4/65, sun4/75、sun4/110、
sun4/150、sun4/260、sun4/280、sun4/330、
sun4/370, sun4/390、sun4/470、sun4/490、
sun4/630、sun4/670、sun4/690、sselc、ssipc、
ssipx、sslc、sslt、sslx、sslx2、ssslc、ss1、
ss1plus、ss2、ss2p、ss4、ss4/85、ss4/110、
ss5、ss5/85、ss5/110、ssvyger、ss10、
ss10/hs11、ss10/hs12、ss10/hs14, ss10/20、
ss10/hs21、ss10/hs22、ss10/30、ss10/40、
ss10/41、ss10/50、ss10/51, ss10/61、ss10/71、
ss10/402、ss10/412、ss10/512、ss10/514、
ss10/612, ss10/712、ss20、ss20/hs11、
ss20/hs12、ss20/hs14、ss20/hs21、ss20/hs22,
ss20/50、ss20/51、ss20/61、ss20/71、ss20/151、
ss20/152、ss20/502、ss20/512、ss20/514、
ss20/612、ss20/712、ss600/41、ss600/51、
ss600/61、ss600/120, ss600/140、ss600/412、
ss600/512、ss600/514、ss600/612、ss1000、
sc2000、cs6400、solb5、solb6、ultra、ultra2、
ultra2e、ultra2i、ultra1/140、ultra1/170,
ultra1/200、ultra2/1170、ultra2/1200、
ultra2/1300、ultra2/2170、ultra2/2200,
ultra2/2300、ultra3、ultra3cu、ultra3i、
ultra4、entr2、entr2/1170、entr2/2170、
entr2/1200、entr2/2200、entr150、entr3000、
entr4000、entr5000、entr6000
SPARC V9 または UltraSPARC V9 上の 64 ビット Solaris 7
用にコンパイルするには、 -xarch=v9 または -xarch=v9a フ
ラグを指定します。 -xtarget=ultra または ultra2 という
設定は必要ないか (必要な場合には) 不十分です。
(Intel) -xtarget= には次のいずれかを指定できます。
o generic または native
o 386, 486 - 旧式。これらのフラグは使わないでください。
代わりに -xtarget=generic を使ってください。『C ユー
ザーズガイド』に、旧式のオプションとフラグの全一覧が掲
載されています。
o pentium
o pentium_pro
o pentium3
o pentium4
新しい pentium3 および pentium4 フラグの働きについての
詳細は、このマニュアルページ先頭の「x86 版での -xarch、
-xtarget、および -xchip のフラグの追加」を参照してくだ
さい。
実際のシステム名と番号のニーモニックコードを示す -xtar-
get を展開した内容ついては、『C ユーザーズガイド』の
-xtarget=t の項を参照してください。
-xtemp=<ディレクトリ>
コンパイラが使用する一時ファイルのディレクトリを<ディレ
クトリ>に設定します。このオプション中に空白文字を入れる
ことはできません。このオプションを指定しない場合は、一
時ファイルは /tmp に置かれます。 -xtemp による指定内容
は、TMPDIR 環境変数よりも優先されます。
-xthreadvar[=of1]
(SPARC) 宣言指定子 __thread と組み合わせて使用し、コン
パイラのスレッドローカルな記憶装置を利用することができ
ます。__thread を使用してスレッド変数を宣言した後に、
-xthreadvar を使用して、動的 (共有) ライブラリ内の位置
依存コード (非 PIC コード) を使用してスレッドローカルな
記憶装置を使用可能にすることができます。__thread の使用
法の詳細については、『C ユーザーズガイド』を参照してく
ださい。
o には以下の値を指定できます。
値 意味
[no%]dynamic
動的読み込み用の変数をコンパイルします[しませ
ん]。 -xthreadvar=no%dynamic を指定すると、ス
レッド変数へのアクセス速度が大幅に高速化され
ますが、動的ライブラリ内のオブジェクトファイ
ルを使用できません。つまり、実行可能ファイル
内のオブジェクトファイルを使用できません。
-xthreadvar を指定しない場合のデフォルトの設定は、位置
独立コード (PIC) が使用可能かどうかによって異なります。
位置独立コードが使用可能な場合、-xthreadvar=dynamic が
設定されます。位置独立コードが使用できない場合、
-xthreadvar=no%dynamic が設定されます。
-xthreadvar を引数を付けずに指定すると、
-xthreadvar=dynamic が設定されます。
動的ライブラリ内に位置独立コードがない場合には、
-xthreadvar を指定する必要があります。
リンカーは、動的ライブラリ内のスレッド変数と同等の非
PIC コードをサポートすることができません。非 PIC スレッ
ド変数を使用することによって大幅な高速化が実現できるた
め、実行可能ファイルのデフォルトにする必要があります。
バージョンの異なる Solaris ソフトウェアでスレッド変数を
使用する場合、コマンド行で指定するオプションが異なりま
す。
Solaris 8 では、__thread を使用するオブジェクトは -mt
を使用してコンパイルし、 -mt
-L/usr/lib/lwp -R/usr/lib/lwp を使用してリンクする必要
があります。
Solaris 9 では、__thread を使用するオブジェクトは -mt
を使用してコンパイルし、リンクする必要があります。
関連項目: -xcode, -KPIC, -Kpic
-xtime
コンパイルごとに、消費する時間とリソースを報告します。
-xtransition
K&R C と ISO C 間の相違について、警告を出します。 -
xtransition オプションは、 -Xa と -Xt オプションと共に
メッセージを発行します。動作の相違についてのすべての警
告メッセージは、適切なコーディングで解除できます。
-xtrigraphs[=[yes|no)]]
コンパイラが ISO C 標準規格で定義されているように 3 文
字表記シーケンスを認識するかどうかを指定します。
-xtrigraphs=yes と指定すると、コンパイラはソースコード
中の 3 文字表記シーケンスを認識します。
-xtrigraphs=no と指定すると、コンパイラはソースコード中
の 3 文字表記シーケンスを認識しません。
デフォルト:
-xtrigraphs が指定されていない場合は、 -xtrigraphs=no
であると仮定されます。
-xtrigraphs とだけ指定された場合は、 -xtrigraphs=yes で
あると仮定されます。
-xunroll=n
コンパイラがループを最適化する (展開する) かどうかを指
定します。 n は正の整数です。 n が 1 の場合はコマンドと
なり、コンパイラはループを展開しません。 n が 1 より大
きい場合は、 -xunroll=n は、ループを n 回展開することを
コンパイラに許可します。
-xustr={ascii_utf16_ushort|no}
ISO10646 UTF-16 文字列リテラルを使用する多言語対応アプ
リケーションをサポートする必要がある場合には、
-xustr=ascii_utf16_ushort を指定します。つまり、オブ
ジェクトファイルで UTF-16 文字列に変換したい文字列リテ
ラルがコードに含まれている場合、このオプションを使用し
ます。このオプションを指定しないと、コンパイラは 16
ビット文字列リテラルの生成、認識を行いません。このオプ
ションを指定すると、U"ASCII_string" 文字列リテラルを符
号なし短整数の配列として認識できるようになります。この
ような文字列は標準として規定されていないので、このオプ
ションを使用して、標準に準拠しない C 言語を認識すること
ができます。
-xustr=no を指定し、U"ASCII_string" 文字列定数を認識し
ないようにすることができます。コマンド行でこのオプショ
ンを複数指定すると、一番右以外の指定は無効になります。
デフォルトは -xustr=no です。引数を付けずに -xustr を指
定すると、指定が無効になり、警告が発生されます。C また
は C++ の標準で構文の意味が定義されると、このデフォルト
の設定は変更される可能性があります。
U"ASCII_string" 文字列リテラルを指定せずに
-xustr=ascii_ustf16_ushort を指定してもエラーにはなりま
せん。
すべてのファイルをこのオプションを指定してコンパイルす
る必要があるわけではありません。
以下の例では、U の後ろの引用符で囲まれた部分が文字列リ
テラルです。また、最後の行は、-xustr を指定するコマンド
行です。
example% cat file.c
const unsigned short *foo = U"foo";
const unsigned short bar[] = U"bar";
const unsigned short *fun() { return
example% cc -xustr=ascii_utf16_ushort file.c -c
-xvector[={yes|no}]
ベクトルライブラリ関数呼び出しの自動生成を有効にしま
す。このオプションを使用する場合は、-fround=nearest を
指定することによって、デフォルトの丸めモードを使用する
必要があります。
-xvector=yes を指定すると、コンパイラは、可能な限り、
ループ内にある数学ライブラリ呼び出しを、等価なベクトル
数学ルーチン呼び出しに変換します。このような変換の結果
として、ループカウントが大きいループではパフォーマンス
が向上する可能性があります。
-xvector を指定しない場合、デフォルトは -xvector=no で
す。 -xvector=no は以前に指定した -xvector=yes を無効に
します。 -xvector だけを指定して値を指定しない場合、デ
フォルトは -xvector=yes です。
-xdepend を指定していない場合、-xvector をコマンド行に
指定すると、-xdepend が暗黙的に指定されます。最適化レベ
ルを指定していない場合、あるいは、-O3 よりも低い最適化
を指定している場合、-xvector オプションを指定すると、
-O3 の最適化レベルが暗黙的に設定されます。
コンパイラは、ロード段階において、libmvec ライブラリを
取り込みます。異なるコマンドでコンパイルおよびリンクす
る場合は、cc コマンドのリンクで -xvector を指定する必要
があります。コンパイル時とリンク時の両方に指定する必要
があるコンパイラオプションの全一覧は、『C ユーザーズガ
イド』を参照してください。
-xvis
-xvis (SPARC) VSDK (VIS[tm] 命令セット Software
Developers Kit) で定義されているアセンブリ言語テンプ
レートを使用する場合、-xvis=[yes|no] コマンドを使用しま
す。デフォルトは -xvis=no です。 -xvis を引数を付けずに
指定すると、 -xvis=yes と指定したことになります。
VIS 命令セットは、SPARC v9 命令セットを拡張したもので
す。UltraSPARC は 64 ビットプロセッサですが、多くの場
合、特にマルチメディアアプリケーションでは、データサイ
ズが 8 または 16 ビットに制限されています。1 つの VIS
命令で 4 つの 16 ビットデータを処理できるため、画像、線
形代数、信号処理、音声、ビデオ、ネットワーキングなどの
新しいメディアを処理するアプリケーションのパフォーマン
スが大幅に向上します。
VSDK の詳細については、
http://www.sun.com/processors/vis/ を参照してください。
-xvpara
(SPARC) #pragma MP 指令が指定されているループについて、
ループが正しく並列化されない場合に、警告を出力します。
たとえば、コンパイラがループの繰り返しの間にデータの依
存関係を検出すると、警告が出力されます。
このオプションは、 -xexplicitpar または -xparallel オプ
ションおよび #pragma MP 指令と共に使用してください。
-Yc,<ディレクトリ>
構成要素 c の位置として、新しい <ディレクトリ> を指定し
ます。c は、-W オプションで示した構成要素を表わします。
構成要素の場所を指定すると、その構成要素の新しいパス名
は <ディレクトリ>/<構成要素>になります。任意の 1 つの項
目に対して複数の -Y オプションを適用すると、最後に指定
した内容が保持されます。
-YA,<ディレクトリ>
コンパイラのすべての構成要素の検索場所として <ディレク
トリ> を指定します。<ディレクトリ> 内で構成要素が見つか
らない場合、検索はコンパイラがインストールされている
ディレクトリに戻って行われます。
-YI,<ディレクトリ>
インクルードファイルを検索するデフォルトのディレクトリ
を変更します。
-YP,<ディレクトリ>
ライブラリファイルを検索するデフォルトのディレクトリを
変更します。
-YS,<ディレクトリ>
起動用のオブジェクトファイルを検索するデフォルトのディ
レクトリを変更します。
-Zll (SPARC) lock_lint 用プログラムデータベースを作成します
が、実行可能コードは生成しません。
cc は、-a、-e、 -r、-t、-u、-z を認識し、これらのオプション
とそれぞれの引数を ld に渡します。また、認識できなかったオプ
ションも ld に渡し、そのことに対する警告を出します。
注意事項
-fast を指定した場合は、errno の値を当てにしないでください。
これは、コード最適化によって errno の値が変更されることがあ
るためです。この問題を回避する最も簡単な方法は、-fast を指定
しないことです。
-fast を指定して、かつ errno の値が必要な場合は、次のことを
行ってください。
o 数学最適化ライブラリとのリンクで、-lmopt を指定しない。
o -xbuiltin=none、-U__MATHERR_ERRNO_DONTCARE、-xnolibmopt、
および -xnolibmil を指定する。
プラグマ
コンパイルシステムは以下の #pragma を認識します。
#pragma align
#pragma does_not_read_global_data
#pragma does_not_return
#pragma does_not_write_global_data
#pragma error_messages
#pragma fini
#pragma hdrstop
#pragma ident
#pragma init
#pragma [no_]inline
#pragma int_to_unsigned
#pragma opt
#pragma rarely_called
#pragma redefine_extname
#pragma returns_new_memory
#pragma unknown_control_flow
#pragma weak
SPARC のみ:
#pragma MP serial_loop
#pragma MP serial_loop_nested
#pragma MP taskloop
#pragma nomemorydepend
#pragma no_side_effect
#pragma pack
#pragma pipeloop
#pragma unroll
プラグマについての詳細は、『C ユーザーズガイド』を参照してく
ださい。
環境
以下は、設定可能な環境変数とその働きの簡単な説明です。
OMP_DYNAMIC
スレッドの数の動的調整を使用可能または使用不能にし
ます。
OMP_NESTED
入れ子の並列要素を使用可能または使用不能にします。
OMP_NUM_THREADS
実行中に使用されるスレッドの数を設定します。
OMP_SCHEDULE
実行時のスケジュールタイプとチャンクサイズを設定し
ます。
PARALLEL マルチプロセッサを利用するときは、 PARALLEL 環境変
数を設定します。 PARALLEL 環境変数は、プログラムが
利用できるプロセッサの数を指定します。ターゲットマ
シンが複数のプロセッサを持っている場合、スレッドが
個々のプロセッサにマップされます。プログラムを実行
すると、プログラムの並列化された部分を実行する 2
つのスレッドが作成されます。
STACKSIZE 実行プログラムは、マスタースレッドのメインメモリー
スタックと各スレーブスレッドの特殊スタックを保持し
ます。スタックは、サブプログラム呼び出し用の引数と
自動変数を保持するために使用される、一時メモリーア
ドレス空間です。メインスタックのデフォルトのサイズ
は、約 8 メガバイトです。現在のメインスタックのサ
イズを表示および設定するには、limit コマンドを使用
します。
マルチスレッド化プログラムの各スレーブスレッドに
は、独自のスレッドスタックがあります。このスタック
は、マスタースレッドのメインスタックに似ています
が、スレーブスレッド固有のスタックです。(スレッド
に局所的な) 専用配列と変数は、スレッドスタックに割
り当てられます。
スレーブスレッドのスタックサイズはすべて同じです。
デフォルトでは、32 ビットアプリケーション用が 4 メ
ガバイトで、64 ビットアプリケーション用が 8 メガバ
イトです。サイズは、STACKSIZE 環境変数によって設定
されます。
並列化されたコードによっては、スレッドスタックサイ
ズをデフォルト値より大きい値に設定する必要がありま
す。
コンパイラは、より大きいスタックサイズが必要である
ことを知らせる警告メッセージを表示することがありま
す。ただし、特に専用/局所配列が使用される場合に
は、テストやエラーの場合を除いて、どのようなサイズ
に設定すべきか分からないことがあります。スタックサ
イズが小さすぎてスレッドを実行できない場合、セグメ
ント例外によりプログラムは異常終了します。
TMPDIR 通常、 cc は一時ファイルをディレクトリ /tmp に作成
します。環境変数 TMPDIR を別のディレクトリに設定す
れば、そのディレクトリを一時ファイル用のディレクト
リとして使用することができます ( TMPDIR が有効な
ディレクトリでないとき、 cc は /tmp を使用します
)。 -xtemp は、TMPDIR 環境変数より優先されます。
SUNPRO_SB_INIT_FILE_NAME
.sbinit(5) ファイルが格納されているディレクトリの
絶対パス名。この変数は、 -xsb または -xsbfast フラ
グを指定したときだけに使用されます。
SUNPROF_DATA
-xprofile=collect コマンドが実行頻度のデータを保存
するファイル名を制御します。
SUNPROF_DATA_DIR
-xprofile=collect コマンドが実行頻度のデータファイ
ルを置くディレクトリを制御します。
SUNW_MP_THR_IDLE
ヘルパースレッドのタスク終了状態を制御します。spin
ns または sleep nms に設定することができます。デ
フォルトは spin です。詳細については、、『OpenMP
API ユーザーズガイド』を参照してください。
SUNW_MP_WARN
この環境変数は TRUE に設定し、OpenMP および他の並
列化実行時システムからの警告メッセージを表示するよ
うにします。警告メッセージを扱うため、
sunw_mp_register_warn() を使用して関数を登録した場
合、SUNW_MP_WARN は警告メッセージを出力しません。
TRUE に設定した場合も同様です。関数を登録しない
で、SUNW_MP_WARN を TRUE に設定した場合、
SUNW_MP_WARN は警告メッセージを stderr に出力しま
す。関数を登録せず、SUNW_MP_WARN を設定しない場
合、警告メッセージは出力されません。libmtsk で送出
された場合も同様です。sunw_mp_register_warn() につ
いて詳細は、C ユーザーズガイドを参照してください。
ファイル
a.out 実行可能出力ファイル
bb_link.o tcov サポート
<ファイル>.a オブジェクトファイルのライブラリ
<ファイル>.c C 言語のソースファイル
<ファイル>.d tcov(1) テストカバレージ入力ファイル
<ファイル>.i 前処理後の C ソースファイル
<ファイル>.il inline(1) 展開ファイル
<ファイル>.ll lock_lint データベース
<ファイル>.o オブジェクトファイル
<ファイル>.profile
-xprofile が使用するデータのディレクトリ
<ファイル>.s アセンブラのソースファイル
<ファイル>.so 動的ライブラリ
<ファイル>.tcov
tcov(1) からの出力
acomp コンパイラ・フロントエンド
cc コンパイラ・コマンド行ドライバ
cg コードジェネレータ (SPARC)
cg386 オプティマイザ (Intel)
codegen コードジェネレータ (Intel)
crt1.o 実行時起動コード
crti.o 実行時起動コード
crtn.o 実行時起動コード
fbe アセンブラ
gcrt1.o gprof(1) を使ったプロファイリングのため
の実行開始ファイル
gmon.out -xpg 用のデフォルトのプロファイルファイ
ル
ipo 内部手続きオプティマイザ (SPARC)
ir2hf 中間コード変換プログラム (Intel)
iropt 大域的なオプティマイザ
libldstab_ws.so sbfocus ロケータ
libredblack.so bids サポート
mcrt1.o prof(1) および intro(3) を使ったプロファ
イリングのための実行開始ファイル
misalign.o misalign データサポート (SPARC)
mon.out -p 用のデフォルトのプロファイルファイル
postopt ポストオプティマイザ (SPARC)
ssbd 静的同期バグ検出 (SPARC)
stack_grow.o スタックオーバーフローチェック (SPARC)
SunWS_cache -xsb フラグまたは -xsbfast フラグが使用
されたときに sbrowser(1) のデータを格納
するディレクトリ
ube オプティマイザ、コードジェネレータ
(Intel)
ube_ipa 内部手続きアナライザ (Intel)
values-xa.o -Xa サポート
values-xc.o -Xc サポート
values-xpg4.o -xpg4 サポート
values-xpg6.o SUSv3 サポート
values-xs.o -Xs サポート
values-xt.o -Xt サポート
関連項目
analyzer(1)、 as(1)、 c89(1)、 c99(1)、 cflow(1)、
cscope(1)、 ctags(1)、 ctrace(1)、 dbx(1)、 er_src(1)、
ild(1)、 indent(1)、 inline(1)、 ld(1)、 lint(1)、
lock_lint(1)、 prof(1)、 sbquery(1)、 sunstudio(1)、
tmpnam(3S)、 version(1)
『C ユーザーズガイド』
『ISO/IEC 9899-1990 Programming Language - C standard』
『ISO/IEC 9899-1999 Programming Language - C standard』
install_path/SUNWspro/READMEs 内の数学ライブラリの readme (
通常 install_path は /opt)