A.2 オプションの一覧

次の節では、C++ コンパイラオプションのアルファベット順の一覧と、プラットフォームの制限を示しています。

A.2.1 `-#`

冗長モードを有効にし、コマンドオプションがどのように展開されるかを表示します。要素が呼び出されるごとにその要素を表示します。

A.2.2 `-###`

呼び出される各構成要素が表示されますが、実行はされません。また、コマンドオプションの展開内容を表示します。

A.2.3 `-Bbinding`

ライブラリのリンク形式を、シンボリックか、動的 (共有)、静的 (共有でない) のいずれかから指定します。

-B オプションは同じコマンド行で何回も指定できます。このオプションはリンカー (ld) に渡されます。

注 - Oracle Solaris の 64 ビットコンパイル環境では、多くのシステムライブラリは動的ライブラリとしてのみ使用できます。このため、コマンド行の最後に -Bstatic を使用しないでください。

A.2.3.1 値

binding は、次の表に示されている値のいずれかである必要があります。

値	意味
`dynamic`	まず `lib`lib`.so` (共有) ファイルを検索するようにリンカーに指示します。これらのファイルが見つからないと、リンカーは `lib`lib`.a` (静的で共有されない) ファイルを検索します。ライブラリのリンク方式を共有にしたい場合は、このオプションを指定します。
`static`	-Bstatic オプションを指定すると、リンカーは `lib`lib`.a` (静的で、共有されない) ファイルだけを検索します。ライブラリのリンク形式を非共有にしたい場合は、このオプションを指定します。
`symbolic`	シンボルがほかですでに定義されている場合でも、可能であれば共有ライブラリ内でシンボル解決を実行します。 `ld`(1) のマニュアルページを参照してください。

-B と binding との間に空白があってはいけません。

デフォルト

-B を指定しないと、-Bdynamic が使用されます。

相互の関連性

C++ のデフォルトのライブラリを静的にリンクするには、-staticlib オプションを使用します。

-Bstatic および -Bdynamic オプションは、デフォルトで使用されるライブラリのリンクにも影響します。デフォルトのライブラリを動的にリンクするには、最後に指定する -B を -Bdynamic にするべきです。

64 ビットの環境では、多くのシステムライブラリは共有の動的ライブラリとしてのみ利用できます。これらのシステムライブラリには、libm.so および libc.so があります。libm.a と libc.a は提供していません。その結果、-Bstatic と -dn を使用すると 64 ビットの Oracle Solaris オペレーティングシステム環境でリンクエラーが生じる可能性があります。この場合、アプリケーションを動的ライブラリとリンクさせる必要があります。

例

次の例では、libfoo.so があっても libfoo.a がリンクされます。ほかのすべてのライブラリは動的にリンクされます。

example% CC a.o –Bstatic –lfoo –Bdynamic

警告

C++ コードが含まれているプログラムでは、-Bsymbolic を使用せずに、リンカーのマップファイルを使用してください。

-Bsymbolic を使用すると、異なるモジュール内の参照が、本来 1 つの大域オブジェクトの複数の異なる複製に結合されてしまう可能性があります。

例外メカニズムは、アドレスの比較によって機能します。オブジェクトの複製が 2 つある場合は、アドレスが同一であると評価されず、本来一意のアドレスを比較することで機能する例外メカニズムで問題が発生することがあります。

コンパイルとリンクを別々に行う場合で、コンパイル時に -Bbinding オプションを使用した場合は、このオプションをリンク時にも指定する必要があります。

A.2.4 `-c`

コンパイルのみ。オブジェクト .o ファイルを作成しますが、リンクはしません。

このオプションは ld によるリンクを抑止し、各ソースファイルに対する .o ファイルを 1 つずつ生成するように、CC ドライバに指示します。コマンド行にソースファイルを 1 つだけ指定する場合には、-o オプションでそのオブジェクトファイルに明示的に名前を付けることができます。

A.2.4.1 例

CC -c x.cc と入力すると、x.o というオブジェクトファイルが生成されます。

CC -c x.cc -o y.o と入力すると、y.o というオブジェクトファイルが生成されます。

警告

コンパイラは、入力ファイル (.c、.i) に対するオブジェクトコードを作成する際に、.o ファイルを作業ディレクトリに作成します。リンク手順を省略すると、この .o ファイルは削除されません。

A.2.5 `-cg`{`89|92`}

(SPARC) 非推奨、使用しないでください。現在の Oracle Solaris オペレーティングシステムソフトウェアは、SPARC V7 アーキテクチャーをサポートしません。このオプションでコンパイルすると、現在の SPARC プラットフォームでの実行速度が遅いコードが生成されます。代わりに -xO を使用し、-xarch、-xchip、および -xcache のコンパイラのデフォルトを利用します。

A.2.6 `-compat=`{ `5`|`g`}

コンパイラの主要リリースとの互換モードを設定します。このオプションは、__SUNPRO_CC_COMPAT プリプロセッサマクロを制御します。

C++ コンパイラには主要なモードが 2 つあります。デフォルトの -compat=5 は 2003 年に更新された ANSI/ISO 1998 C++ 標準に従った構造を受け入れ、-compat=5 モードで C++ 5.0 ~ 5.12 と互換性のあるコードを生成します。-compat=g オプションにより、Oracle Solaris x86 および Linux プラットフォーム上の gcc/g++ コンパイラとのソースおよびバイナリ互換性が追加されます。名前の符号化、クラスの配置、vtable の配置、その他の ABI の細かい点に互換性のない、大きな変更が行われているため、これらのモードには互換性がありません。

以前のリリースの 4.2 コンパイラで定義された意味と言語を受け入れていた互換モード (-compat=4) は、使用できなくなりました。

次の節に示すように、これらのモードは -compat オプションで区別されます。

A.2.6.1 値

-compat オプションには、次の表に示されている値を指定できます。

値	意味
`-compat=5`	(標準モード) 言語とバイナリの互換性を ANSI/ISO 標準モード 5.0 コンパイラに合わせます。`__SUNPRO_CC_COMPAT` プリプロセッサマクロを 5 に設定します。
`-compat=g`	(x86 のみ) g++ 言語拡張の認識を有効にし、コンパイラで Solaris および Linux プラットフォーム上の g++ とバイナリ互換のあるコードが生成されるようにします。`__SUNPRO_CC_COMPAT` プリプロセッサマクロを `'G'` に設定します。

-compat=g を使用すると、バイナリ互換性は個々の .o ファイルまたはアーカイブ (.a) ライブラリではなく、共有 (動的または .so) ライブラリにのみ拡張されます。

次の例は、g++ 共有ライブラリの C++ メインプログラムへのリンクを示しています。

% g++ -shared -o libfoo.so -fpic a.cc b.cc c.cc  
% CC -compat=g main.cc -L. -lfoo

次の例は、C++ 共有ライブラリの g++ メインプログラムへのリンクを示しています。

% CC -compat=g -G -o libfoo.so -Kpic a.cc b.cc c.cc
% g++ main.cc -L. -lfoo

デフォルト

-compat オプションを指定しないと、-compat=5 が使用されます。

相互の関連性

詳細は、-features を参照してください。

警告

共有ライブラリを構築するときは、-Bsymbolic を使用しないでください。

A.2.7 `+d`

C++ インライン関数を展開しません。

C++ 言語の規則では、C++ インライン関数は、次の文のいずれかがあてはまる場合の関数です。

関数が inline キーワードを使用して定義されている
関数が、宣言されているだけでなく、クラス定義内で定義されている
関数がコンパイラで生成されたクラスメンバー関数である

C++ 言語の規則では、呼び出しを実際にインライン化するかどうかをコンパイラが選択します。C++ コンパイラは、次のいずれかがあてはまらないかぎり、呼び出しをインライン関数にインライン化します。

関数が複雑すぎる
+d オプションが選択されている
—xOn 最適化レベルが指定されずに —g オプションが選択されている

A.2.7.1 例

デフォルトでは、コンパイラは次のコード例で関数 f() と memf2() をインライン化できます。また、クラスには、コンパイラによって生成されたデフォルトのコンストラクタとコンパイラでインライン化できるデストラクタがあります。+d を使用すると、コンパイラでコンストラクタ f() とデストラクタ C::mf2() はインライン化されません。

inline int f() {return 0;} // may be inlined
class C {
  int mf1(); // not inlined unless inline definition comes later
  int mf2() {return 0;} // may be inlined
};

相互の関連性

このオプションは、最適化レベルも同時に指定されていないかぎり (-O または -xO)、デバッグオプション -g を指定すると自動的に有効になります。

-g0 デバッグオプションでは、+d は有効になりません。

+d オプションは、-xO4 または -xO5 を使用するときに実行される自動インライン化に影響を与えません。

A.2.8 `-Dname`[ `=`def]

プリプロセッサに対してマクロシンボル名 name を def と定義します。

このオプションは、ソースファイルの先頭に #define 指令を記述するのと同じです。-D オプションは複数指定できます。

コンパイラの定義済みマクロのリストについては、CC(1) のマニュアルページを参照してください。

A.2.9 `-d`{`y`| `n`}

実行可能ファイル全体に対して動的ライブラリを使用できるかどうか指定します。

このオプションは ld に渡されます。

このオプションは、コマンド行では 1 度だけしか使用できません。

A.2.9.1 値

値	意味
`-dy`	リンカーで動的リンクを実行します。
`-dn`	リンカーで静的リンクを実行します。

デフォルト

-d オプションを指定しないと、-dy が使用されます。

相互の関連性

64 ビットの環境では、多くのシステムライブラリは共有の動的ライブラリとしてのみ利用できます。これらのシステムライブラリには、libm.so および libc.so があります。libm.a と libc.a は提供していません。その結果、-Bstatic と -dn を使用すると 64 ビットの Oracle Solaris オペレーティングシステムでリンクエラーが生じる可能性があります。この場合、アプリケーションを動的ライブラリとリンクさせる必要があります。

警告

このオプションを動的ライブラリと組み合わせて使用すると、重大なエラーが発生します。ほとんどのシステムライブラリは、動的ライブラリでのみ使用できます。

A.2.10 `-dalign`

(SPARC) 廃止。使用しないでください。-xmemalign=8s を使用してください。詳細は、「A.2.145 -xmemalign=ab」を参照してください。

x86 プラットフォームでは、このオプションはメッセージを表示せずに無視されます。

A.2.11 `-dryrun`

ドライバによって作成されたコマンドを表示しますが、コンパイルはしません。

このオプションは、コンパイルドライバが作成したサブコマンドの表示のみを行い、実行はしないように CC ドライバに指示します。

A.2.12 `-E`

ソースファイルに対してプリプロセッサを実行しますが、コンパイルはしません。

C++ のソースファイルに対してプリプロセッサだけを実行し、結果を stdout (標準出力) に出力するよう CC ドライバに指示します。コンパイルは行われません。したがって .o ファイルは生成されません。

このオプションを使用すると、プリプロセッサで作成されるような行番号情報が出力に含まれます。

ソースコードにテンプレートが含まれている場合に -E オプションの出力をコンパイルするには、-E オプションとともに -template=no%extdef オプションを使用する必要が生じることがあります。アプリケーションコードで定義分離テンプレートのソースコードモデルが使用されている場合でも、-E オプションの出力が引き続きコンパイルされない可能性があります。詳細は、テンプレートの章を参照してください。

A.2.12.1 例

このオプションは、プリプロセッサの処理結果を知りたいときに便利です。たとえば、次に示すプログラムでは、foo.cc は、「A.2.12.1 例」に示す出力を生成します。

例 A-1 プリプロセッサのプログラム例 foo.cc

#if __cplusplus < 199711L
int power(int, int);
#else
template <> int power(int, int);
#endif

int main () {
  int x;
  x=power(2, 10);
}
.

例 A-2 -E オプションを使用したときの foo.cc のプリプロセッサ出力

example% CC -E foo.cc
#4 "foo.cc"
template < > int power (int, int);


int main () {
int x;
x = power (2, 10);
}

警告

コードの定義分離モデルにテンプレートが含まれている場合は、このオプションの出力を C++ コンパイルへの入力として使用できないことがあります。

A.2.13 `-erroff`[`=` `t`]

このコマンドは、C++ コンパイラの警告メッセージを無効にします。エラーメッセージには影響しません。このオプションは、-errwarn によってゼロ以外の終了状態を発生させるように指定されているかどうかにかかわらず、すべての警告メッセージに適用されます。

A.2.13.1 値

t には、次の 1 つまたは複数の項目をコンマで区切って指定します。tag、no%tag、 %all、%none。指定順序によって実行内容が異なります。たとえば、「%all,no%tag」と指定すると、tag 以外のすべての警告メッセージを抑制します。次の表は、-erroff の値を示しています。

表 A-2 -erroff の値

値	意味
`tag`	`tag` のリストに指定されているメッセージを抑制します。`-errtags=yes` オプションで、メッセージのタグを表示することができます。
`no%tag`	`tag` 以外のすべての警告メッセージの抑制を解除します。
`%all`	すべての警告メッセージを抑制します。
`%none`	すべてのメッセージの抑制を解除します (デフォルト)。

デフォルト

デフォルトは -erroff=%none です。-erroff と指定すると、-erroff=%all を指定した場合と同じ結果が得られます。

例

たとえば、-erroff=tag は、この tag が指定する警告メッセージを抑止します。それに対して、-erroff=%all,no% tag は、tag で識別されるメッセージ以外の警告メッセージをすべて抑制します。

警告メッセージのタグを表示するには、-errtags=yes オプションを使用します。

警告

-erroff オプションで無効にできるのは、C++ コンパイラのフロントエンドで -errtags オプションを指定したときにタグを表示する警告メッセージだけです。

A.2.14 `-errtags`[`=` `a`]

C++ コンパイラのフロントエンドで出力される警告メッセージのうち、-erroff オプションで無効にできる、または -errwarn オプションで重大な警告に変換できるメッセージのメッセージタグを表示します。

A.2.14.1 値とデフォルト

a には yes または no のいずれかを指定します。デフォルトは -errtags=no です。-errtags だけを指定すると、-errtags=yes を指定するのと同じことになります。

警告

C++ コンパイラドライバや、コンパイルシステムのその他のコンポーネントからのメッセージには、エラータグは含まれていません。そのため、これらのメッセージを -erroff で抑制したり、-errwarn で致命的エラーにすることはできません。

A.2.15 `-errwarn`[`=` `t`]

指定した警告メッセージが生成された場合に、重大なエラーを出力して C++ コンパイラを終了する場合は、-errwarn を使用します。

A.2.15.1 値

t には、次の 1 つまたは複数の項目をコンマで区切って指定します。tag、no%tag、 %all、%none。このとき、順序が重要になります。たとえば、%all,no%tag と指定すると、tag 以外のすべての警告メッセージが生成された場合に、重大なエラーを出力して cc を終了します。

-errwarn の値を次の表に示します。

表 A-3 -errwarn の値

値	意味
`tag`	`tag` に指定されたメッセージが警告メッセージとして発行されると、`CC` は致命的エラーステータスを返して終了します。`tag` に指定されたメッセージが発行されない場合は無効です。
`no%tag`	`tag` に指定されたメッセージが警告メッセージとしてのみ発行された場合に、`CC` が致命的なエラーステータスを返して終了しないようにします。`tag` に指定されたメッセージが発行されない場合は無効です。このオプションは、`tag` または `%all` を使用して以前に指定したメッセージが警告メッセージとして発行されても cc が致命的エラーステータスで終了しないようにする場合に使用してください。
`%all`	警告メッセージが 1 つでも発行されると `CC` は致命的ステータスを返して終了します。`%all` に続いて `no%tag` を使用して、特定の警告メッセージを対象から除外することもできます。
`%none`	どの警告メッセージが発行されても `CC` が致命的エラーステータスを返して終了することがないようにします。

デフォルト

デフォルトは -errwarn=%none です。-errwarn のみを指定することは、-errwarn=%all と同等です。

警告

-errwarn オプションを使用して、障害状態で C++ コンパイラを終了するように指定できるのは、C++ コンパイラのフロントエンドで -errtags オプションを指定したときにタグを表示する警告メッセージだけです。

C++ コンパイラで生成される警告メッセージは、コンパイラのエラーチェックの改善や機能追加に応じて、リリースごとに変更されます。-errwarn=%all を指定してエラーなしでコンパイルされるコードでも、コンパイラの次期リリースではエラーを出力してコンパイルされる可能性があります。

A.2.16 `-fast`

このオプションは、実行ファイルの実行時のパフォーマンスのチューニングで効果的に使用することができるマクロです。-fast は、コンパイラのリリースによって変更される可能性があるマクロで、ターゲットのプラットフォーム固有のオプションに展開されます。-dryrun オプションまたは -xdryrun を使用して -fast の展開を調べ、-fast の該当するオプションを使用して実行可能ファイルのチューニングを行なってください。

このオプションは、コードをコンパイルするマシン上でコンパイラオプションの最適な組み合わせを選択して実行速度を向上するマクロです。

A.2.16.1 展開

このオプションは、次のコンパイラオプションを組み合わせて、多くのアプリケーションのパフォーマンスをほぼ最大にします。

表 A-4 -fast の展開

オプション	SPARC	x86
`-fns`	X	X
`-fsimple=2`	X	X
`-nofstore`	-	X
`-xbuiltin=%all`	X	X
`-xlibmil`	X	X
`-xlibmopt`	X	X
`-xmemalign`	X	-
`-xO5`	X	X
`-xregs=frameptr`	-	X
`-xtarget=native`	X	X

相互の関連性

-fast マクロから展開されるコンパイラオプションが、指定されたほかのオプションに影響を与えることがあります。たとえば、次のコマンドの -fast マクロの展開には -xtarget=native が含まれています。そのため、ターゲットのアーキテクチャーは -xarch に指定された SPARC-V9 ではなく、32 ビットアーキテクチャーのものに戻されます。

誤

example% CC -xarch=sparcvis2 -fast test.cc

正

example% CC -fast -xarch=sparcvis2 test.cc

個々の相互の関連性については、各オプションの説明を参照してください。

このコード生成オプション、最適化レベル、組み込み関数の最適化、インラインテンプレートファイルの使用よりも、そのあとで指定するフラグの方が優先されます (例を参照)。ユーザーの指定した最適化レベルは、以前に設定された最適化レベルを無効にします。

-fast オプションには -fns -ftrap=%none が含まれているため、このオプションによってすべてのトラップが無効になります。

x86 では、—fast オプションに —xregs=frameptr が含まれます。特に C、Fortran、および C++ の混合ソースコードをコンパイルする場合は、その詳細について、このオプションの説明を参照してください。

例

次のコンパイラコマンドでは、最適化レベルは -x03 になります。

example% CC –fast –xO3

次のコンパイラコマンドでは、最適化レベルは -xO5 になります。

example% CC -xO3 –fast

警告

別々の手順でコンパイルしてリンクする場合は、-fast オプションをコンパイルコマンドとリンクコマンドの両方に表示する必要があります。

-fast オプションでコンパイルしたオブジェクトバイナリは移植できません。たとえば、UltraSPARC-III システムで次のコマンドを指定すると、生成されるバイナリは UltraSPARC-II システムでは動作しません。

example% CC -fast test.cc

IEEE 標準の浮動小数点演算に依存するプログラムでは、このオプションを使用しないでください。異なる数値の結果、プログラムの強制終了、または予期しない SIGFPE シグナルが発生する可能性があります。

-fast の展開には、-D_MATHERR_ERRNO_DONTCARE が含まれます。

-fast を使用すると、コンパイラは errno 変数を設定しない同等の最適化コードを使用して呼び出しを浮動小数点関数に自由に置き換えることができます。さらに、-fast を指定すると、マクロ __MATHERR_ERRNO_DONTCARE も定義されます。このマクロにより、コンパイラは errno や、浮動小数点関数呼び出しのあとに発生した浮動小数点例外の有効性の保証を無視できます。結果として、errno の値または浮動小数点関数呼び出しのあとに発生した適切な浮動小数点例外の値に依存するユーザーコードが、一貫性のない結果を生成する可能性があります。

この問題を解決する 1 つの方法は、-fast を使用してそのようなコードをコンパイルしないことです。ただし、-fast の最適化が必要であり、かつコードが正しく設定された errno の値、または浮動小数点ライブラリの呼び出しのあとに発生した浮動小数点例外に依存している場合は、コンパイラがこのようなライブラリ呼び出しを最適化することを抑制するために、コマンド行で -fast のあとに次のオプションを指定してコンパイルしてください。

-xbuiltin=%none -U__MATHERR_ERRNO_DONTCARE -xnolibmopt -xnolibmil

任意のプラットフォームで -fast の展開を表示するには、次の例に示すように、コマンド CC -dryrun -fast を実行します。

>CC -dryrun -fast |& grep ###
###     command line files and options (expanded):
### -dryrun -xO5 -xarch=sparcvis2 -xcache=64/32/4:1024/64/4 \
-xchip=ultra3i -xmemalign=8s -fsimple=2 -fns=yes -ftrap=%none \
-xlibmil -xlibmopt -xbuiltin=%all -D__MATHERR_ERRNO_DONTCARE

A.2.17 `-features`=a[ `,a`...]

コンマで区切って指定された C++ 言語のさまざまな機能を、有効または無効にします。

A.2.17.1 値

キーワード a には、次の表に示されている値を指定できます。no% 接頭辞によって、関連付けられたオプションが無効になります。

表 A-5 -features の値

値	意味
`%all`	非推奨。使用しないでください。ほぼすべての `-features` オプションを有効にします。結果は予測できない場合があります。
[`no%`]`altspell`	トークンの代替スペル (たとえば、「`&&`」の代わりの「`and`」) を認識します。デフォルトは `altspell` です。
[`no%`]`anachronisms`	廃止されている構文を許可します。無効にした場合 (つまり、`-features=no%anachronisms`)、廃止されている構文は許可されません。デフォルトは `anachronisms` です。
[`no%`]`bool`	`bool` 型とリテラルを許可します。有効にした場合は、マクロ `_BOOL=1` です。有効にしないと、マクロは定義されません。デフォルトは `bool` です。
[`no%`]`conststrings`	リテラル文字列を読み取り専用メモリーに配置します。デフォルトは `conststrings` です。
`cplusplus_redef`	通常は事前に定義されているマクロ `__cplusplus` を、コマンド行で `-D` オプションを使用して再定義できるようにします。ソースコードで `#define` 指令を使用して `__cplusplus` の再定義を試みることは許可されていません。例: `CC -features=cplusplus_redef -D__cplusplus=1` ... g++ コンパイラは通常、`__cplusplus` マクロを 1 に事前に定義するため、一部のソースコードはこの非標準の値に依存している可能性があります。(標準の値は、1998 年の C++ 標準または 2003 年の更新を実装しているコンパイラを示す 199711L です。将来の標準では、このマクロにより大きな値が必要になります。) g++ を目的に作成されたコードをコンパイルするために `__cplusplus` を 1 に再定義することが必要でないかぎり、このオプションを使用しないでください。
[`no%`]`except`	C++ 例外を許可します。C++ 例外を無効にした場合 (つまり、`-features=no%except`)、関数に指定された throw は受け入れられますが無視されます。つまり、コンパイラは例外コードを生成しません。キーワード `try`、`throw`、および `catch` は常に予約されています。「8.3 例外の無効化」を参照してください。デフォルトは `except` です。
`explicit`	キーワード `explicit` を認識します。オプション `no%explicit` は許可されていません。
[`no%`]`export`	キーワード `export` を認識します。デフォルトは `export` です。
`[no%]extensions`	ほかの C++ コンパイラでは一般に受け入れられる非標準コードを許可します。デフォルトは `no%extensions` です。
`[no%]iddollar`	`$` シンボルを最初以外の識別子の文字として許可します。デフォルトは `no%iddollar` です。
`[no%]localfor`	`for` 文に対して標準準拠の局所スコープ規則を使用します。デフォルトは `localfor` です。
`[no%]mutable`	キーワード `mutable` を認識します。デフォルトは `mutable` です。
`namespace`	キーワード `namespace` を認識します。オプション `no%namespace` は許可されていません。
`[no%]nestedacess`	ネストしたクラスが、包含するクラスの private メンバーにアクセスできるようにします。デフォルト: `-features=nestedaccess`
`rtti`	実行時の型識別 (RTTI) を許可します。オプション `no%rtti` は許可されていません。
`[no%]rvalueref`	`const` 以外の参照の右辺値または一時値へのバインドを許可します。デフォルト: `-features=no%rvalueref` デフォルトでは、C++ コンパイラは `const` 以外の参照を一時値または右辺値にバインドできないという規則を適用します。この規則を上書きするには、`-features=rvalueref` オプションを使用します。
`[no%]split_init`	ローカルではない静的オブジェクトに対応する初期化子を個別の関数に配置します。`-features=no%split_init` を使用すると、コンパイラではすべての初期設定子が 1 つの関数に入れられます。`-features=no%split_init` を使用すると、コンパイル時間を可能なかぎり費やしてコードサイズを最小化します。デフォルトは `split_init` です。
`[no%]transitions`	標準 C++ で問題があり、しかもプログラムが予想とは違った動作をする可能性があるか、または将来のコンパイラで拒否される可能性のある ARM 言語構造を許可します。`-features=no%transitions` を使用すると、コンパイラではこれらの言語構造をエラーとして扱います。`-features=transitions` を使用すると、コンパイラはエラーメッセージの代わりに、これらの構造に関する警告を発行します。次の構造は移行エラーとみなされます。テンプレートの使用後にテンプレートを再定義する、`typename` 指令をテンプレートの定義で必要なときに省略する、`int` 型を暗黙的に宣言する。一連の移行エラーは将来のリリースで変更される可能性があります。デフォルトは `transitions` です。
`[no%]strictdestrorder`	静的記憶領域の持続中にオブジェクトを破棄する順序に関する、C++ 標準の必要条件に従います。デフォルトは `strictdestrorder` です。
[`no%`]`tmplrefstatic`	関数テンプレートからの依存静的関数または静的関数テンプレートの参照を許可します。デフォルトは標準準拠の `no%tmplrefstatic` です。
`[no%]tmplife`	ANSI/ISO C++ 標準で定義された完全な式の最後にある式によって作成された一時オブジェクトをクリーンアップします。`-features=no%tmplife` が有効である場合は、大多数の一時オブジェクトはそのブロックの終わりに整理されます。デフォルトは `tmplife` です。
`%none`	非推奨。使用しないでください。ほぼすべての機能を無効にします。結果は予測できない場合があります。

相互の関連性

このオプションは、置き換えられる代わりに蓄積されます。

次の値の使用は、標準ライブラリやヘッダーと互換性がありません。

no%bool
no%except
no%mutable

警告

-features=%all または -features=%none を使用しないでください。これらのキーワードは非推奨であり、将来のリリースで削除される可能性があります。結果は予測できない場合があります。

-features=tmplife オプションを使用すると、プログラムの動作が変わる場合があります。プログラムが -features=tmplife オプションを指定してもしなくても動作するかどうかをテストする方法は、プログラムの移植性をテストする方法の 1 つです。

A.2.18 `-filt`[`=` `filter`[`,filter`...]]

コンパイラによってリンカーとコンパイラのエラーメッセージに通常適用されるフィルタリングを制御します。

A.2.18.1 値

filter は、次の表に示されている値のいずれかである必要があります。%no 接頭辞によって、関連付けられたサブオプションが無効になります。

表 A-6 -filt の値

値	意味
[`no%`]`errors`	C++ のリンカーエラーメッセージの説明を表示します。説明の抑止は、リンカーの診断を別のツールに直接提供している場合に便利です。
[`no%`]`names`	C++ で符号化されたリンカー名を復号化します。
[`no%`]`returns`	関数の戻り型を復号化します。この種の復号化を抑止すると、より迅速に関数名を識別できるようになりますが、共有の不変式の戻り値の場合、一部の関数は戻り型でのみ異なります。
[`no%`]`stdlib`	リンカーとコンパイラの両方のエラーメッセージに出力される標準ライブラリからの名前を簡略化し、標準ライブラリテンプレート型の名前をより容易に認識するための方法を提供します。
`%all`	`-filt=errors,names,returns,stdlib` と同等です。これはデフォルトの動作です。
`%none`	`-filt=no%errors,no%names,no%returns,no%stdlib` と同等です。

デフォルト

-filt オプションを指定しない場合、または -filt を値なしで指定した場合、コンパイラでは -filt=%all が使用されます。

例

次の例では、このコードを -filt オプションでコンパイルしたときの影響を示します。

// filt_demo.cc
class type {
public:
    virtual ~type(); // no definition provided
};

int main()
{
    type t;
}

-filt オプションを指定しないでコードをコンパイルすると、コンパイラでは -filt=errors,names,returns,stdlib が使用され、標準出力が表示されます。

example% CC filt_demo.cc
Undefined             first referenced
 symbol                  in file
type::~type()         filt_demo.o
type::__vtbl          filt_demo.o
[Hint: try checking whether the first non-inlined, /
non-pure virtual function of class type is defined]

ld: fatal: Symbol referencing errors. No output written to a.out

次のコマンドでは、C++ で符号化されたリンカー名の復号化が抑止され、C++ のリンカーエラーの説明が抑止されます。

example% CC -filt=no%names,no%errors filt_demo.cc
Undefined                       first referenced
 symbol                             in file
__1cEtype2T6M_v_                    filt_demo.o
__1cEtypeG__vtbl_                   filt_demo.o
ld: fatal: Symbol referencing errors. No output written to a.out

次のコードについて考えてみましょう。

#include <string>
#include <list>
int main()
{
    std::list<int> l;
    std::string s(l); // error here
}

-filt=no%stdlib を指定すると、次の出力が得られます。

Error: Cannot use std::list<int, std::allocator<int>> to initialize
std::basic_string<char, std::char_traits<char>,
std::allocator<char>>.

-filt=stdlib を指定すると、次の出力が得られます。

Error: Cannot use std::list<int> to initialize std::string .

相互の関連性

no%names を使用しても returns や no%returns に影響はありません。つまり、次のオプションは同じ効果を持ちます。

-filt=no%names
-filt=no%names,no%returns
-filt=no%names,returns

A.2.19 `-flags`

-xhelp=flags と同じです。

A.2.20 `-fma`[`=`{ `none`|`fused`}]

(SPARC) 浮動小数点の積和演算 (FMA) 命令の自動生成を有効にします。-fma=none を指定すると、これらの命令の生成を無効にします。-fma=fused を指定すると、コンパイラは浮動小数点の積和演算 (FMA) 命令を使用して、コードのパフォーマンスを改善する機会を検出しようとします。

デフォルトは -fma=none です。

コンパイラが積和演算 (FMA) 命令を生成するための最小要件は、-xarch=sparcfmaf と、最適化レベルが -xO2 以上であることです。積和演算 (FMA) 命令をサポートしていないプラットフォームでプログラムが実行されないようにするため、コンパイラは積和演算 (FMA) 命令を生成する場合、バイナリプログラムにマーク付けをします。

積和演算 (FMA) 命令により、積と和の間で中間の丸め手順が排除されます。その結果、-fma=fused を指定してコンパイルしたプログラムは、精度は減少ではなく増加する傾向にありますが、異なる結果になることがあります。

A.2.21 `-fnonstd`

これは、x86 上では -ftrap=common、また SPARC 上では -fns -ftrap=common に展開されるマクロです。

詳細は、-fns および -ftrap=common を参照してください。

A.2.22 `-fns`[={`yes`| `no`}]

SPARC: SPARC 非標準浮動小数点モードを有効または無効にします。

-fns=yes (または-fns) を指定すると、プログラムが実行を開始するときに、非標準浮動小数点モードが有効になります。

このオプションを使うと、-fns を含むほかのマクロオプション (-fast など) のあとで非標準と標準の浮動小数点モードを切り替えることができます。

一部の SPARC アーキテクチャーでは、非標準浮動小数点モードで「段階的アンダーフロー」が無効になり、非正規の数値を生成する代わりに、小さい値がゼロにフラッシュされます。さらに、このモードでは、非正規のオペランドが報告なしにゼロに置き換えられます。

段階的アンダーフローや、非正規の数値をハードウェアでサポートしない SPARC アーキテクチャーでは、-fns=yes (または -fns) を使用すると、プログラムによってはパフォーマンスが著しく向上することがあります。
x86: SSE flush-to-zero モードを選択または選択解除します。利用可能な場合は、denormals-are-zero モードです。

このオプションは、非正規数の結果をゼロにフラッシュします。また利用可能な場合には、非正規数オペランドもゼロとして扱われます。

このオプションは、SSE や SSE2 命令セットを利用しない従来の x86 浮動小数点演算には影響しません。

A.2.22.1 値

-fns オプションには、次の表に示されている値を指定できます。

表 A-7 -fns の値

値	意味
`yes`	非標準浮動小数点モードを選択します。
`no`	標準浮動小数点モードを選択します。

デフォルト

-fns を指定しないと、非標準浮動小数点モードは自動的には有効にされません。標準の IEEE 754 浮動小数点計算が行われます。つまり、アンダーフローは段階的です。

-fns だけを指定すると、-fns=yes が想定されます。

例

次の例では、-fast は複数のオプションに展開され、その中には -fns=yes (非標準浮動小数点モードを選択する) も含まれます。ところが、そのあとに続く -fns=no が初期設定を変更するので、結果的には、標準の浮動小数点モードが使用されます。

example% CC foo.cc -fast -fns=no

警告

非標準モードが有効になっていると、浮動小数点演算によって、IEEE 754 規格の条件に合わない結果が出力されることがあります。

1 つのルーチンを -fns オプションを使用してコンパイルする場合は、そのプログラムのすべてのルーチンを -fns オプションを使用してコンパイルしてください。それ以外の場合、予期しない結果が生じることがあります。

このオプションは、メインプログラムをコンパイルする場合にのみ有効です。

-fns=yes (または -fns) オプションを使用すると、プログラムで通常は IEEE 浮動小数点トラップハンドラによって管理される浮動小数点エラーが発生した場合、警告メッセージが生成されることがあります。

A.2.23 `-fprecision`=p

x86: デフォルト以外の浮動小数点精度モードを設定します。

-fprecision オプションは、浮動小数点制御ワード (FPCW) の丸め精度モードのビットを設定します。これらのビットは、基本演算 (加算、減算、乗算、除算、平方根) の結果をどの精度に丸めるかを制御します。

A.2.23.1 値

p は、次の表に示されている値のいずれかである必要があります。

表 A-8 -fprecision の値

値	意味
`single`	IEEE 単精度値に丸めます。
`double`	IEEE 倍精度値に丸めます。
`extended`	利用可能な最大の精度に丸めます。

p が single か double であれば、丸め精度モードは、プログラムの実行が始まるときに、それぞれ single か double 精度に設定されます。p が extended であるか、-fprecision フラグが使用されていなければ、丸め精度モードは extended 精度のままです。

single 精度の丸めモードでは、結果が 24 ビットの有効桁に丸められます。double 精度の丸めモードでは、結果が 53 ビットの有効桁に丸められます。デフォルトの extended 精度の丸めモードでは、結果が 64 ビットの有効桁に丸められます。このモードは、レジスタにある結果をどの精度に丸めるかを制御するだけであり、レジスタの値には影響を与えません。レジスタにあるすべての結果は、拡張倍精度形式の全範囲を使って丸められます。ただし、メモリーに格納される結果は、指定した形式の範囲と精度に合わせて丸められます。

float 型の公称精度は single です。long double 型の公称精度は extended です。

デフォルト

-fprecision オプションを指定しないと、丸め精度モードは extended になります。

警告

このオプションは、x86 システムでメインプログラムのコンパイル時に使用する場合にのみ有効で、64 ビット (-m64) または SSE2 対応 (-xarch=sse2) プロセッサでコンパイルする場合は無視されます。SPARC システムでも無視されます。

A.2.24 `-fround=`r

起動時に IEEE 丸めモードを有効にします。

このオプションは、コンパイラが定数式を評価するときに使用できる IEEE 754 丸めモードを設定します。丸めモードは、プログラム初期化中の実行時に確立されます。

内容は、ieee_flags サブルーチンと同じです。これは実行時のモードを変更するために使用します。

A.2.24.1 値

r は、次の表に示されている値のいずれかである必要があります。

表 A-9 -fround の値

値	意味
`nearest`	もっとも近い数値に丸め、中間値の場合は偶数にします。
`tozero`	ゼロに丸めます。
`negative`	負の無限大に丸めます。
`positive`	正の無限大に丸めます。

デフォルト

-fround オプションを指定しないと、丸めモードは -fround=nearest になります。

警告

1 つのルーチンを -fround=r を使用してコンパイルする場合は、そのプログラムのすべてのルーチンを同じ -fround=r オプションを使用してコンパイルする必要があります。それ以外の場合、予期しない結果が生じることがあります。

このオプションは、メインプログラムをコンパイルするときにだけ有効です。

-xvector または -xlibmopt でのコンパイルには、デフォルトの丸めが必要です。-xvector または -xlibmopt のどちらか、あるいはその両方を使用してコンパイルされたライブラリにリンクするプログラムは、デフォルトの丸めが有効になっていることを確認する必要があります。

A.2.25 `-fsimple`[`=` n]

浮動小数点最適化の設定を選択します。

このオプションは、オプティマイザが浮動小数点演算に関する仮定を単純化できるようにします。

A.2.25.1 値

n を指定する場合、0、1、2 のいずれかにしなければいけません。

表 A-10 -fsimple の値

値	意味
`0`	仮定の設定を許可しません。IEEE 754 に厳密に準拠します。
`1`	安全な簡略化を行います。生成されるコードは IEEE 754 に厳密には準拠していませんが、大半のプログラムの数値結果は変わりありません。 `-fsimple=1` の場合、次に示す内容を前提とした最適化が行われます。 IEEE 754 のデフォルトの丸めとトラップモードが、プロセスの初期化以後も変わらない。起こり得る浮動小数点例外を除き、目に見えない結果を出す演算が削除される可能性がある。無限大数または非数をオペランドとする演算は、その結果に非数を伝える必要がある。x*0 は 0 によって置き換えられる可能性がある。演算はゼロの符号を区別しない。 `-fsimple=1` の場合、四捨五入や例外を考慮せずに完全な最適化を行うことは許可されていません。特に浮動小数点演算は、丸めモードを保持した定数について実行時に異なった結果を出す演算に置き換えることはできません。
`2`	`-fsimple=1` のすべての機能に加えて、浮動小数点演算の最適化を積極的に行い、丸めモードの変更によって多くのプログラムが異なった数値結果を出すようになります。たとえば、あるループ内の `x/y` の演算をすべて `x*z` に置き換えるような最適化を許可します。この最適化では、`x/y` はループ `z=1/y` 内で少なくとも 1 回評価されることが保証されており、`y` と `z` にはループの実行中に定数値が割り当てられます。

デフォルト

-fsimple を指定しないと、コンパイラーは -fsimple=0 を使用します。

-fsimple を指定しても n の値を指定しないと、-fsimple=1 が使用されます。

相互の関連性

-fast は -fsimple=2 を意味します。

警告

このオプションによって、IEEE 754 に対する適合性が損なわれることがあります。

A.2.26 `-fstore`

(x86) 浮動小数点式の精度を強制的に設定します。

このオプションを指定すると、コンパイラは、次の場合に浮動小数点の式や関数の値を代入式の左辺の型に変換します。つまり、その値はレジスタにそのままの型で残りません。

式や関数を変数に代入する。
式をそれより短い浮動小数点型にキャストする。

このオプションを解除するには、オプション -nofstore を使用してください。SPARC プラットフォームでは、-fstore と -nofstore のどちらも、警告が出力されて無視されます。

A.2.26.1 警告

丸めや切り捨てによって、結果がレジスタの値から生成される値と異なることがあります。

A.2.27 `-ftrap=`t[`,`t...]

起動時の IEEE トラップモードを設定します。ただし、SIGFPE ハンドラは組み込まれません。トラップの設定と SIGFPE ハンドラの組み込みを同時に行うには、ieee_handler(3M) か fex_set_handling(3M) を使用します。複数の値を指定すると、それらの値は左から右に処理されます。

A.2.27.1 値

t には、次の表に示す値のいずれかにできます。

表 A-11 -ftrap の値

値	意味
`[no%]division`	ゼロによる除算をトラップします。
`[no%]inexact`	正確でない結果をトラップします。
`[no%]invalid`	無効な演算をトラップします。
`[no%]overflow`	オーバーフローをトラップします。
`[no%]underflow`	アンダーフローをトラップします。
`%all`	前述のすべてをトラップします。
`%none`	前述のどれもトラップしません。
`common`	無効、ゼロ除算、オーバーフローをトラップします。

[no%] 形式のオプションは、下の例に示すように、%all や commonフラグの意味を変更するときだけ使用します。[no%] 形式のオプション自体は、特定のトラップを明示的に無効にするものではありません。

デフォルト

-ftrap を指定しない場合、コンパイラは -ftrap=%none とみなします。

例

-ftrap=%all,no%inexact は、inexact を除くすべてのトラップが設定されます。

警告

1 つのルーチンを -ftrap=t を使用してコンパイルする場合は、そのプログラムのすべてのルーチンを同じ -ftrap=t オプションを使用してコンパイルしてください。それ以外の場合、予期しない結果が生じることがあります。

-ftrap=inexact のトラップは慎重に使用してください。-ftrap=inexact では、浮動小数点の値が正確でないとトラップが発生します。たとえば、次の文ではこの条件が発生します。

x = 1.0 / 3.0;

このオプションは、メインプログラムをコンパイルするときにだけ有効です。このオプションを使用する際には注意してください。IEEE トラップを有効にする場合は、-ftrap=common を使用します。

A.2.28 `–G`

実行可能ファイルではなく動的共有ライブラリを構築します。

コマンド行で指定したソースファイルはすべて、デフォルトで -xcode=pic13 オプションでコンパイルされます。

テンプレートが含まれていて、-instances=extern オプションを使用してコンパイルされたファイルから共有ライブラリを構築すると、.o ファイルにより参照されているテンプレートインスタンスがすべてテンプレートキャッシュから自動的に含められます。

コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションと -G オプションを組み合わせて共有ライブラリを作成した場合は、生成された共有オブジェクトとのリンクでも、必ず同じオプションを指定してください。

「A.2.113 -xcode=a」で推奨されているように、共有オブジェクトを作成するときは、64 ビット SPARC アーキテクチャー用にコンパイルされるすべてのオブジェクトファイルもまた、明示的な -xcode 値を使用してコンパイルする必要があります。

A.2.28.1 相互の関連性

-c (コンパイルのみのオプション) を指定しないと、次のオプションがリンカーに渡されます。

-dy
–G
-R

警告

共有ライブラリの構築には、ld -G ではなく、CC -G を使用してください。こうすると、CC ドライバによって C++ に必要ないくつかのオプションが ld に自動的に渡されます。

-G オプションを使用すると、コンパイラはデフォルトの -l オプションを ld に渡しません。共有ライブラリを別の共有ライブラリに依存させる場合は、必要な -l オプションをコマンド行に渡す必要があります。たとえば、共有ライブラリを libCrun に依存させる場合は、-lCrun をコマンド行に渡す必要があります。

A.2.29 `-g`

dbx(1) または Debugger によるデバッグおよびパフォーマンスアナライザ analyzer(1) による解析用のシンボルテーブル情報を追加生成します。

コンパイラとリンカーに、デバッグとパフォーマンス解析に備えてファイルとプログラムを用意するように指示します。

これには、次の処理が含まれています。

オブジェクトファイルと実行可能ファイルのシンボルテーブル内に、詳細情報 (スタブ) を生成する。
デバッガがその一部の機能を実装するために呼び出すことのできるヘルパー関数を生成します。
最適化レベルが指定されていない場合は、関数のインライン生成を無効にします。つまり、最適化レベルも同時に指定されていない場合は、このオプションを使用すると +d オプションが指定されていることになります。-O または -xO レベルが指定された -g では、インライン化は無効になりません。
特定のレベルの最適化を無効にする。

A.2.29.1 相互の関連性

このオプションと -xOlevel (あるいは、同等の -O オプションなど) を一緒に使用した場合、デバッグ情報が限定されます。詳細は、「A.2.151 -xOlevel」を参照してください。

このオプションを使用するとき、最適化レベルが -xO4 以上の場合、可能なかぎりのシンボリック情報と最高の最適化が得られます。最適化レベルを指定しないで —g を使用した場合、関数呼び出しのインライン化が無効になります (—g を使用して最適化レベルが指定されると、インラインが有効になります)。

このオプションを指定し、-O と -xO のどちらも指定していない場合は、+d +d オプションが自動的に指定されます。

パフォーマンスアナライザの機能を最大限に利用するには、-g オプションを指定してコンパイルします。一部のパフォーマンス分析機能は -g を必要としませんが、注釈付きのソースコード、一部の関数レベルの情報、およびコンパイラの注釈メッセージを確認するには、-g でコンパイルする必要があります。詳細は、analyzer(1) のマニュアルページおよびパフォーマンスアナライザのマニュアルを参照してください。

-g オプションで生成される注釈メッセージは、プログラムのコンパイル時にコンパイラが実行した最適化と変換について説明します。メッセージを表示するには、er_src(1) コマンドを使用します。これらのメッセージはソースコードでインタリーブされます。

警告

プログラムを別々の手順でコンパイルしてリンクしてから、1 つの手順に -g オプションを取り込み、ほかの手順から -g オプションを除外すると、プログラムの正確さは損なわれませんが、プログラムをデバッグする機能に影響します。-g (または -g0) でコンパイルされず、-g (または -g0) とリンクされているモジュールは、デバッグ用に正しく作成されません。通常、main 関数の入っているモジュールをデバッグするには、-g オプション (または -g0 オプション) でコンパイルする必要があります。

A.2.30 `-g0`

デバッグ用にコンパイルとリンクを行いますが、インライン化は無効にしません。

このオプションは、+d が無効になり、dbx がインライン化された関数でステップイン機能を使用できない点を除き、-g と同じです。

-xO3 以下の最適化レベルで -g0 を指定すると、ほとんど完全な最適化と可能なかぎりのシンボル情報を取得することができます末尾呼び出しの最適化とバックエンドのインライン化は無効です。

A.2.30.1 関連項目

+d、-g、『dbx コマンドによるデバッグ』

A.2.31 `-g3`

追加のデバッグ情報を生成します。

-g3 オプションは、-g0 と同じですが、dbx がソースコード内のマクロの展開を表示できるようにするためのデバッグシンボルテーブル情報が追加されています。この追加のシンボルテーブル情報により、-g0 でのコンパイルに比べて、結果として得られる .o ファイルや実行可能ファイルのサイズが増加する場合があります。

A.2.32 `–H`

インクルードされるファイルのパス名を出力します。

現在のコンパイルに含まれている #include ファイルのパス名を標準エラー出力 (stderr) に 1 行に 1 つずつ出力します。

A.2.33 `-hname`

生成する動的共有ライブラリに名前 name を割り当てます。動的共有ライブラリ

これは ld に渡されるリンカーオプションです。通常、-h のあとに指定する name (名前) は、-o のあとに指定する名前と同じでなければいけません。-h と name の間には、空白文字を入れても入れなくてもかまいません。

コンパイルの時ローダーは、作成対象の共有動的ライブラリに、指定の名前を割り当てます。この名前は、ライブラリのイントリンシック名として、ライブラリファイルに記録されます。-hname (名前) オプションを指定しないと、イントリンシック名はライブラリファイルに記録されません。

実行可能ファイルはすべて、必要な共有ライブラリファイルのリストを持っています。実行時のリンカーは、ライブラリを実行可能ファイルにリンクするとき、ライブラリのイントリンシック名をこの共有ライブラリファイルのリストの中にコピーします。共有ライブラリにイントリンシック名がないと、リンカーは代わりにその共有ライブラリファイルのパス名を使用します。

-h オプションを指定せずに共有ライブラリを構築する場合は、実行時のローダーはライブラリのファイル名のみを検索します。ライブラリを、同じファイル名を持つほかのライブラリに置換することもできます。共有ライブラリにイントリンシック名がある場合は、ローダーはファイルを読み込むときにイントリンシック名を確認します。イントリンシック名が一致しない場合は、ローダーは置換ファイルを使用しません。

A.2.33.1 例

example% CC -G -o libx.so.1 -h libx.so.1 a.o b.o c.o

A.2.34 `-help`

-xhelp=flags と同じです。

A.2.35 `-Ipathname`

#include ファイル検索パスに pathname を追加します。

このオプションは、相対ファイル名 (スラッシュ以外の文字で始まるファイル名) を持つ #include ファイルを検索するためのディレクトリリストに、pathname (パス名) を追加します。

コンパイラは、引用符付きのインクルードファイル (形式は #include "foo.h") を次の順序で検索します。

ソースが存在するディレクトリ
-I オプションで指定したディレクトリ内 (存在する場合)
コンパイラで提供される C++ ヘッダーファイル、ANSI C ヘッダーファイル、および特殊目的ファイルの include ディレクトリ内
/usr/include ディレクトリ内

コンパイラは、山括弧をインクルードしたファイル (形式は #include <foo.h>) を次の順序で検索します。

-I オプションで指定したディレクトリ内 (存在する場合)
コンパイラで提供される C++ ヘッダーファイル、ANSI C ヘッダーファイル、および特殊目的ファイルの include ディレクトリ内
/usr/include ディレクトリ内

注 - スペルが標準ヘッダーファイルの名前と一致する場合は、「11.7.5 標準ヘッダーの実装」も参照してください。

A.2.35.1 相互の関連性

-I- オプションを指定すると、デフォルトの検索規則が無効になります。

-library=no%Cstd を指定すると、その検索パスに C++ 標準ライブラリに関連付けられたコンパイラで提供されるヘッダーファイルがコンパイラでインクルードされません。「11.7 C++ 標準ライブラリの置き換え」を参照してください。

-ptipath が使用されていないと、コンパイラは -Ipathname でテンプレートファイルを検索します。

-ptipathの代わりに -Ipathname を使用します。

このオプションは、置き換えられる代わりに蓄積されます。

警告

コンパイラがインストールされている位置の /usr/include、/lib、/usr/lib を検索ディレクトリに指定しないでください。

A.2.36 `-I-`

インクルードファイル検索規則を変更します。

#include "foo.h" 形式のインクルードファイルの場合、次の順序でディレクトリを検索します。

1. -I オプションで指定されたディレクトリ内 (-I- の前後)

2. コンパイラで提供される C++ ヘッダーファイル、ANSI C ヘッダーファイル、および特殊な目的のファイルのディレクトリ

3. /usr/include ディレクトリ

#include <foo.h> 形式のインクルードファイルの場合、次の順序でディレクトリを検索します。

1. -I- のあとに現れる -I オプションで指定されたディレクトリ。

2. コンパイラで提供される C++ ヘッダーファイル、ANSI C ヘッダーファイル、および特殊な目的のファイルのディレクトリ

3. /usr/include ディレクトリ

注 - インクルードファイルの名前が標準ヘッダーの名前と一致する場合は、「11.7.5 標準ヘッダーの実装」も参照してください。

A.2.36.1 例

次の例は、prog.cc のコンパイル時に -I- を使用した結果を示します。

prog.cc
#include "a.h"
#include <b.h>
#include "c.h"
c.h
#ifndef _C_H_1
#define _C_H_1
int c1;
#endif
inc/a.h
#ifndef _A_H
#define _A_H
#include "c.h"
int a;
#endif
inc/b.h
#ifndef _B_H
#define _B_H
#include <c.h>
int b;
#endif
inc/c.h
#ifndef _C_H_2
#define _C_H_2
int c2;
#endif

次のコマンドでは、#include "foo.h" 形式のインクルード文のカレントディレクトリ (インクルードしているファイルのディレクトリ) のデフォルトの検索動作を示します。#include "c.h" ステートメントを inc/a.h で処理するときは、コンパイラで inc サブディレクトリから c.h ヘッダーファイルがインクルードされます。#include "c.h" 文を prog.cc で処理するときは、コンパイラで prog.cc を含むディレクトリから c.h ファイルがインクルードされます。-H オプションがインクルードファイルのパスを印刷するようにコンパイラに指示していることに注意してください。

example% CC -c -Iinc -H prog.cc
inc/a.h
        inc/c.h
inc/b.h
        inc/c.h
c.h

次のコマンドでは、-I- オプションの影響を示します。コンパイラでは、#include "foo.h" 形式の文を処理するときにインクルードしているディレクトリを最初に探しません。代わりに、コマンド行に配置されている順番で、-I オプションで命名されたディレクトリを検索します。#include "c.h" 文を inc/a.h で処理するときは、コンパイラで ./c.h ヘッダーファイルが、inc/c.h ヘッダーファイルの代わりにインクルードされます。

example% CC -c -I. -I- -Iinc -H prog.cc
inc/a.h
        ./c.h
inc/b.h
        inc/c.h
./c.h

相互の関連性

-I- がコマンド行に現れると、現在のディレクトリが -I 指令で明示的に指定されていないかぎり、コンパイラは現在のディレクトリを検索しません。この影響は #include "foo.h" 形式のインクルード文にも及びます。

警告

コマンド行の最初の -I- だけが、説明した動作を引き起こします。

コンパイラがインストールされている位置の /usr/include、/lib、/usr/lib を検索ディレクトリに指定しないでください。

A.2.37 `-i`

リンカー ld に、LD_LIBRARY_PATH と LD_LIBRARY_PATH_64 の設定をすべて無視するよう指示します。

A.2.38 `-include` `filename`

このオプションを指定すると、コンパイラは filename を、主要なソースファイルの 1 行目に記述されているかのように #include プリプロセッサ指令として処理します。ソースファイル t.c の考慮:

main()
{
   ...
}

t.c を cc -include t.h t.c コマンドを使用してコンパイルする場合は、ソースファイルに次の内容が含まれているかのようにコンパイルが進行します。

#include "t.h"
main()
{
   ...
}

コンパイラが filename を検索する最初のディレクトリは現在の作業ディレクトリであり、ファイルが明示的にインクルードされている場合のようにメインのソースファイルが存在するディレクトリになるわけではありません。たとえば、次のディレクトリ構造では、同じ名前を持つ 2 つのヘッダーファイルが異なる場所に存在しています。

foo/
   t.c
   t.h
   bar/
     u.c
     t.h

作業ディレクトリが foo/bar であり、cc ../t.c -include t.h コマンドを使用してコンパイルする場合は、コンパイラによって foo/bar ディレクトリから取得された t.h がインクルードされますが、ソースファイル t.c 内で #include 指令を使用した場合の foo/ ディレクトリとは異なります。

-include で指定されたファイルをコンパイラが現在の作業ディレクトリ内で見つけることができない場合は、コンパイラは通常のディレクトリパスでこのファイルを検索します。複数の -include オプションを指定する場合は、コマンド行で表示された順にファイルがインクルードされます。

A.2.39 `-inline`

-xinline と同じです。

A.2.40 `-instances`=a

テンプレートインスタンスの位置とリンケージを制御します。

A.2.40.1 値

a は、次の表に示されている値のいずれかである必要があります。

表 A-12 -instances の値

値	意味
`extern`	必要なすべてのインスタンスをテンプレートリポジトリのリンカー comdat セクション内に置き、それらに対して大域リンケージを行います。リポジトリのインスタンスが古い場合は、再びインスタンス化されます。注: コンパイルとリンクを別々に行うとき、コンパイル処理で `-instance=extern` を指定した場合には、リンク処理でも -instance=extern を指定する必要があります。
`explicit`	明示的にインスタンス化されたインスタンスを現在のオブジェクトファイルに置き、それらに対して大域リンケージを行います。必要なインスタンスがほかにあっても生成しません。
`global`	必要なすべてのインスタンスを現在のオブジェクトファイルに置き、それらに対して大域リンケージを行います。
`semiexplicit`	明示的にインスタンス化されたインスタンスを現在のオブジェクトファイルに置き、それらに対して大域リンケージを行います。明示的なインスタンスにとって必要なすべてのインスタンスを現在のオブジェクトファイルに置き、それらに対して大域リンケージを行います。必要なインスタンスがほかにあっても生成しません。
`static`	注: `-instances=static` は非推奨です。現在では `-instances=global` によって static のすべての利点が得られ、欠点はなくなっているため、`-instances=static` を使用する必要はなくなりました。このオプションは、このバージョンのコンパイラには存在しない、旧リリースのコンパイラにあった問題を克服するために用意されていました。必要なすべてのインスタンスを現在のオブジェクトファイルに置き、それらに対して静的リンケージを行います。

デフォルト

-instances を指定しないと、-instances=global が想定されます。

A.2.41 `-instlib=` `filename`

このオプションを使用すると、ライブラリ (共有、静的) と現在のオブジェクトで重複するテンプレートインスタンスの生成が禁止されます。一般に、ライブラリを使用するプログラムが多数のインスタンスを共有する場合、-instlib=filename を指定して、コンパイル時間の短縮を試みることができます。

A.2.41.1 値

現在のコンパイルで生成できるテンプレートインスタンスを含むライブラリを指定するには、filename 引数を使用します。ファイル名引数には、スラッシュ (/) 文字を含める必要があります。現在のディレクトリに関連するパスの場合には、ドットスラッシュ (./) を使用します。

デフォルト

-instlib=filename オプションにはデフォルト値はないので、値を指定する場合にのみ使用します。このオプションは複数回指定でき、指定内容は追加されていきます。

例

libfoo.a ライブラリと libbar.so ライブラリが、ソースファイル a.cc と共有する多数のテンプレートインスタンスをインスタンス化すると仮定します。-instlib=filename を追加してライブラリを指定すると、冗長性が回避されコンパイル時間を短縮できます。

example% CC -c -instlib=./libfoo.a -instlib=./libbar.so a.cc

相互の関連性

-g を使ってコンパイルするとき、-instlib=file で指定したライブラリが -g でコンパイルされていない場合には、テンプレートインスタンスがデバッグ不能となります。この問題の対策としては、-g を指定するときに -instlib=}file を使用しないようにします。

警告

-instlib によってライブラリを指定する場合には、そのライブラリとのリンクを行う必要があります。

A.2.42 `-KPIC`

SPARC: (廃止) -xcode=pic32 と同じです。

x86: -Kpic と同じです。

このオプションは、共有ライブラリを構築するためにソースファイルをコンパイルするときに使用します。大域データへの各参照は、大域オフセットテーブルにおけるポインタの間接参照として生成されます。各関数呼び出しは、手続きリンケージテーブルを通してプログラムカウンタ (PC) 相対アドレス指定モードで生成されます。

A.2.43 `-Kpic`

SPARC: (廃止) -xcode=pic13 と同じです。

x86: 位置に依存しないコードを使ってコンパイルします。

A.2.44 `-keeptmp`

コンパイル中に作成されたすべての一時ファイルを残します。

このオプションを -verbose=diags と一緒に使用すると、デバッグに便利です。

A.2.44.1 関連項目

-v、-verbose

A.2.45 `-L`path

ライブラリを検索するディレクトリのリストに path を追加します。

このオプションは ld に渡されます。コンパイラが提供するディレクトリよりも path が先に検索されます。

A.2.45.1 相互の関連性

このオプションは、置き換えられる代わりに蓄積されます。

警告

コンパイラがインストールされている位置の /usr/include、/lib、/usr/lib を検索ディレクトリに指定しないでください。

A.2.46 `-l`lib

ライブラリ liblib.a または liblib.so をリンカーの検索ライブラリに追加します。

このオプションは ld に渡されます。ライブラリは一般に、liblib.a や liblib.so などの名前を持っています。ここで、lib と .a または .so の部分は必須です。このオプションでは lib の部分を指定できます。ライブラリは 1 つのコマンド行にいくつでも置くことができます。ライブラリは、-Ldir で指定された順序で検索されます。

このオプションはファイル名のあとに使用してください。

A.2.46.1 相互の関連性

このオプションは、置き換えられる代わりに蓄積されます。

ライブラリが正しい順序で確実に検索されるようにするために、ソースとオブジェクトのリストのあとに -lx を置いてください。

警告

ライブラリを正しい順序で確実にリンクするには、-lthread ではなく -mt を使用して libthread にリンクする必要があります。

A.2.47 `-libmieee`

-xlibmieee と同じです。

A.2.48 `-libmil`

-xlibmil と同じです。

A.2.49 `-library=`l[ `,`l...]

l に指定した、CC が提供するライブラリを、コンパイルとリンクに組み込みます。

A.2.49.1 値

キーワード l は、次の表の値のいずれかである必要があります。no% 接頭辞によって、関連付けられたオプションが無効になります。

表 A-13 -library の値

値	意味
`[no%]f77`	非推奨。`-xlang=f77` を使用してください。
`[no%]f90`	非推奨。`-xlang=f90` を使用してください。
`[no%]f95`	非推奨。`-xlang=f95` を使用してください。
`[no%]rwtools7`	古い iostream `Tools.h++` Version 7 を使用します。
`[no%]rwtools7_dbg`	デバッグが可能な古い iostream `Tools.h++` Version 7 を使用します。
`[no%]rwtools7_std`	標準 iostream `Tools.h++` Version 7 を使用します。
`[no%]rwtools7_std_dbg`	デバッグが可能な標準 iostream `Tools.h++` Version 7 を使用します。
`[no%]interval`	非推奨。使用しないでください。`-xia` を使用します。
`[no%]iostream`	古い iostream ライブラリ `libiostream` を使用します。
`[no%]Cstd`	C++ 標準ライブラリ `libCstd` を使用します。コンパイラで提供される C++ 標準ライブラリヘッダーファイルをインクルードします。
`[no%]Crun`	C++ 実行時ライブラリ `libCrun` を使用します。
`[no%]gc`	ガベージコレクション `libgc` を使用します。
`[no%]stlport4`	デフォルトの `libCstd` の代わりに STLport の標準ライブラリ実装 Version 4.5.3 を使用します。STLport の実装の詳細は、「12.2 STLport」を参照してください。
`[no%]stlport4_dbg`	STLport のデバッグ可能なライブラリを使用します。
`[no%]sunperf`	Sun Performance Library を使用します。
`[no%]stdcxx4`	デフォルトの `libCstd` の代わりに Solaris の Apache `stdcxx` Version 4 C++ 標準ライブラリを使用します。このオプションにより、`-mt` オプションも暗黙的に設定されます。`stdcxx` ライブラリには、マルチスレッドモードが必要です。このオプションは、コンパイルのたびに、およびアプリケーション全体のリンクコマンドで一貫して使用する必要があります。`-library=stdcxx4` を使用してコンパイルされたコードは、デフォルトの `-library=Cstd` または省略可能な `-library=stlport4` を使用してコンパイルされたコードと同じプログラムでは使用できません。
`%none`	`libCrun` の場合を除いて C++ ライブラリを使用しません。

A.2.49.2 デフォルト

標準モード (デフォルトモード)
- libCstd ライブラリは、-library=%none または -library=no%Cstd、-library=stdcxx4 または -library=stlport4 を使用して明確に除外されないかぎり常に含まれます。
- libCrun ライブラリは、-library=no%Crun を使用して明確に除外されないかぎり常に含まれます。

libm ライブラリは、-library=%none を指定した場合でも常に含まれます。

A.2.49.3 例

標準モードでどの C++ ライブラリも使用せずに (libCrun を除く) リンクするには:

example% CC -library=%none

標準モードで従来の iostream と RogueWave tools.h++ ライブラリを使用するには、次のコマンドを使用します。

example% CC –library=rwtools7,iostream

標準モードで標準の iostream と Rogue Wave tools.h++ ライブラリを使用するコマンドは次のとおりです。

example% CC -library=rwtools7_std

A.2.49.4 相互の関連性

-library でライブラリを指定すると、適切な -I パスがコンパイルで設定されます。リンクでは、適切な -L、-Y P、および -R パスと、-l オプションが設定されます。

このオプションは、置き換えられる代わりに蓄積されます。

区間演算ライブラリを使用するときは、libC、libCstd、または libiostream のいずれかのライブラリを取り込む必要があります。

-library オプションを使用すると、指定されたライブラリに対する -l オプションが正しい順序で処理されることが保証されます。たとえば、-library=rwtools7,iostream および -lirabary=iostream,rwtools7 のどちらでも、-l オプションは、-lrwtool -liostream の順序で ld に渡されます。

指定したライブラリは、システムサポートライブラリよりも前にリンクされます。

-library=stdcxx4 の場合は、Apache stdcxx ライブラリが Oracle Solaris プラットフォーム上の /usr/include と /usr/lib にインストールされている必要があります。

-library=sunperf と -xlic_lib=sunperf は同じコマンド行で使用できません。

どのコマンド行でも、-library=stlport4、-library=stdcxx4、または -library=Cstd オプションのうち使用できるオプションは、多くても 1 つだけです。

同時に使用できる Rogue Wave ツールライブラリは 1 つだけです。また、-library=stlport4 または -library=stdcxx4 を指定して Rogue Wave ツールライブラリと併用することはできません。

従来の iostream RogueWave ツールライブラリを標準モード (デフォルトモード) で取り込む場合は、libiostream も取り込む必要があります (詳細は、『C++ 移行ガイド』を参照してください)。標準 iostream RogueWave ツールライブラリは、標準モードでのみ使用できます。次のコマンド例は、RogueWave tools.h++ ライブラリオプションの有効もしくは無効な使用法について示します。

% CC -library=rwtools7,iostream foo.cc       <-- valid, classic iostreams
% CC -library=rwtools7 foo.cc                <-- invalid

% CC -library=rwtools7_std foo.cc            <-- valid, standard iostreams
% CC -library=rwtools7_std,iostream foo.cc   <-- invalid

libCstd と libiostream の両方を含めた場合は、プログラム内で古い形式と新しい形式の iostream を使用して同じファイルにアクセスしないように注意する必要があります (たとえば、cout と std::cout)。同じプログラム内に標準 iostream と従来の iostream が混在し、その両方のコードから同じファイルにアクセスすると、問題が発生する可能性があります。

Crun ライブラリも、Cstd と stlport4 のどちらのライブラリもリンクしない標準モードのプログラムは、C++ 言語のすべての機能は使用できません。

-xnolib を指定すると、-library は無視されます。

A.2.49.5 警告

別々の手順でコンパイルしてリンクする場合は、コンパイルコマンドに表示される一連の -library オプションをリンクコマンドにも表示する必要があります。

stlport4、Cstd、および iostream のライブラリは、固有の入出力ストリームを実装しています。これらのライブラリの 2 個以上を-library オプションを使って指定した場合、プログラム動作が予期しないものになる恐れがあります。STLport の実装の詳細は、「12.2 STLport」を参照してください。

これらのライブラリは安定したものではなく、リリースによって変わることがあります。

-I、-l、-R、-staticlib、-xia、-xlang、-xnolib、「警告:」、「12.2.1 再配布とサポートされる STLport ライブラリ」、『Tools.h++ User’s Guide』

-library=no%cstd オプションを使用して独自の C++ 標準ライブラリの使用を有効にする方法については、「11.7 C++ 標準ライブラリの置き換え」を参照してください。

A.2.50 `-m32`|`-m64`

コンパイルされたバイナリオブジェクトのメモリーモデルを指定します。

-m32 を使用すると、32 ビット実行可能ファイルと共有ライブラリが作成されます。-m64 を使用すると、64 ビット実行可能ファイルと共有ライブラリが作成されます。

ILP32 メモリーモデル (32 ビット int、long、ポインタデータ型) は、64 ビット対応ではないすべての Oracle Solaris プラットフォームおよび Linux プラットフォームでのデフォルトです。LP64 メモリーモデル (64 ビット long、ポインタデータ型) は 64 ビット対応の Linux プラットフォームのデフォルトです。-m64 は LP64 モデル対応のプラットフォームでのみ使用できます。

-m32 を使用してコンパイルされたオブジェクトファイルまたはライブラリを、-m64 を使用してコンパイルされたオブジェクトファイルまたはライブラリにリンクすることはできません。

-m32|-m64 を指定してコンパイルしたモジュールは、-m32 |-m64 を指定してリンクする必要があります。コンパイル時とリンク時の両方で指定する必要のあるコンパイラオプションの完全なリストについては、「3.3.3 コンパイル時とリンク時のオプション」を参照してください。

64 ビットプラットフォーム上で大量の静的データを使用するアプリケーション (-m64) には、-xmodel=medium も必要になることがあります。一部の Linux プラットフォームは、ミディアムモデルをサポートしていません。

以前のコンパイラリリースでは、-xarch で命令セットを選択すると、メモリーモデル ILP32 または LP64 が使用されていました。ほとんどのプラットフォーム上では Solaris Studio 12 コンパイラで開始し、コマンド行に -m64 だけを追加することが、64 ビットオブジェクトを作成するための正しい方法です。

Oracle Solaris では、-m32 がデフォルトです。64 ビットプログラムをサポートする Linux システムでは、-m64 -xarch=sse2 がデフォルトです。

A.2.50.1 関連項目

-xarch.

A.2.51 `-mc`

オブジェクトファイルの ELF .comment セクションから重複した文字列を削除します。-mc オプションを使用すると、mcs -c コマンドが呼び出されます。詳細は、mcs(1) のマニュアルページを参照してください。

A.2.52 `-misalign`

SPARC: 廃止。このオプションは使用しないでください。代わりに -xmemalign=2i を使用してください。

A.2.53 `-mr`[`,` `string`]

オブジェクトファイルの .comment セクションからすべての文字列を削除します。string が与えられた場合、そのセクションに string を埋め込みます。文字列に空白が含まれている場合は、文字列を引用符で囲む必要があります。このオプションを使用すると、mcs -d [-a string] が呼び出されます。

A.2.54 `-mt`[`=`{`yes` |`no`}]

このオプションを使用して、Oracle Solaris スレッドまたは POSIX スレッドの API を使用しているマルチスレッド化コードをコンパイルおよびリンクします。-mt=yes オプションにより、ライブラリが適切な順序でリンクされることが保証されます。

このオプションは -D_REENTRANT をプリプロセッサに渡します。

Oracle Solaris スレッドを使用するには、thread.h ヘッダーファイルをインクルードし、—mt=yes オプション付きでコンパイルします。Oracle Solaris プラットフォーム上で POSIX スレッドを使用するには、pthread.h ヘッダーファイルをインクルードし、-mt=yes -lpthread オプションを使用してコンパイルします。

Linux プラットフォーム上では、POSIX スレッドの API のみが使用できます (Linux プラットフォームには libthread はありません)。したがって、Linux プラットフォームで —mt=yes を使用すると、—lthread の代わりに —lpthread が追加されます。Linux プラットフォームで POSIX スレッドを使用するには、—mt=yes を使用してコンパイルします。

—G を使用してコンパイルする場合は、—mt=yes を指定しても、—lthread と —lpthread のどちらも自動的には含められません。共有ライブラリを構築する場合は、これらのライブラリを明示的にリストする必要があります。

(OpenMP 共有メモリー並列化 API を使用するための) —xopenmp オプションには、—mt=yes が自動的に含まれます。

-mt=yes を指定してコンパイルを実行し、リンクを個別の手順でリンクする場合は、コンパイル手順と同様にリンク手順でも -mt=yes オプションを使用する必要があります。-mt を使用して 1 つの変換ユニットをコンパイルおよびリンクする場合は、-mt を指定してプログラムのすべてのユニットをコンパイルおよびリンクする必要があります。

-mt=yes は、コンパイラのデフォルトの動作です。この動作が望ましくない場合は、-mt=no でコンパイルします。

オプション —mt は —mt=yes と同じです。

A.2.54.1 関連項目

-xnolib、Oracle Solaris『Multithreaded Programming Guide』および『リンカーとライブラリ』

A.2.55 `-native`

-xtarget=native と同じです。

A.2.56 `-noex`

-features=no%except と同じです。

A.2.57 `-nofstore`

x86: コマンド行の -fstore を取り消します。

式を強制的に -fstore によって呼び出される代入先の変数の精度にすることを取り消します。-nofstore は、-fast によって呼び出されます。通常は、-fstore がデフォルトです。

A.2.57.1 関連項目

-fstore

A.2.58 `-nolib`

-xnolib と同じです。

A.2.59 `-nolibmil`

-xnolibmil と同じです。

A.2.60 `-norunpath`

実行可能ファイルに共有ライブラリへの実行時検索パスを組み込みません。

実行可能ファイルが共有ライブラリを使用する場合、コンパイラは通常、実行時のリンカーに対して共有ライブラリの場所を伝えるために構築を行なったパス名を知らせます。これは、ld に対して -R オプションを渡すことによって行われます。このパスはコンパイラのインストール先によって決まります。

このオプションは、プログラムで参照される共有ライブラリの異なるパスを使用する可能性のある顧客に出荷される実行可能ファイルの構築に推奨されます。「11.6 共有ライブラリの使用」を参照してください。

A.2.60.1 相互の関連性

共有ライブラリをコンパイラのインストールされている位置で使用し、かつ -norunpath を使用する場合は、リンク時に -R オプションを使うか、または実行時に環境変数 LD_LIBRARY_PATH を設定して共有ライブラリの位置を明示しなければいけません。そうすることにより、実行時リンカーはそれらの共有ライブラリを検索できるようになります。

A.2.61 `-O`

-O マクロは -xO3 に展開されます。(以前の一部のリリースでは、-O を -xO2 に展開していました)。

このデフォルトの変更によって、実行時のパフォーマンスが向上します。ただし、あらゆる変数を自動的に volatile と見なすことを前提にするプログラムの場合、 -xO3 は不適切なことがあります。この前提を持つ典型的なプログラムは、独自の同期処理プリミティブを実装するデバイスドライバや古いマルチスレッドアプリケーションです。回避策は、-O ではなく、-xO2 でコンパイルすることです。

A.2.62 `-Olevel`

-xOlevel と同じです。

A.2.63 `-o` `filename`

出力ファイルまたは実行可能ファイルの名前を filename (ファイル名) に指定します。

A.2.63.1 相互の関連性

コンパイラは、テンプレートインスタンスを格納する必要がある場合には、出力ファイルのディレクトリにあるテンプレートリポジトリに格納します。たとえば、次のコマンドでは、コンパイラはオブジェクトファイルを ./sub/a.o に、テンプレートインスタンスを ./sub/SunWS_cache 内のリポジトリにそれぞれ書き込みます。

example% CC -instances=extern -o sub/a.o a.cc

コンパイラは、読み込むオブジェクトファイルに対応するテンプレートリポジトリからテンプレートインスタンスを読み取ります。たとえば、次のコマンドは ./sub1/SunWS_Cache と ./sub2/SunWS_cache を読み取り、必要な場合は ./SunWS_cache に書き込みます。

example% CC -instances=extern sub1/a.o sub2/b.o

詳細は、「7.4 テンプレートリポジトリ」を参照してください。

警告

この filename は、コンパイラが作成するファイルの型に合った接尾辞を含むする必要があります。-c とともに使用されると、filename はターゲットの .o オブジェクトファイルを指定します。-G とともに使用されると、ターゲットの .so ライブラリファイルを指定します。このオプションとその引数は ld に渡されます。

CC ドライバはソースファイルを上書きしないため、filename をソースファイルと同じファイルにすることはできません。

A.2.64 `+p`

標準に従っていないプリプロセッサの表明を無視します。

A.2.64.1 デフォルト

+p を指定しないと、コンパイラは非標準のプリプロセッサの表明を認識します。

相互の関連性

+p を指定している場合は、次のマクロは定義されません。

sun
unix
sparc
i386

A.2.65 `-P`

ソースの前処理だけでコンパイルはしません (接尾辞 .i のファイルを出力します)。

このオプションを指定すると、プリプロセッサが出力するような行番号情報はファイルに出力されません。

A.2.65.1 関連項目

-E

A.2.66 `-p`

廃止。「A.2.159 -xpg」を参照してください。

A.2.67 `-pentium`

x86: -xtarget=pentium と置き換えられています。

A.2.68 `-pg`

廃止。-xpg を使用します。

A.2.69 `-PIC`

SPARC: -xcode=pic32 と同じです。

x86: -Kpic と同じです。

A.2.70 `-pic`

SPARC: -xcode=pic13 と同じです。

x86: -Kpic と同じです。

A.2.71 `-pta`

-template=wholeclass と同じです。

A.2.72 `-ptipath`

テンプレートソース用の検索ディレクトリを追加指定します。

このオプションは -Ipathname (パス名) によって設定された通常の検索パスに代わるものです。-ptipath (パス) フラグを使用した場合、コンパイラはこのパス上にあるテンプレート定義ファイルを検索し、-Ipathname フラグを無視します。

-ptipath よりも -Ipathname を使用すると混乱が起きにくくなります。

A.2.72.1 相互の関連性

このオプションは、置き換えられる代わりに蓄積されます。

A.2.72.2 関連項目

–Ipathname および「7.5.2 定義検索パス」

A.2.73 `-pto`

-instances=static と同じです。

A.2.74 `-ptv`

-verbose=template と同じです。

A.2.75 `-Qoption` `phase option`[`,option…`]

option (オプション) を phase (コンパイル段階) に渡します。

複数のオプションを渡すには、コンマで区切って指定します。-Qoption でコンポーネントに渡されるオプションは、順序が変更されることがあります。ドライバが認識するオプションは、正しい順序に保持されます。ドライバがすでに認識しているオプションに、-Qoption は使わないでください。たとえば C++ コンパイラは、リンカー (ld) に対する -z オプションを認識します。次の例のようなコマンドを発行すると、-z オプションが適切な順序でリンカーに渡されます。

     CC -G -zallextract mylib.a -zdefaultextract ... // correct

ただし、次の例のようなコマンドを指定した場合は、-z オプションを並べ替えることはできますが、正しくない結果になります。

     CC -G -Qoption ld -zallextract mylib.a -Qoption ld -zdefaultextract ... // error

A.2.75.1 値

phase には、次の表に示されている値のいずれかを指定する必要があります。

表 A-14 -Qoption の値

SPARC	x86
`ccfe`	`ccfe`
`iropt`	`iropt`
`cg`	`ube`
`CClink`	`CClink`
`ld`	`ld`

A.2.75.2 例

次のコマンドでは、ld が CC ドライバによって呼び出されると、-Qoption は ld に -i オプションと -m オプションを渡します。

example% CC -Qoption ld -i,-m test.c

A.2.75.3 警告

意図しない結果にならないように注意してください。たとえば、次のオプションのシーケンス

-Qoption ccfe -features=bool,iddollar

は次のように解釈されます。

-Qoption ccfe -features=bool -Qoption ccfe iddollar

正しい指定は次のとおりです。

-Qoption ccfe -features=bool,-features=iddollar

これらの機能は -Qoption を必要とせず、例としてのみ使用されています。

A.2.76 `-qoption` `phase option`

-Qoption と同じです。

A.2.77 `-qp`

-p と同じです。

A.2.78 `-Qproduce` `sourcetype`

CC ドライバに sourcetype (ソースタイプ) 型のソースコードを生成するよう指示します。

Sourcetype 接尾辞は、次の表で定義されています。

表 A-15 -Qproduce の値

接尾辞	意味
`.i`	`ccfe` が作成する前処理済みの C++ のソースコード
`.o`	生成されるオブジェクトコード
`.s`	`cg` が作成するアセンブラソース

A.2.79 `-qproduce` `sourcetype`

-Qproduce と同じです。

A.2.80 `-Rpathname`[ `:pathname…`]

動的ライブラリの検索パスを実行可能ファイルに組み込みます。

このオプションは ld に渡されます。

A.2.80.1 デフォルト

-R オプションが存在しない場合、出力オブジェクトに記録され、実行時リンカーに渡されるライブラリ検索パスは、-xarch オプションで指定されたターゲットアーキテクチャー命令によって異なります。-xarch が存在しない場合は、-xarch=generic が使用されます。

コンパイラが想定するデフォルトのパスを表示するには、—dryrun と —R の各オプションをリンカー ld に渡して出力を検査します。

A.2.80.2 相互の関連性

このオプションは、置き換えられる代わりに蓄積されます。

LD_RUN_PATH 環境変数が設定されている場合に、-R オプションを指定すると、-R に指定したパスが検索され、LD_RUN_PATH のパスは無視されます。

A.2.80.3 関連項目

-norunpath、『リンカーとライブラリ』

A.2.81 `-S`

コンパイルしてアセンブリコードだけを生成します。

CC ドライバはプログラムをコンパイルして、アセンブリソースファイルを作成します。しかし、プログラムのアセンブルは行いません。このアセンブリソースファイル名には、.s という接尾辞が付きます。

A.2.82 `-s`

実行可能ファイルからシンボルテーブルを取り除きます。

出力する実行可能ファイルからシンボリック情報をすべて削除します。このオプションは ld に渡されます。

A.2.83 `-staticlib`=`l`[ `,l…`]

-library オプションで指定されたライブラリ (そのデフォルトを含む)、-xlang オプションで指定されたライブラリ、および -xia オプションで指定されたライブラリのうち、どの C++ ライブラリが静的にリンクされるかを示します。

A.2.83.1 値

l は、次の表に示されている値のいずれかである必要があります。

表 A-16 -staticlib の値

値	意味
`[no%]library`	`library` を静的にリンクします。`library` に有効な値は、`-library` で有効なすべての値 (`%all` と `%none` を除く)、`-xlang` で有効なすべての値、および (`-xia` とともに使用される) `interval` です。
`%all`	`-library オプション` で指定されているすべてのライブラリと、`-xlang` オプションで指定されているすべてのライブラリ、`-xia` をコマンド行で指定している場合は区間ライブラリを静的にリンクします。
`%none`	`-library` オプションと `-xlang` オプションに静的に指定されているライブラリをリンクしません。`-xia` をコマンド行に指定した場合は、区間ライブラリを静的にリンクしません。

A.2.83.2 デフォルト

-staticlib を指定しないと、-staticlib=%none が想定されます。

A.2.83.3 例

Crun は -library のデフォルト値であるため、次のコマンドは libCrun を静的にリンクします。

example% CC –staticlib=Crun (correct)

ただし、libgc は -library オプションで明示的に指定されないかぎりリンクされないため、次のコマンドは libgc をリンクしません。

example% CC –staticlib=gc (incorrect)

libgc を静的にリンクするには、次のコマンドを使用します。

example% CC -library=gc -staticlib=gc (correct)

次のコマンドは、librwtool ライブラリを動的にリンクします。librwtool はデフォルトのライブラリでもなく、-library オプションでも選択されていないため、-staticlib の影響はありません。

example% CC -lrwtool -library=iostream \
-staticlib=rwtools7 (incorrect)

次のコマンドは、librwtool ライブラリを静的にリンクします。

example% CC -library=rwtools7,iostream -staticlib=rwtools7 (correct)

次のコマンドは、Sun Performance Library を動的にリンクします。それは、これらのライブラリのリンクで -staticlib オプションを有効にするには、-library=sunperf を -staticlib=sunperf と組み合わせて使用する必要があるためです。

example% CC -xlic_lib=sunperf -staticlib=sunperf (incorrect)

このコマンドは、Sun Performance Library を静的にリンクします。

example% CC -library=sunperf -staticlib=sunperf (correct)

A.2.83.4 相互の関連性

このオプションは、置き換えられる代わりに蓄積されます。

-staticlib オプションは、デフォルトで暗黙的に選択された C++ ライブラリに加えて、-xia オプション、-xlang オプション、および -library オプションで明示的に選択された C++ ライブラリに対してのみ機能します。デフォルトでは、Cstd と Crun が選択されます。

A.2.83.5 警告

library に使用できる値は安定したものではないため、リリースによって変わることがあります。

Oracle Solaris プラットフォーム上では、システムライブラリは静的ライブラリとして使用できません。

A.2.83.6 関連項目

-library、「11.5 標準ライブラリの静的リンク」

A.2.84 `-sync_stdio=`[`yes`| `no`]

このオプションは、C++ の iostream と C の stdio の間の同期のために実行時のパフォーマンスが低下する場合に使用します。同期が必要なのは、同じプログラム内で iostream を使って cout に書き込み、stdio を使って stdout に書き込みを行う場合だけです。C++ 規格では同期が求められており、このため C++ コンパイラはデフォルトで同期を有効にします。ただし、しばしば、アプリケーションのパフォーマンスは同期なしの方が良くなることがあります。cout と stdout の一方にしか書き込みを行わない場合は、-sync_stdio=no オプションを使って同期を無効にすることができます。

A.2.84.1 デフォルト

-sync_stdio を指定しなかった場合は、-sync_stdio=yes が設定されます。

A.2.84.2 例

次の例を考えてみましょう。

#include <stdio.h>
#include <iostream>
int main()
{
   std::cout << "Hello ";
   printf("beautiful ");
   std::cout << "world!";
   printf("\n");
}

同期が有効な場合は、1 行だけ出力されます。

Hello beautiful world!
:

同期なしの場合、出力が混乱します。

A.2.84.3 警告

このオプションは、ライブラリではなく実行可能ファイルのリンクでのみ有効です。

A.2.85 `-temp=`path

一時ファイルのディレクトリを定義します。

このオプションは、コンパイル中に生成される一時ファイルを格納するディレクトリのパス名を指定します。コンパイラは -temp によって設定された値を、TMPDIR の値より優先します。

A.2.85.1 関連項目

-keeptmp

A.2.86 `-template`=`opt`[`,opt…`]

さまざまなテンプレートオプションを有効/無効にします。

A.2.86.1 値

opt は、次の表に示されている値のいずれかである必要があります。

表 A-17 -template の値

値	意味
`[no%]extdef`	別のソースファイル内のテンプレート定義を検索します。`no%extdef` を使用すると、コンパイラは `_TEMPLATE_NO_EXTDEF` を事前定義します。
`[no%]geninlinefuncs`	明示的にインスタンス化されたクラステンプレートのための非参照インラインメンバー関数を生成します。
`[no%]wholeclass`	使用されている関数だけでなく、テンプレートクラス全体をインスタンス化します。クラスの少なくとも 1 つのメンバーを参照する必要があります。それ以外の場合、コンパイラはそのクラスのどのメンバーもインスタンス化しません。

A.2.86.2 デフォルト

-template オプションを指定しないと、-template=no%wholeclass,extdef が使用されます。

A.2.86.3 例

次のコードについて考えてみましょう。

example% cat Example.cc
     template <class T> struct S {
               void imf() {}
               static void smf() {}
     };

     template class S <int>;

     int main() {
     }
example%

-template=geninlinefuncs を指定した場合、S の 2 つのメンバー関数は、プログラム内で呼び出されなくてもオブジェクトファイルに生成されます。

example% CC -c -template=geninlinefuncs Example.cc
example% nm -C Example.o

Example.o:

[Index] Value Size Type  Bind  Other Shndx Name
[5]       0   0    NOTY  GLOB  0     ABS   __fsr_init_value
[1]       0   0    FILE  LOCL  0     ABS   b.c
[4]      16   32   FUNC  GLOB  0     2     main
[3]     104   24   FUNC  LOCL  0     2     void S<int>::imf()
                                           [__1cBS4Ci_Dimf6M_v_]
[2]     64    20   FUNC  LOCL  0     2     void S<int>::smf()
                                           [__1cBS4Ci_Dsmf6F_v_]

A.2.86.4 関連項目

「7.2.2 全クラスインスタンス化」、「7.5 テンプレート定義の検索」

A.2.87 `-time`

-xtime と同じです。

A.2.88 `-traceback`[`=`{ `%none`|`common`|`signals_list`}]

実行時に重大エラーが発生した場合にスタックトレースを発行します。

-traceback オプションを指定すると、プログラムによって特定のシグナルが生成された場合に、実行可能ファイルで stderr へのスタックトレースが発行されて、コアダンプが実行され、終了します。複数のスレッドが 1 つのシグナルを生成すると、スタックトレースは最初のスレッドに対してのみ生成されます。

追跡表示を使用するには、リンク時に -traceback オプションをコンパイラコマンド行に追加します。このオプションはコンパイル時にも使用できますが、実行可能バイナリが生成されない場合無視されます。-traceback を -G とともに使用して共有ライブラリを作成しないでください。

表 A-18 -traceback オプション

オプション	意味
`common`	`sigill`、`sigfpe`、`sigbus`、`sigsegv`、または `sigabrt` の共通シグナルのいずれかのセットが発生した場合にスタックトレースを発行するべきであることを指定します。
`signals_list`	スタックトレースを生成するシグナルの名前 (小文字) のコンマ区切りリストを指定します。`sigquit`、 `sigill`、 `sigtrap`、 `sigabrt`、 `sigemt`、 `sigfpe`、 `sigbus`、 `sigsegv`、 `sigsys`、 `sigxcpu`、 `sigxfsz` のシグナル (コアファイルが生成されるシグナル) をキャッチできます。これらのシグナルの前に `no%` を指定すると、そのシグナルのキャッチが無効になります。たとえば、`-traceback=sigsegv,sigfpe` と指定すると、`sigsegv` または `sigfpe` が発生した場合にスタックトレースとコアダンプが生成されます。
`%none` または `none`	追跡表示を無効にします

このオプションを指定しない場合、デフォルトは -traceback=%none になります。

= 記号なしで、-traceback だけを指定すると、-traceback=common の意味になります。

注: コアダンプが必要ない場合は、次のコマンドを使用してコアダンプのサイズ制限を 0 に設定できます。

% limit coredumpsize 0

-traceback オプションは、実行時のパフォーマンスに影響しません。

A.2.89 `-U`name

プリプロセッサシンボル name の初期定義を削除します。

このオプションは、コマンド行に指定された (CC ドライバによって暗黙的に挿入されるものも含む) -D オプションによって作成されるマクロシンボル name の初期定義を削除します。ほかの定義済みマクロや、ソースファイル内のマクロ定義が影響を受けることはありません。

CC ドライバにより定義される -D オプションを表示するには、コマンド行に -dryrun オプションを追加します。

A.2.89.1 例

次のコマンドでは、事前に定義されているシンボル __sun を未定義にします。#ifdef (__sun) のような foo.cc 中のプリプロセッサ文では、シンボルが未定義であると検出されます。

example% CC -U__sun foo.cc

A.2.89.2 相互の関連性

コマンド行には複数の -U オプションを指定できます。

すべての -U オプションは、存在している任意の -D オプションのあとに処理されます。つまり、同じ name がコマンド行上の -D と -U の両方に指定されている場合は、オプションが表示される順序にかかわらず name は未定義になります。

A.2.89.3 関連項目

-D

A.2.90 `-unroll=`n

-xunroll=n と同じです。

A.2.91 `-V`

-verbose=version と同じです。

A.2.92 `-v`

-verbose=diags と同じです。

A.2.93 `-verbose`=`v`[`,v…`]

コンパイラメッセージの詳細度を制御します。

A.2.93.1 値

v は、次の表に示されている値のいずれかである必要があります。no% 接頭辞によって、関連付けられたオプションが無効になります。

表 A-19 -verbose の値

値	意味
`[no%]diags`	コンパイルパスごとにコマンド行を出力します。
`[no%]template`	テンプレートインスタンス化の `verbose` モード (「検証」モードとも呼ばれる) を有効にします。`verbose`モードはコンパイル中にインスタンス化の各段階の進行を表示します。
`[no%]version`	`CC` ドライバに、起動するプログラムの名前とバージョン番号を出力するよう指示します。
`%all`	ほかのすべてのオプションを起動します。
`%none`	`-verbose=%none` は `-verbose=no%template,no%diags,no%version` を指定することと同じです。

デフォルト

-verbose を指定されない場合、-verbose=%none が想定されます。

相互の関連性

このオプションは、置き換えられる代わりに蓄積されます。

A.2.94 `-Wc` `,arg`

指定されたコンポーネント c に引数 arg を渡します。

引数は前の引数からコンマでのみ区切る必要があります。すべての -W 引数は、残りのコマンド行引数のあとに渡されます。コンマを引数の一部として含めるには、コンマの直前にエスケープ文字 \ (バックスラッシュ) を使用します。すべての -W arg は、通常のコマンド行引数のあとに渡されます。

たとえば、-Wa,-o,objfile は、-o と objfile をこの順番でアセンブラに渡します。また、-Wl,-I,name; を指定すると、リンク段階で動的リンカー /usr/lib/ld.so.1 のデフォルト名が無効になります。

引数がツールに渡される順序は、ほかに指定されるコマンド行オプションとの関係で、今後のコンパイラリリースで変更される可能性があります。

c に指定可能な値を次の表に示します。

表 A-20 -W のフラグ

フラグ	意味
`a`	アセンブラ : (`fbe`); (`gas`)
`c`	C++ コードジェネレータ: (`cg`) (SPARC);
`d`	CC ドライバ
`l`	リンクエディタ (`ld`)
`m`	mcs
`O` (大文字の o)	相互手続きオプティマイザ
`o` (小文字 o)	ポストオプティマイザ
`p`	プリプロセッサ (`cpp`)
`0` (ゼロ)	コンパイラ (`ccfe`)
`2`	オプティマイザ: (`iropt`)

注: -Wd を使用して CC オプションを C++ コンパイラに渡すことはできません。

A.2.95 `+w`

意図しない結果が生じる可能性のあるコードを特定します。+w オプションは、関数が大きすぎてインライン化できない場合、および宣言されたプログラム要素が未使用の場合に警告を生成しません。これらの警告は、ソース中の実際の問題を特定するものではないため、開発環境によっては不適切です。そのような環境では、+w でこれらの警告を生成しないようにすることで、+w をより効果的に使用することができます。これらの警告は、+w2 オプションの場合は生成されます。

このオプションを指定すると、次のような問題のある構造に関する追加の警告が生成されます。

移植性がない
間違っていると考えられる
効率が悪い

A.2.95.1 デフォルト

+w オプションを指定しない場合、コンパイラは必ず問題となる構造についてのみ警告を出力します。

A.2.95.2 関連項目

-w、+w2

A.2.96 `+w2`

+w で発行されるすべての警告に加えて、おそらく害はないが、プログラムの最大の移植性を損なう可能性のある技術的な違反に関する警告を発行します。

+w2 オプションは、システムのヘッダーファイル中で実装に依存する構造が使用されている場合をレポートしなくなりました。システムヘッダーファイルが実装であるため、これらの警告は不適切でした。+w2 でこれらの警告を生成しないようにすることで、+w2 をより効果的に使用することができます。

A.2.96.1 関連項目

+w

A.2.97 `–w`

ほとんどの警告メッセージを抑止します。

このオプションは、コンパイラが警告を出力しない原因となります。ただし、一部の警告、特に旧式の構文に関する重要な警告は抑制できません。

A.2.97.1 関連項目

+w

A.2.98 `-Xlinker` `arg`

arg をリンカー ld(1) に渡します。—z arg と同等

A.2.99 `-Xm`

-features=iddollar と同じです。

A.2.100 `-xaddr32`

(Solaris x86/x64 のみ) コンパイラフラグ -xaddr32=yes は、結果として生成される実行可能ファイルまたは共有オブジェクトを 32 ビットアドレス空間に制限します。

この方法でコンパイルする実行可能ファイルは、32 ビットアドレス空間に制限されるプロセスを作成する結果になります。

-xaddr32=no が指定されている場合は、通常の 64 ビットバイナリが生成されます。

-xaddr32 オプションを指定しないと、-xaddr32=no が想定されます。

-xaddr32 だけを指定すると、-xaddr32=yes が想定されます。

このオプションは、-m64 コンパイルのみ、および SF1_SUNW_ADDR32 ソフトウェア機能をサポートしている Oracle Solaris プラットフォームのみに適用できます。Linux カーネルはアドレス空間制限をサポートしていないので、Linux ではこのオプションは使用できません。

単一オブジェクトファイルが -xaddr32=yes を指定してコンパイルされた場合、リンク時には、出力ファイル全体が -xaddr32=yes を指定してコンパイルされたものと見なされます。

32 ビットアドレス空間に制限される共有オブジェクトは、制限された 32 ビットモードのアドレス空間内で実行されるプロセスから読み込む必要があります。

詳細は、『リンカーとライブラリ』で説明されている SF1_SUNW_ADDR32 ソフトウェア機能の定義を参照してください。

A.2.101 `-xalias_level`[`=` `n`]

次のコマンドを指定すると、C++ コンパイラは、型に基づく別名の解析および最適化を実行できます。

-xalias_level[=n ]

ここで、n は any、simple、compatible のいずれかです。

A.2.101.1 `-xalias_level=any`

このレベルの解析では、ある型を別名で定義できるとものとして処理されます。ただしこの場合でも、一部の最適化が可能です。

A.2.101.2 `-xalias_level=simple`

単純型は別名で定義されていないものとして処理されます。記憶オブジェクトは、次のいずれかの単純型である動的な型を持っている必要があります。

char, signed char, unsigned char wchar_t, データポインタ型

short int, unsigned short int, int unsigned int, 関数ポインタ型

long int, unsigned long int, long long int, unsigned long long int, データメンバーポインタ型

float, double long double, 列挙型関数メンバーポインタ型

記憶オブジェクトには、次の型の左辺値を使用してのみアクセスするべきです。

オブジェクトの動的な型
オブジェクトの動的な型を constant または volatile で修飾したもの。つまり、オブジェクトの動的な型に相当する符号付きまたは符号なしの型。
オブジェクトの動的な型を constant または volatile で修飾したものに相当する、符号付きまたは符号なしの型。
前述の型のいずれかがメンバーに含まれる集合体または共用体 (再帰的に、その下位の集合体またはそれに含まれる共用体のメンバーについても該当します)。
char 型または unsigned char 型

A.2.101.3 `-xalias_level=compatible`

配置非互換の型は、別名で定義されていないものとして処理されます。記憶オブジェクトは、次の型の lvalue を使用してだけアクセスされます。

オブジェクトの動的な型
オブジェクトの動的な型を constant または volatile で修飾したもの。つまり、オブジェクトの動的な型に相当する符号付きまたは符号なしの型。
オブジェクトの動的な型を constant または volatile で修飾したものに相当する、符号付きまたは符号なしの型。
前述の型のいずれかがメンバーに含まれる集合体または共用体 (再帰的に、その下位の集合体またはそれに含まれる共用体のメンバーについても該当します)。
オブジェクトの動的な型の (多くの場合は constant または volatile で修飾した) 基本クラス型。
char 型または unsigned char 型

コンパイラでは、すべての参照の型が、対応する記憶オブジェクトの動的な型と配置の互換性があると想定します。2 つの型は、次の条件の場合に配置互換になります。

2 つの型が同じ型である場合
2 つの型が constant と volatile のどちらで修飾されたかという点だけが異なる場合
符号付き整数型のそれぞれについて、対応する (ただし、異なる) 符号なし整数型が存在する場合、これらの対応する型には配置の互換性があります。
2 つの列挙型は、基礎の型が同一の場合に配置互換になります。
2 つの Plain Old Data (POD) 構造体型は、メンバーの数が同じであり、かつ順序で対応するメンバーの型に配置の互換性がある場合に配置の互換性があります。
2 つの POD 共用体型は、メンバー数が同一で、対応するメンバー (順番は任意) が配置互換である場合に配置互換になります。

参照は、一部の場合に、記憶オブジェクトの動的な型と配置非互換になります。

POD 共用体に、開始シーケンスが共通の POD 構造体が複数含まれていて、その POD 共用体オブジェクトにそれらの POD 構造体のいずれかが含まれている場合は、任意の POD 構造体の共通の開始部分を調べることができます。2 つの POD 構造体が共通の開始シーケンスを共有していて、対応するメンバーの型が配置互換であり、開始メンバーのシーケンスでビットフィールドの幅が同一の場合に、2 つの POD 構造体は開始シーケンスが共通になります。
reinterpret_cast を使用して適切に変換された POD 構造体オブジェクトへのポインタは、その最初のメンバーか、またはそのメンバーがビットフィールドである場合はそのビットフィールドが存在するユニットを指します。

A.2.101.4 デフォルト

-xalias_level を指定しない場合は、コンパイラでは -xalias_level=any が指定されます。-xalias_level を値なしで指定した場合は、コンパイラでは -xalias_level=compatible が指定されます。

A.2.101.5 相互の関連性

コンパイラは、-xO2 以下の最適化レベルでは、型に基づく別名の解析および最適化を実行しません。

A.2.101.6 警告

reinterpret_cast またはこれに相当する旧形式のキャストを使用している場合には、解析の前提にプログラムが違反することがあります。また、次の例に示す共用体の型のパンニングも、解析の前提に違反します。

union bitbucket{
  int i;
  float f;
};

int bitsof(float f){
bitbucket var;
var.f=3.6;
return var.i;
}

A.2.102 `-xanalyze=`{`code`| `no`}

ソースコードの静的分析を生成します。Oracle Solaris Studio コードアナライザを使用して表示できます。

—xanalyze=code を指定してコンパイルし、別の手順でリンクするときは、リンク手順でも —xanalyze=code を含めてください。

デフォルトは —xanalyze=no です。詳細は、Oracle Solaris Studio コードアナライザのドキュメントを参照してください。

A.2.103 `-xannotate`[`=yes`| `no`]

(Solaris のみ) あとで最適化および可観測性ツール binopt(1)、code-analyzer(1)、discover(1)、collect(1)、および uncover(1) で使用できるバイナリを作成します。

デフォルトは -xannotate=yes です。値なしで -xannotate を指定することは、-xannotate=yes と同義です。

最適化および監視ツールを最適に使用するためには、コンパイル時とリンク時の両方で -xannotate=yes が有効である必要があります。最適化および監視ツールを使用しないときは、-xannotate=no を指定してコンパイルおよびリンクすると、バイナリとライブラリが若干小さくなります。

Linux システムでは、このオプションはありません。

A.2.104 `-xar`

アーカイブライブラリを作成します。

テンプレートを使用する C++ のアーカイブを構築する場合は、テンプレートリポジトリ内でインスタンス化されたテンプレート関数をそのアーカイブに含めます。テンプレートリポジトリは、少なくとも 1 つのオブジェクトファイルを -instances=extern オプションでコンパイルしたときにのみ使用されます。-xar を使用してコンパイルすると、それらのテンプレートが必要に応じてアーカイブに自動的に追加されます。

ただし、コンパイラのデフォルトではテンプレートキャッシュが使用されないため、多くの場合、-xar オプションは必要ありません。一部のコードが -instances=extern を使用してコンパイルされていないかぎり、通常の ar(1) コマンドを使用して C++ コードのアーカイブ (.a ファイル) を作成できます。その場合、または確信がない場合は、ar コマンドの代わりに CC -xar を使用します。

A.2.104.1 値

-xar を指定すると、ar -c -r が起動され、アーカイブがゼロから作成されます。

例

次のコマンド行は、ライブラリファイルとオブジェクトファイルに含まれるテンプレート関数をアーカイブします。

example% CC -xar -o libmain.a a.o b.o c.o

警告

テンプレートデータベースの .o ファイルをコマンド行に追加しないでください。

アーカイブを構築するときは、ar コマンドを使用しないでください。CC -xar を使用して、テンプレートのインスタンス化情報が自動的にアーカイブに含まれるようにしてください。

A.2.105 `–xarch=`isa

対象となる命令セットアーキテクチャー (ISA) を指定します。

このオプションは、コンパイラが生成するコードを、指定した命令セットアーキテクチャーの命令だけに制限します。このオプションは、すべてのターゲットを対象とするような命令としての使用は保証しません。ただし、このオプションを使用するとバイナリプログラムの移植性に影響を与える可能性があります。

注 - 意図するメモリーモデルとして LP64 (64 ビット) または ILP32 (32 ビット) を指定するには、それぞれ -m64 または -m32 オプションを使用してください。次に示すように、以前のリリースとの互換性を除き、-xarch オプションでメモリーモデルを指定できなくなりました。

アーキテクチャー固有の命令を使用する _asm 文またはインラインテンプレート (.il ファイル) を使用したコードには、コンパイルエラーを回避するために、適切な -xarch 値でのコンパイルが必要になることがあります。

別々の手順でコンパイルしてリンクする場合は、両方の手順に同じ -xarch の値を指定してください。コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧については、「3.3.3 コンパイル時とリンク時のオプション」を参照してください。

A.2.105.1 SPARC および x86 用の `-xarch` フラグ

次の表は、SPARC プラットフォームと x86 プラットフォームの両方に共通する -xarch キーワードの一覧です。

表 A-21 SPARC および x86 での -xarch フラグ

フラグ	意味
`generic`	ほとんどのプロセッサに共通の命令セットを使用します。これはデフォルト値です。
`generic64`	ほとんどの 64 ビットプラットフォームで良好なパフォーマンスになるようにコンパイルします。このオプションは `-m64` `-xarch=generic` と同義で、以前のリリースとの互換性のために提供されています。
`native`	このシステムで良好なパフォーマンスを得られるようにコンパイルします。現在コンパイルしているシステムプロセッサにもっとも適した設定を選択します。
`native64`	このシステムで良好なパフォーマンスになるようにコンパイルします。このオプションは `-m64` `-xarch=native` と同義で、以前のリリースとの互換性のために提供されています。

A.2.105.2 SPARC での `-xarch` のフラグ

次の表に、SPARC プラットフォームでの各 -xarch キーワードの詳細を示します。

表 A-22 SPARC プラットフォーム用の -xarch フラグ

フラグ	意味
`sparc`	VIS (Visual Instruction Set) を使用せず、その他の実装に固有の ISA 拡張機能も使用せずに、SPARC-V9 ISA 用にコンパイルします。このオプションを使用して、コンパイラは、V9 ISA で良好なパフォーマンスが得られるようにコードを生成できます。
`sparcvis`	SPARC-V9 + VIS (Visual Instruction Set) version 1.0 + UltraSPARC 拡張機能用のコンパイルを実行します。このオプションを使用すると、コンパイラは、UltraSPARC アーキテクチャー上で良好なパフォーマンスが得られるようにコードを生成することができます。
`sparcvis2`	UltraSPARC アーキテクチャー + VIS (Visual Instruction Set) version 2.0 + UltraSPARC-III 拡張機能用のオブジェクトコードを生成します。
`sparcvis3`	SPARC VIS version 3 の SPARC-V9 ISA 用にコンパイルします。SPARC-V9 命令セット、VIS (Visual Instruction Set) Version 1.0 を含む UltraSPARC 拡張機能、VIS (Visual Instruction Set) Version 2.0、積和演算 (FMA) 命令、および VIS (Visual Instruction Set) Version 3.0 を含む UltraSPARC-III 拡張機能の命令をコンパイラが使用できるようになります。
`sparcfmaf`	SPARC-V9 命令セット、VIS (Visual Instruction Set) version 1.0 を含む UltraSPARC 拡張機能、VIS (Visual Instruction Set) version 2.0 を含む UltraSPARC-III 拡張機能、および浮動小数点積和演算用の SPARC64 VI 拡張機能の命令をコンパイラが使用できるようになります。 `-xarch=sparcfmaf` は `fma=fused` と組み合わせて使用し、ある程度の最適化レベルを指定することで、コンパイラが自動的に積和命令の使用を試みるようにする必要があります。
`sparcima`	SPARC IMA バージョンの SPARC-V9 ISA 用にコンパイルします。コンパイラが、SPARC-V9 命令セットに加えて、VIS (Visual Instruction Set) Version 1.0 を含む UltraSPARC 拡張機能、VIS (Visual Instruction Set) Version 2.0 を含む UltraSPARC-III 拡張機能、浮動小数点の積和演算用の SPARC64 VI 拡張機能、整数の積和演算用の SPARC64 VII 拡張機能からの命令を使用できるようにします。
`sparc4`	SPARC4 バージョンの SPARC-V9 ISA 用にコンパイルします。コンパイラが SPARC-V9 命令セットからの命令、さらに拡張機能 (VIS 1.0 を含む)、UltraSPARC-III 拡張機能 (VIS 2.0 を含む)、浮動小数点積和演算 (FMA) 命令、VIS 3.0、および SPARC4 命令を使用できるようになります。
`v9`	`-m64` `-xarch=sparc` と同等です。64 ビットメモリーモデルを得るために `-xarch=v9` を使用する古いメイクファイルとスクリプトでは、`-m64` だけを使用すれば十分です。
`v9a`	`-m64` `-xarch=sparcvis` と同等で、以前のリリースとの互換性のために提供されています。
`v9b`	`-m64` `-xarch=sparcvis2` と同等で、以前のリリースとの互換性のために提供されています。

また、次のことにも注意してください。

generic、sparc、sparcvis2、sparcvis3、sparcfmaf、sparcima でコンパイルされたオブジェクトライブラリファイル (.o) をリンクして、一度に実行できます。ただし、実行できるのは、リンクされているすべての命令セットをサポートしているプロセッサのみです。
特定の設定で、生成された実行可能ファイルが実行されなかったり、従来のアーキテクチャーよりも実行速度が遅くなったりする場合があります。また、4 倍精度 (REAL*16 および long double) 浮動小数点命令は、これらの命令セットアーキテクチャーのいずれにも実装されないため、コンパイラは、そのコンパイラが生成したコードではそれらの命令を使用しません。

A.2.105.3 x86 での `-xarch` のフラグ

次の表に、x86 プラットフォームでの -xarch フラグを示します。

表 A-23 x86 上の -xarch フラグ

フラグ	意味
`amd64`	`-m64` `-xarch=sse2` と同等です (Solaris のみ)。64 ビットメモリーモデルを得るために `-xarch=amd64` を使用する古いメイクファイルとスクリプトでは、`-m64` だけを使用すれば十分です。
`amd64a`	`-m64` `-xarch=sse2a` と同等です (Solaris のみ)。
`pentium_pro`	命令セットを 32 ビット Pentium Pro アーキテクチャーに限定します。
`pentium_proa`	AMD 拡張機能 (3DNow!、3DNow! 拡張機能、および MMX 拡張機能) を 32 ビット Pentium Pro アーキテクチャーに追加します。
`sse`	`SSE` 命令セットを `Pentium Pro` アーキテクチャーに追加します。
`ssea`	AMD 拡張機能 (3DNow!、3DNow! 拡張機能、および MMX 拡張機能) を 32 ビット SSE アーキテクチャーに追加します。
`sse2`	`SSE2` 命令セットを Pentium Pro アーキテクチャーに追加します。
`sse2a`	AMD 拡張機能 (3DNow!、3DNow! 拡張機能、および MMX 拡張機能) を 32 ビット SSE2 アーキテクチャーに追加します。
`sse3`	SSE3 命令セットを SSE2 命令セットに追加します。
`sse3a`	AMD 拡張命令 (3dnow など) を SSE3 命令セットに追加します。
`ssse3`	SSSE3 命令セットで、Pentium Pro、SSE、SSE2、および SSE3 の各命令セットを補足します。
`sse4_1`	SSE4.1 命令セットで、Pentium Pro、SSE、SSE2、SSE3、および SSSE3 の各命令セットを補足します。
`sse4_2`	SSE4.2 命令セットで、Pentium Pro、SSE、SSE2、SSE3、SSSE3、および SSE4.1 の各命令セットを補足します。
`amdsse4a`	AMD SSE4a 命令セットを使用します。
`aes`	Intel Advanced Encryption Standard 命令セットを使用します。
`avx`	Intel Advanced Vector Extensions 命令セットを使用します。

x86 プラットフォームで、プログラムの一部が —m64 を使用してコンパイルまたはリンクされる場合は、プログラムのすべての部分もこれらのオプションのいずれかを使用してコンパイルされる必要があります。各種 Intel 命令セットアーキテクチャー (SSE、SSE2、SSE3、SSSE3 など) の詳細は、Intel-64 および IA-32 の『Intel Architecture Software Developer's Manual』を参照してください。

「1.2 x86 の特記事項」および「1.4 バイナリの互換性の妥当性検査」も参照してください。

A.2.105.4 相互の関連性

このオプションは単体でも使用できますが、-xtarget オプションの展開の一部でもあります。したがって、特定の -xtarget オプションで設定される -xarch のオーバーライドにも使用できます。-xtarget=ultra2 は -xarch=v8plusa -xchip=ultra2 -xcache=16/32/1:512/64/1 に展開されます。次のコマンドでは、-xarch=v8plusb は、-xtarget=ultra2 の展開で設定された -xarch=v8plusa より優先されます。

example% CC -xtarget=ultra2 -xarch=v8plusb foo.cc

-xarch=generic64、-xarch=native64、-xarch=v9、-xarch=v9a、または -xarch=v9b による -compat[=4] の使用はサポートされていません。

A.2.105.5 警告

このオプションを最適化と併せて使用する場合、適切なアーキテクチャーを選択すると、そのアーキテクチャー上での実行パフォーマンスを向上させることができます。ただし、適切な選択をしなかった場合、パフォーマンスが著しく低下するか、あるいは、作成されたバイナリプログラムが目的のターゲットプラットフォーム上で実行できない可能性があります。

別々の手順でコンパイルしてリンクする場合は、両方の手順に同じ -xarch の値を指定してください。

A.2.106 `-xautopar`

複数プロセッサのための自動並列化を有効にします。依存性の解析 (ループの繰り返し内部でのデータ依存性の解析) およびループ再構成を実行します。最適化が -xO3 以上でない場合、最適化は -xO3 に引き上げられ、警告が出されます。

独自のスレッド管理を行なっている場合には、-xautopar を使用しないでください。

より高速な実行を実現するには、このオプションにマルチプロセッサシステムが必要です。シングルプロセッサシステムでは、通常、生成されたバイナリの実行速度は低下します。

並列化されたプログラムをマルチスレッド環境で実行するには、実行前に環境変数 OMP_NUM_THREADS を 1 より大きな値に設定する必要があります。設定しない場合は、デフォルトは 2 です。より多くのスレッドを使用するには、OMP_NUM_THREADS をより高い値に設定します。1 つのスレッドだけで実行する場合は、OMP_NUM_THREADS を 1 に設定します。一般に、OMP_NUM_THREADS には、実行中のシステムで使用可能な仮想プロセッサ数を設定します。Oracle Solaris の psrinfo(1) コマンドを使用して判断できます。

-xautopar を使用してコンパイルとリンクを 1 度に実行する場合、リンクには自動的にマイクロタスキングライブラリおよびスレッドに対して安全な C 実行時ライブラリが含まれます。-xautopar を使用して別々にコンパイルし、リンクする場合、-xautopar でリンクする必要があります。

A.2.106.1 関連項目

「A.2.152 -xopenmp[= i]」

A.2.107 `-xbinopt=`{`prepare`| `off`}

(SPARC) このオプションは廃止されており、コンパイラの将来のリリースで削除される予定です。「A.2.103 -xannotate[=yes| no]」を参照してください。

コンパイラに、あとで最適化、変換、および解析を行うためにバイナリを準備するよう指示します。binopt(1) のマニュアルページを参照してください。このオプションは、実行可能ファイルまたは共有オブジェクトの構築に使用できます。コンパイルとリンクを別々に行う場合は、両方の手順に -xbinopt を指定する必要があります。

example% cc -c -xO1 -xbinopt=prepare a.c b.c
example% cc -o myprog -xbinopt=prepare a.o

一部のソースコードがコンパイルに使用できない場合も、このオプションを使用してそのほかのコードがコンパイルされます。このとき、最終的なバイナリを作成するリンク手順で、このオプションを使用する必要があります。この場合、このオプションでコンパイルされたコードだけが最適化、変換、分析できます。

A.2.107.1 デフォルト

デフォルトは -xbinopt=off です。

相互の関連性

このオプションを有効にするには、最適化レベル -xO1 以上で使用する必要があります。このオプションを使用すると、構築したバイナリのサイズが少し増えます。

-xbinopt=prepare と -g を指定してコンパイルすると、デバッグ情報が取り込まれるので、実行可能ファイルのサイズが増えます。

A.2.108 `-xbuiltin`[`=`{ `%all`|`%default`|`%none`}]

標準ライブラリ呼び出しの最適化を有効または無効にします。

-xbuiltin オプションは、標準ライブラリ関数を呼び出すコードをさらに最適化するために使用します。このオプションを使用すると、コンパイラは、パフォーマンスに有益な場所で組み込み関数またはインラインシステム関数を置き換えることができます。コンパイラのコメント出力を読み取って、どの関数がコンパイラによって置き換えられたかを判定する方法については、er_src(1) のマニュアルページを参照してください。

-xbuiltin=%all を使用した場合、置き換えによって errno の設定が信頼できなくなることがあります。プログラムが errno の値に依存している場合、このオプションは避けてください。

-xbuiltin=%default では、errno を設定しない関数だけがインライン化されます。errno の値はどの最適化レベルでも常に正確であり、高い信頼度でチェックできます。-xbuiltin=%default を -xO3 以下で使用した場合、コンパイラはどの呼び出しがインライン化に有益かを判定し、それ以外はインライン化しません。

-xbuiltin=%none オプションはデフォルトのコンパイラの動作に影響を与え、コンパイラは組み込み関数に対して特別な最適化は行いません。

A.2.108.1 デフォルト

-xbuiltin を指定しない場合、デフォルトは、-xO1 以上の最適化レベルでのコンパイル時は -xbuiltin=%default、-xO0 では -xbuiltin=%none です。-xbuiltin を引数なしで指定した場合、デフォルトは -xbuiltin=%all であり、コンパイラは組み込み関数の置き換えや標準ライブラリ関数のインライン化をはるかに積極的に行います。

-xbuiltin オプションでは、システムのヘッダーファイルで定義されている大域関数だけがインライン化され、ユーザーが定義した静的関数はインライン化されません。大域関数に割り込もうとするユーザーコードによって、定義されていない動作になることがあります。

相互の関連性

マクロ -fast の拡張には、-xbuiltin=%all が取り込まれます。

例

次のコンパイラコマンドでは、標準ライブラリ呼び出しを特殊処理するように要求します。

example% CC -xbuiltin -c foo.cc

次のコンパイラコマンドでは、標準ライブラリ呼び出しを特殊処理しないように要求します。マクロ -fast の拡張には -xbuiltin=%all が取り込まれていることに注意してください。

example% CC -fast -xbuiltin=%none -c foo.cc

A.2.109 `-xcache=`c

オプティマイザ用のキャッシュ特性を定義します。この定義によって、特定のキャッシュが使用されるわけではありません。

注 - このオプションは単独でも使用できますが、-xtarget オプションを展開したものの一部です。主に、-xtarget オプションで指定された値を上書きするために使用されます。

オプションのプロパティー [/ti] は、キャッシュを共有できるスレッドの数を設定します。

A.2.109.1 値

c は、次の表に示されている値のいずれかである必要があります。

表 A-24 -xcache の値

値	意味
`generic`	コンパイラに、どのプロセッサ上でも大きなパフォーマンス低下を招かず、ほとんどの x86 および SPARC プロセッサ上で良好なパフォーマンスが得られるキャッシュ属性を使用するよう指示します。(デフォルト) これらの最高のタイミング特性は、新しいリリースごとに、必要に応じて調整されます。
`native`	ホスト環境に対して最適化されたパラメータを設定します。
`s1/l1` `/a1`[`/t1`]	レベル 1 のキャッシュ属性を定義します。
`s1/l1` `/a1`[`/t1`] `:s2/l2` `/a2`[`/t2`]	レベル 1 とレベル 2 のキャッシュ属性を定義します。
`s1/l1` `/a1`[`/t1`] `:s2/l2` `/a2`[`/t2`] `:s3/l3` `/a3`[`/t3`]	レベル 1、レベル 2、レベル 3 のキャッシュ属性を定義します。

キャッシュ属性 si /li/ai /ti の定義を次の表に示します。

属性	定義
`si`	レベル i のデータキャッシュのサイズ (K バイト単位)
`li`	レベル i のデータキャッシュのラインサイズ (バイト単位)
`ai`	レベル i のデータキャッシュの結合規則
`ti`	レベル `i` でキャッシュを共有するハードウェアスレッドの数

たとえば、i=1 は、レベル 1 のキャッシュ属性の s1/l1/a1 を意味します。

デフォルト

-xcache が指定されていない場合は、デフォルトの -xcache=generic が使用されます。この値は、コンパイラに、どのプロセッサ上でも大きなパフォーマンス低下を招かず、ほとんどの SPARC プロセッサ上で良好なパフォーマンスが得られるキャッシュ属性を使用するよう指示します。

t の値を指定しない場合のデフォルトは 1 です。

例

-xcache=16/32/4:1024/32/1 は、次の値を指定します。

レベル 1 のキャッシュ: 16K バイト、32 バイトの行サイズ、4 ウェイアソシアティブ
レベル 2 のキャッシュ: 1024K バイト、32 バイトの行サイズ、ダイレクトマップ結合

A.2.110 `-xchar`[`=` `o`]

このオプションは、 char 型が符号なしで定義されているシステムからのコード移植を簡単にするためのものです。そのようなシステムからの移植以外では、このオプションは使用しないでください。符号付きまたは符号なしであると明示的に示すように書き直す必要があるのは、符号に依存するコードだけです。

A.2.110.1 値

次の表の値のいずれかを o に置き換えることができます。

表 A-25 -xchar の値

値	意味
`signed`	char 型で定義された文字定数および変数を符号付きとして処理します。このオプションは、コンパイル済みコードの動作に影響しますが、ライブラリルーチンの動作には影響しません。
`s`	`signed` と同義です。
`unsigned`	char 型で定義された文字定数および変数を符号なしとして処理します。このオプションは、コンパイル済みコードの動作に影響しますが、ライブラリルーチンの動作には影響しません。
`u`	`unsigned` と同等です

デフォルト

-xchar を指定しない場合は、コンパイラでは -xchar=s が指定されます。

-xchar を値なしで指定した場合は、コンパイラでは -xchar=s が指定されます。

相互の関連性

-xchar オプションは、-xchar でコンパイルしたコードでだけ、char 型の値の範囲を変更します。このオプションは、システムルーチンまたはヘッダーファイル内の char 型の値の範囲は変更されません。特に、limits.h で定義された CHAR_MAX と CHAR_MIN の値は、このオプションが指定されても変更されません。したがって、CHAR_MAX および CHAR_MIN は、通常の char で符号化可能な値の範囲は表示されなくなります。

警告

-xchar=unsigned を使用するときは、マクロでの値が符号付きの場合があるため、char を定義済みのシステムマクロと比較する際には特に注意してください。この状況は、マクロを通してアクセスされる、エラーコードを返すすべてのルーチンでもっとも一般的です。エラーコードは、一般的には負の値になっています。したがって、char をそのようなマクロによる値と比較するときは、結果は常に false になります。負の数値が符号なしの型の値と等しくなることはありません。

ライブラリを通してエクスポートされるインタフェースのルーチンをコンパイルするために、-xchar を使用しないでください。Oracle Solaris ABI は char 型を符号付きとして指定し、それに応じてシステムライブラリが動作します。char を符号なしにする影響は、システムライブラリで十分にテストされていません。このオプションを使用する代わりに、char 型の符号の有無に依存しないようにコードを変更してください。char 型の符号は、コンパイラやオペレーティングシステムの間でさまざまに変化します。

A.2.111 `-xcheck`[`=` `i`]

-xcheck=stkovf を使用してコンパイルすると、シングルスレッドプログラム内のメインスレッドや、マルチスレッドプログラム内のスレーブスレッドスタックのスタックオーバーフローのための実行時チェックが追加されます。スタックオーバーフローが検出された場合は、SIGSEGV が生成されます。スタックオーバーフローによって発生した SIGSEGV をほかのアドレス空間違反と異なる方法で処理する方法については、sigaltstack(2) のマニュアルページを参照してください。

A.2.111.1 値

i は、次の表に示されている値のいずれかである必要があります。

表 A-26 -xcheck の値

値	意味
`%all`	チェックをすべて実行します。
`%none`	チェックを実行しません。
`stkovf`	スタックオーバーフローのチェックをオンにします。
`no%stkovf`	スタックオーバーフローのチェックをオフにします。
`init_local`	ローカル変数を初期化します。詳細は、『C ユーザーズガイド』を参照してください。
`no%init_local`	局所変数を初期化しません (デフォルト)。

デフォルト

-xcheck を指定しない場合は、コンパイラではデフォルトで -xcheck=%none が指定されます。

引数を指定せずに -xcheck を使用した場合は、コンパイラではデフォルトで -xcheck=%none が指定されます。

-xcheck オプションは、コマンド行で累積されません。コンパイラは、コマンドで最後に指定したものに従ってフラグを設定します。

A.2.112 `-xchip=`c

オプティマイザが使用するターゲットとなるプロセッサを指定します。

–xchip オプションは、ターゲットとなるプロセッサを指定してタイミング属性を指定します。このオプションは、次の属性に影響を与えます。

命令の順序 (スケジューリング)
コンパイラが分岐を使用する方法
意味が同じもので代用できる場合に使用する命令

注 - このオプションは単独でも使用できますが、-xtarget オプションを展開したものの一部です。主に、-xtarget オプションで指定された値を上書きするために使用されます。

A.2.112.1 値

c は、次の 2 つの表に示されている値のいずれかである必要があります。

表 A-27 SPARC プロセッサでの -xchip の値

`generic`	ほとんどの SPARC プロセッサ上での良好なパフォーマンス
`native`	コンパイラが実行されているホスト SPARC システム上での良好なパフォーマンス
`sparc64vi`	SPARC64 VI プロセッサ
`sparc64vii`	SPARC64 VII プロセッサ
`sparc64viiplus`	SPARC64 VII+ プロセッサ
`ultra`	UltraSPARC プロセッサ
`ultra2`	UltraSPARC II プロセッサ
`ultra2e`	UltraSPARC IIe プロセッサ
`ultra2i`	UltraSPARC IIi プロセッサ
`ultra3`	UltraSPARC III プロセッサ
`ultra3cu`	UltraSPARC III Cu プロセッサ
`ultra3`i	UltraSparc IIIi プロセッサ
`ultra4`	UltraSPARC IV プロセッサ
`ultra4plus`	UltraSPARC IVplus プロセッサ
`ultraT1`	UltraSPARC T1 プロセッサ.
`ultraT2`	UltraSPARC T2 プロセッサ
`ultraT2plus`	UltraSPARC T2+ プロセッサ
`T3`	SPARC T3 プロセッサ
`T4`	SPARC T4 プロセッサ

表 A-28 x86/x64 プロセッサでの -xchip の値

`generic`	ほとんどの x86 プロセッサ上での良好なパフォーマンス
native	コンパイラが実行されているホスト x86 システム上での良好なパフォーマンス
`core2`	Intel Core2 プロセッサ
`nehalem`	Intel Nehalem プロセッサ
`opteron`	AMD Opteron プロセッサ
`penryn`	Intel Penryn プロセッサ
`pentium`	Intel Pentium プロセッサ
`pentium_pro`	Intel Pentium Pro プロセッサ
`pentium3`	Intel Pentium 3 形式プロセッサ
`pentium4`	Intel Pentium 4 形式プロセッサ
`amdfam10`	AMD AMDFAM10 プロセッサ
`sandybridge`	Intel Sandy Bridge プロセッサ
`westmere`	Intel Westmere プロセッサ

デフォルト

ほとんどのプロセッサ上で、generic は、どのプロセッサでもパフォーマンスの著しい低下がなく、良好なパフォーマンスが得られる最良のタイミング属性を使用するようコンパイラに命令するデフォルト値です。

A.2.113 `-xcode=`a

(SPARC のみ ) コードのアドレス空間を指定します。

注 - 共有オブジェクトの構築では、-xcode=pic13 または -xcode=pic32 を指定することをお勧めします。pic13 または pic32 なしに構築された共有オブジェクトは、正しく機能せず、構築できない可能性があります。

A.2.113.1 値

a は、次の表に示されている値のいずれかである必要があります。

表 A-29 -xcode の値

値	意味
`abs32`	32 ビット絶対アドレスを生成します。高速ですが、範囲が制限されます。コード、データ、および bss を合計したサイズは 2**32 バイトに制限されます。
`abs44`	SPARC: 44 ビット絶対アドレスを生成します。中程度の速さで中程度の範囲を使用できます。コード、データ、および bss を合計したサイズは 2**44 バイトに制限されます。64 ビットのアーキテクチャーでのみ利用できます。動的 (共有) ライブラリで使用しないでください。
`abs64`	SPARC: 64 ビット絶対アドレスを生成します。低速ですが、範囲は制限されません。64 ビットのアーキテクチャーでのみ利用できます。
`pic13`	位置独立コード (小規模モデル) を生成します。高速ですが、範囲が制限されます。`-Kpic` と同等です。32 ビットアーキテクチャーでは最大 211 個の固有の外部シンボルを、64 ビットでは 210 個の固有の外部シンボルをそれぞれ参照できます。
`pic32`	位置独立コード (ラージモデル) を生成します。`pic13` ほど高速でない可能性がありますが、フルレンジ対応です。`-KPIC` と同等です。32 ビットアーキテクチャーでは最大 230 個の固有の外部シンボルを、64 ビットでは 229 個の固有の外部シンボルをそれぞれ参照できます。

-xcode=pic13 と -xcode=pic32 のどちらを使用するかを判定するには、elfdump -c を使用して大域オフセットテーブル (GOT) のサイズを確認し、セクションヘッダー sh_name: .got を検索します。sh_size 値が GOT のサイズです。GOT のサイズが 8,192 バイトに満たない場合は -xcode=pic13、そうでない場合は -xcode=pic32 を指定します。詳細は、elfdump(1) のマニュアルページを参照してください。

一般に、-xcode の使用方法の決定に際しては、次のガイドラインに従ってください。

実行可能ファイルを構築する場合は、-xcode=pic13 と -xcode=pic32 のどちらも使わない。
実行可能ファイルへのリンク専用のアーカイブライブラリを構築する場合は、-xcode=pic13 と -xcode=pic32 のどちらも使わない。
共有ライブラリを構築している場合は、-xcode=pic13 から始めてください。GOT のサイズが 8,192 バイトを超えたら、-xcode=pic32 を使用します。
共有ライブラリへのリンクのためのアーカイブライブラリを構築している場合は、-xcode=pic32 のみを使用してください。

デフォルト

32 ビットアーキテクチャーの場合は -xcode=abs32 です。64 ビットアーキテクチャーの場合のデフォルトは -xcode=abs44 です。

共有動的ライブラリを作成する場合、64 ビットアーキテクチャーでは -xcode のデフォルト値である abs44 と abs32 を使用できません。-xcode=pic13 または -xcode=pic32 を指定してください。SPARC の場合、-xcode=pic13 および -xcode=pic32 では、わずかですが、次の 2 つのパフォーマンス上の負担がかかります。

-xcode=pic13 および -xcode=pic32 のいずれかでコンパイルしたルーチンは、共有ライブラリの大域または静的変数へのアクセスに使用されるテーブル (_GLOBAL_OFFSET_TABLE_) を指し示すようレジスタを設定するために、入口で命令を数個余計に実行します。
大域または静的変数へのアクセスのたびに、_GLOBAL_OFFSET_TABLE_ を使用した間接メモリー参照が 1 回余計に行われます。-xcode=pic32 でコンパイルした場合は、大域および静的変数への参照ごとに命令が 2 個増えます。

こうした負担があるとしても、-xcode=pic13 および -xcode=pic32 を使用すると、ライブラリコードを共有できるため、必要となるシステムメモリーを大幅に減らすことができます。-xcode=pic13 あるいは -xcode=pic32 でコンパイルした共有ライブラリを使用するすべてのプロセスは、そのライブラリのすべてのコードを共有できます。共有ライブラリ内のコードに非 pic (すなわち、絶対) メモリー参照が 1 つでも含まれている場合、そのコードは共有不可になるため、そのライブラリを使用するプログラムを実行する場合は、その都度、コードのコピーを作成する必要があります。

.o ファイルが -xcode=pic13 と -xcode=pic32 のどちらを使用してコンパイルされたかを知るためのもっとも簡単な方法は、nm コマンドの使用です。

% nm file.o | grep _GLOBAL_OFFSET_TABLE_ U _GLOBAL_OFFSET_TABLE_

位置独立コードを含む .o ファイルには、_GLOBAL_OFFSET_TABLE_ への未解決の外部参照が含まれます。このことは、英文字の U で示されます。

-xcode=pic13 または -xcode=pic32 を使用すべきかどうかを判断するには、nm を使用して、共有ライブラリで使用または定義されている明確な大域および静的変数の個数を確認します。_GLOBAL_OFFSET_TABLE_ のサイズが 8,192 バイトより小さい場合は、-Kpic を使用できます。そうでない場合は、-xcode=pic32 を使用する必要があります。

A.2.114 `-xdebugformat=`[`stabs|dwarf`]

コンパイラは、デバッガ情報の形式をスタブ (「シンボルテーブル」) 形式から「DWARF Debugging Information Format」仕様の dwarf 形式に移行しました。デフォルト設定は -xdebugformat=dwarf です。

デバッグ情報を読み取るソフトウェアを保守している場合は、今回からそのようなツールを stab 形式から dwarf 形式へ移行するためのオプションが加わりました。

このオプションは、ツールを移植する場合に新しい形式を使用する方法として使用してください。デバッガ情報を読み取るソフトウェアを保守しているか、または特定のツールがこれらのいずれかの形式のデバッガ情報を必要としていないかぎり、このオプションを使用する必要はありません。

表 A-30 -xdebugformat のフラグ

値	意味
`stabs`	`-xdebugformat=stabs` は、stab 標準形式を使用してデバッグ情報を生成します。
dwarf	`-xdebugformat=dwarf` は、dwarf 標準形式を使用してデバッグ情報を生成します。

-xdebugformat を指定しない場合は、コンパイラでは -xdebugformat=dwarf が指定されます。このオプションには引数が必要です。

このオプションは、-g オプションによって記録されるデータの形式に影響します。-g を指定しなくても、一部のデバッグ情報が記録されますが、その情報の形式もこのオプションによって制御されます。したがって、-g が使用されていないときでも、-xdebugformat は有効です。

dbx とパフォーマンスアナライザソフトウェアは、stab 形式と dwarf 形式を両方とも認識するので、このオプションを使用しても、ツールの機能にはまったく影響を与えません。

注 - スタブ形式では、dbx で現在使用されているすべてのデバッグデータを表せません。また、一部のコードは、スタブを使用してデバッグデータを正常に生成できない可能性があります。

詳細は、dumpstabs(1) および dwarfdump(1) のマニュアルページも参照してください。

A.2.115 `-xdepend`=[`yes`| `no`]

ループの繰り返し内部でのデータ依存性を解析し、ループ交換、ループ融合、スカラー交換、「デッドアレイ」代入の回避などのループの再構成を実行します。

SPARC プロセッサ上では、-xdepend はデフォルトで、-xO3 以上のすべての最適化レベルを示す -xdepend=on になります。それ以外の場合は、–xdepend のデフォルトは –xdepend=off です。-xdepend の明示的な設定を指定すると、すべてのデフォルト設定は上書きされます。

x86 プロセッサ上では、-xdepend はデフォルトで -xdepend=off になります。-xdepend を指定し、最適化が -xO3 以上でない場合は、コンパイラは最適化を -xO3 に上げ、警告を発行します。

引数なしで -xdepend を指定すると、-xdepend=yes と同等であることを意味します。

依存性の解析は -xautopar に含まれています。依存性の解析はコンパイル時に実行されます。

依存性の解析はシングルプロセッサシステムで役立つことがあります。ただし、シングルプロセッサシステム上で -xdepend を使用する場合は、-xautopar も同時に指定してはいけません。マルチプロセッサシステムに対して -xdepend の最適化が実行されてしまうためです。

A.2.115.1 関連項目

-xprefetch_auto_type

A.2.116 `-xdumpmacros`[`=` `value`[`,value...`]]

マクロがプログラム内でどのように動作しているかを調べたいときに、このオプションを使用します。このオプションは、定義済みマクロ、解除済みマクロ、実際の使用状況といった情報を提供します。マクロの処理順序に基づいて、標準エラー (stderr) への出力が出力されます。-xdumpmacros オプションは、ファイルの終わりまで、または dumpmacros プラグマまたは end_dumpmacros プラグマによって上書きされるまで有効です。「B.2.5 #pragma dumpmacros」を参照してください。

A.2.116.1 値

次の表に、value の有効な引数の一覧を示します。接頭辞 no% は関連付けられた値を無効にします。

表 A-31 -xdumpmacros の値

値	意味
[`no%`]`defs`	すべての定義済みマクロを出力します。
[`no%`]`undefs`	すべての解除済みマクロを出力します。
[`no%`]`use`	使用されているマクロの情報を出力します
[`no%`]`loc`	`defs`、`undefs`、`use` の位置 (パス名と行番号) も出力します。
[`no%`]`conds`	条件付き指令で使用されたマクロの使用情報を出力します。
[`no%`]`sys`	システムヘッダーファイル内のマクロについて、すべての定義済みマクロ、解除済みマクロ、使用状況を出力します。
`%all`	オプションを`-xdumpmacros=defs,undefs,use,loc,conds,sys` に設定します。この引数は、`[no%]` 形式の引数と併用すると効果的です。たとえば `-xdumpmacros=%all,no%sys` は、出力からシステムヘッダーマクロを除外しますが、そのほかのマクロに関する情報は依然として出力します。
`%none`	あらゆるマクロ情報を出力しません。

オプションの値は累積されるので、-xdumpmacros=sys -xdumpmacros=undefs を指定することは、-xdumpmacros=undefs,sys と同じ効果があります。

注 - サブオプション loc、conds、sys は、オプション defs、undefs、use の修飾子です。loc、conds、sys は、単独では効果はありません。たとえば -xdumpmacros=loc,conds,sys は、まったく効果を持ちません。

デフォルト

引数なしで -xdumpmacros を指定するときのデフォルトは、-xdumpmacros=defs,undefs,sys です。-xdumpmacros を指定しないときのデフォルトは、-xdumpmacros=%none です。

例

-xdumpmacros=use,no%loc オプションを使用すると、使用した各マクロの名前が一度だけ出力されます。より詳しい情報が必要であれば、-xdumpmacros=use,loc オプションを使用します。マクロを使用するたびに、そのマクロの名前と位置が印刷されます。

次のファイル t.c を考慮します。

example% cat t.c
#ifdef FOO
#undef FOO
#define COMPUTE(a, b) a+b
#else
#define COMPUTE(a,b) a-b
#endif
int n = COMPUTE(5,2);
int j = COMPUTE(7,1);
#if COMPUTE(8,3) + NN + MM
int k = 0;
#endif

次の例は、defs、undefs、sys、および loc の引数に基づいた、ファイル t.c の出力を示しています。

example% CC -c -xdumpmacros -DFOO t.c
#define __SunOS_5_9 1
#define __SUNPRO_CC 0x590
#define unix 1
#define sun 1
#define sparc 1
#define __sparc 1
#define __unix 1
#define __sun 1
#define __BUILTIN_VA_ARG_INCR 1
#define __SVR4 1
#define __SUNPRO_CC_COMPAT 5
#define __SUN_PREFETCH 1
#define FOO 1
#undef FOO
#define COMPUTE(a, b) a + b

example% CC -c -xdumpmacros=defs,undefs,loc -DFOO -UBAR t.c
command line: #define __SunOS_5_9 1
command line: #define __SUNPRO_CC 0x590
command line: #define unix 1
command line: #define sun 1
command line: #define sparc 1
command line: #define __sparc 1
command line: #define __unix 1
command line: #define __sun 1
command line: #define __BUILTIN_VA_ARG_INCR 1
command line: #define __SVR4 1
command line: #define __SUNPRO_CC_COMPAT 5
command line: #define __SUN_PREFETCH 1
command line: #define FOO 1
command line: #undef BAR
t.c, line 2: #undef FOO
t.c, line 3: #define COMPUTE(a, b) a + b

次の例では、use、loc、および conds の引数によって、マクロ動作がファイル t.c に出力されます。

example% CC -c -xdumpmacros=use t.c
used macro COMPUTE

example% CC -c -xdumpmacros=use,loc t.c
t.c, line 7: used macro COMPUTE
t.c, line 8: used macro COMPUTE

example% CC -c -xdumpmacros=use,conds t.c
used macro FOO
used macro COMPUTE
used macro NN
used macro MM

example% CC -c -xdumpmacros=use,conds,loc t.c
t.c, line 1: used macro FOO
t.c, line 7: used macro COMPUTE
t.c, line 8: used macro COMPUTE
t.c, line 9: used macro COMPUTE
t.c, line 9: used macro NN
t.c, line 9: used macro MM

次は、ファイル y.c の例です。

example% cat y.c
#define X 1
#define Y X
#define Z Y
int a = Z;

次の例は、y.c 内のマクロに基づく、-xdumpmacros=use,loc からの出力を示しています。

example% CC -c -xdumpmacros=use,loc y.c
y.c, line 4: used macro Z
y.c, line 4: used macro Y
y.c, line 4: used macro X

A.2.117 `-xe`

構文エラーと意味エラーの有無チェックのみ行います。-xe を指定すると、オブジェクトコードは出力されません。-xe の出力は、stderr に送られます。

コンパイルによってオブジェクトファイルを生成する必要がない場合には、-xe オプションを使用してください。たとえば、コードの一部を削除することによってエラーメッセージの原因を切り分ける場合には、-xe を使用することによって編集とコンパイルを高速化できます。

A.2.117.1 関連項目

-c

A.2.118 `-xF`[`=v`[, `v`...]]

リンカーによる関数と変数の最適な順序の並べ替えを有効にします。

このオプションは、コンパイラに、関数やデータ変数を細分化された別々のセクションに配置するよう指示します。これにより、リンカーは、リンカーの -M オプションで指定されたマップファイル内の指示を使用してこれらのセクションを並べ替えることにより、プログラムのパフォーマンスを最適化できるようになります。通常は、この最適化によって効果が上がるのは、プログラムの実行時間の多くがページフォルト時間に費やされている場合だけです。

変数を並べ替えると、実行時のパフォーマンスに悪影響を与える次の問題の解決に役立ちます。

メモリー内で互いに近い位置にある関連性のない変数によって発生するキャッシュやページの競合
メモリー内で互いに近い位置にない関連性のある変数によって発生する、必要以上に大きな作業セットサイズ
有効なデータ密度を低下させる weak 変数の未使用のコピーによって発生する、必要以上に大きな作業セットサイズ

最適なパフォーマンスを得るために変数と関数の順序を並べ替えるには、次の処理が必要です。

-xF によるコンパイルとリンク
『パフォーマンスアナライザ』のマニュアルにある関数のマップファイルを生成する方法に関する指示に従うか、または『リンカーとライブラリ』にあるデータのマップファイルを生成する方法に関する指示に従います。
リンカーの -M オプションを使用して新しいマップファイルを再リンクします。
アナライザで再実行して、パフォーマンスが向上したかどうかを検証します。

A.2.118.1 値

v には、次の表に示されている値の 1 つ以上を指定できます。no% 接頭辞によって、関連付けられた値が無効になります。

表 A-32 -xF の値

値	意味
[`no%`]`func`	関数を個別のセクションにフラグメント化します。
`[no%`]`gbldata`	大域データ (外部リンケージを持つ変数) を個別のセクションにフラグメント化します。
[`no%`]`lcldata`	ローカルデータ (内部リンケージを持つ変数) を個別のセクションにフラグメント化します。
`%all`	関数、大域データ、局所データを細分化します。
`%none`	何も細分化しません。

デフォルト

-xF を指定しない場合のデフォルトは、-xF=%none です。引数を指定しないで -xF を指定した場合のデフォルトは、-xF=%none,func です。

相互の関連性

-xF=lcldata を指定するとアドレス計算最適化が一部禁止されるので、このフラグは実験として意味があるときにだけ使用するとよいでしょう。

A.2.119 `-xhelp=flags`

各コンパイラオプションの簡単な説明を表示します。

A.2.120 `-xhwcprof`

(SPARC のみ) ハードウェアカウンタによるプロファイリングのコンパイラでのサポートを有効にします。

-xhwcprof を有効にすると、コンパイラは、プロファイル対象のロード命令およびストア命令と、それらが参照するデータ型および構造体メンバーをツールが関連付けるのに役立つ情報を、-g で生成されたシンボル情報と組み合わせて生成します。プロファイルデータをターゲットの命令領域ではなく、データ領域に関連付けます。このオプションは、命令プロファイリングだけでは簡単には得られない動作に対する見通しを提供します。

指定した一連のオブジェクトファイルは、-xhwcprof を指定してコンパイルできます。ただし、-xhwcprof がもっとも有効なのは、アプリケーション内のすべてのオブジェクトファイルに適用された場合です。この場合は、アプリケーションのオブジェクトファイルに分散しているすべてのメモリー参照の識別や関連付けが完全に対処されます。

コンパイルとリンクを別々に行う場合は、-xhwcprof をリンク時にも使用してください。将来 -xhwcprof に拡張する場合は、リンク時に -xhwcprof を使用する必要があります。

-xhwcprof=enable または -xhwcprof=disable のインスタンスは、同じコマンド行にある以前の -xhwcprof のインスタンスをすべて無効にします。

-xhwcprof はデフォルトでは無効です。引数を指定せずに -xhwcprof と指定することは、-xhwcprof=enable と指定することと同じです。

-xhwcprof を指定するには、最適化を有効にして、DWARF のデバッグデータ形式を選択する必要があります。現在は、DWARF 形式 ( -xdebugformat=dwarf) がデフォルトです。

-xhwcprof と -g を組み合わせると、コンパイラの一時ファイル記憶領域の必要量は、-xhwcprof と -g のいずれかを指定したときに増える量の合計よりも増えます。

次のコマンドは example.cc をコンパイルし、ハードウェアカウンタによるプロファイリングのサポートを指定し、DWARF シンボルを使用してデータ型と構造体メンバーのシンボリック解析を指定します。

example% CC -c -O -xhwcprof -g -xdebugformat=dwarf example.cc

ハードウェアカウンタによるプロファイリングについての詳細は、『パフォーマンスアナライザ』のマニュアルを参照してください。

A.2.121 `-xia`

区間演算ライブラリをリンクし、適切な浮動小数点環境を設定します。

注 - C++ 区間演算ライブラリは、Fortran コンパイラで実装されているとおり、区間演算と互換性があります。

x86 プラットフォーム上では、このオプションを指定するには SSE2 命令セットのサポートが必要です。

A.2.121.1 展開

-xia オプションは、-fsimple=0 -ftrap=%none -fns=no -library=interval に拡張するマクロです。区間演算を使用するようにしていて、-fsimple か -ftrap、-fns、-library のどれかを指定して -xia による設定を無効にした場合、コンパイラが不正な動作をすることがあります。

A.2.121.2 相互の関連性

区間演算ライブラリを使用するには、<suninterval.h> を取り込みます。

区間演算ライブラリを使用する場合は、Cstd と iostreams のいずれかのライブラリを含める必要があります。これらのライブラリを含める方法については、-library を参照してください。

A.2.121.3 警告

区間を使用し、-fsimple、-ftrap、または -fns に異なる値を指定すると、プログラムの動作が不正確になる場合があります。

C++ 区間演算は実験に基づくもので発展性があります。詳細は、リリースごとに変更される可能性があります。

A.2.121.4 関連項目

-library

A.2.122 `-xinline`[`=` `func-spec`[`,func-spec`...]]

どのユーザー作成ルーチンをオプティマイザによって -xO3 レベル以上でインライン化するかを指定します。

A.2.122.1 値

func-spec は、次の表に示されている値のいずれかである必要があります。

表 A-33 -xinline の値

値	意味
`%auto`	最適化レベル `-xO4` 以上で自動インライン化を有効にします。この引数は、オプティマイザが選択した関数をインライン化できることをオプティマイザに知らせます。`%auto` の指定がない場合、`-xinline=`[`no%`] `func-name`... によってコマンド行で明示的インライン化が指定されていると、自動インライン化は通常無効になります。
`func_name`	オプティマイザに関数をインライン化するように強く要求します。関数が extern "C" で宣言されていない場合は、`func_name` の値を符号化する必要があります。実行可能ファイルに対し `nm` コマンドを使用して符号化された関数名を検索できます。extern "C" で宣言された関数の場合は、名前はコンパイラで符号化されません。
`no%func_name`	リスト上のルーチン名の前に `no%` を付けると、そのルーチンのインライン化が禁止されます。`func-name` の符号化された名前に関する規則は、`no%func-name` にも適用されます。

-xipo [=1|2] を使用しないかぎり、コンパイルされているファイルのルーチンだけがインライン化の対象とみなされます。オプティマイザでは、どのルーチンがインライン化に適しているかを判断します。

A.2.122.2 デフォルト

-xinline オプションを指定しないと、コンパイラでは -xinline=%auto が使用されます。

-xinline= が引数なしで指定されている場合は、最適化レベルには関係なく、どの関数もインライン化されません。

A.2.122.3 例

自動インライン化を有効にしながら、int foo() が宣言されている関数のインライン化を無効にするには、次のコマンドを使用します。

example% CC -xO5 -xinline=%auto,no%__1cDfoo6F_i_ -c a.cc

int foo() として宣言された関数のインライン化を強く要求し、その他のすべての関数をインライン化の候補にするには、次のコマンドを使用します。

example% CC -xO5 -xinline=%auto,__1cDfoo6F_i_ -c a.cc

int foo() として宣言された関数のインライン化を強く要求し、ほかのどの関数のインライン化も許可しないようにするには、次のコマンドを使用します。

example% CC -xO5 -xinline=__1cDfoo6F_i_ -c a.cc

A.2.122.4 相互の関連性

-xinline オプションは -xO3 未満の最適化レベルには影響を与えません。-xO4 以上では、-xinline オプションを指定しなくてもオプティマイザでどの関数をインライン化する必要があるかを判断します。-xO4 では、コンパイラはどの関数が、インライン化されたときにパフォーマンスを改善するかを判断しようとします。

ルーチンは、次のいずれかの条件が当てはまる場合はインライン化されます。

最適化は -xO3 以上
インライン化に効果があって安全
コンパイル中のファイルの中に関数がある、または-xipo[=1|2] を使用してコンパイルしたファイルの中に関数がある

A.2.122.5 警告

-xinline を指定して関数のインライン化を強制すると、実際にパフォーマンスを低下させる可能性があります。

A.2.122.6 関連項目

「A.2.130 -xldscope={v}」

A.2.123 `-xinstrument=`[ `no%`]`datarace`

スレッドアナライザで分析するためにプログラムをコンパイルして計測するには、このオプションを指定します。スレッドアナライザの詳細は、tha(1) のマニュアルページを参照してください。

そうすることで、パフォーマンスアナライザを使用して計測されたプログラムを collect -r races で実行し、データ競合の検出実験を行うことができます。計測されたコードをスタンドアロンで実行できますが、低速で実行されます。

-xinstrument=no%datarace を指定して、スレッドアナライザ用のソースコードの準備をオフにすることができます。これはデフォルト値です。

-xinstrument を引数なしで指定することはできません。

コンパイルとリンクを別々に行う場合は、コンパイル時とリンク時の両方で -xinstrument=datarace を指定する必要があります。

このオプションは、プリプロセッサトークン __THA_NOTIFY を定義します。#ifdef __THA_NOTIFY を指定して、libtha(3) ルーチンへの呼び出しを保護できます。

このオプションにも、-g を設定します。

A.2.124 `-xipo`[`=`{`0`|`1`|`2`}]

内部手続きの最適化を実行します。

-xipo オプションが内部手続き解析パスを呼び出すことでプログラムの一部の最適化を実行します。このオプションを指定すると、リンク手順でのすべてのオブジェクトファイル間の最適化を行い、しかもこれらの最適化は単にコンパイルコマンドのソースファイルにとどまりません。ただし、-xipo によるプログラム全体の最適化には、アセンブリ (.s) ソースファイルは含まれません。

-xipo オプションは、大量のファイルを使用してアプリケーションをコンパイルしてリンクするときに特に便利です。このフラグを指定してコンパイルされたオブジェクトファイルには、ソースプログラムファイルとコンパイル済みプログラムファイル間で内部手続き解析を有効にする解析情報が含まれています。ただし、解析と最適化は、-xipo を指定してコンパイルされたオブジェクトファイルに限定され、オブジェクトファイルまたはライブラリは対象外です。

A.2.124.1 値

-xipo オプションには、次の表に示されている値を指定できます。

表 A-34 -xipo の値

値	意味
`0`	内部手続きの最適化を実行しません
`1`	内部手続きの最適化を実行します
`2`	内部手続きの別名解析と、メモリーの割り当ておよび配置の最適化を実行し、キャッシュ性能を向上します

A.2.124.2 デフォルト

-xipo を指定しないと、-xipo=0 が使用されます。

-xipoだけを指定すると、-xipo=1 が使用されます。

A.2.124.3 例

次の例では同じ手順でコンパイルしてリンクします。

example% CC -xipo -xO4 -o prog part1.cc part2.cc part3.cc

オプティマイザは、最後のリンク手順で 3 つのすべてのソースファイルにわたるファイル間のインライン化を実行します。ソースファイルのコンパイルのすべてを 1 回のコンパイルで実行する必要はなく、それぞれに -xipo オプションが指定された、複数回の個別のコンパイルにより実行できます。

次の例では別々の手順でコンパイルしてリンクします。

example% CC -xipo -xO4 -c part1.cc part2.cc
example% CC -xipo -xO4 -c part3.cc
example% CC -xipo -xO4 -o prog part1.o part2.o part3.o

コンパイルステップで作成されるオブジェクトファイルは、それらのファイル内でコンパイルされる追加の分析情報を保持します。そのため、リンクステップにおいてファイル相互の最適化を実行できます。

A.2.124.4 `-xipo=` を使用しない内部手続き解析を行う場合

内部手続き解析では、コンパイラは、リンクステップでオブジェクトファイル群を操作しながら、プログラム全体の解析と最適化を試みます。コンパイラは、この一連のオブジェクトファイルで定義されているすべての foo() 関数またはサブルーチンについて、次の 2 つのことを前提にします。

実行時、このオブジェクトファイル群の外部で定義されている別のルーチンによって foo() が明示的に呼び出されない。
オブジェクトファイル群内のルーチンからの foo() 呼び出しが、そのオブジェクトファイル群の外部に定義されている別のバージョンの foo() によって置き換えられることがない。

特定のアプリケーションについて最初の前提が当てはまらない場合は、-xipo=2 を使用してコンパイルしないでください。

2 つ目の前提が当てはまらない場合は、-xipo=1 と -xipo=2 のどちらでもコンパイルしないでください。

1 例として、独自のバージョンの malloc() で関数 malloc() を置き換え、-xipo=2 を指定してコンパイルするケースを考えてみましょう。独自のコードとリンクされる、malloc() を参照しているライブラリ内の関数はすべて、-xipo=2 も指定してコンパイルされる必要があり、かつそれらのオブジェクトファイルがリンク手順に関与している必要があります。この方法はシステムライブラリには使用できない可能性があるため、独自のバージョンの malloc() を -xipo=2 を使用してコンパイルしないでください。

もう 1 つの例として、別々のソースファイルにある foo() および bar() という 2 つの外部呼び出しを含む共有ライブラリを構築するケースを考えてみましょう。また、bar() は foo() を呼び出すと仮定します。foo() が実行時に割り込まれる可能性がある場合は、foo() または bar() のソースファイルを -xipo=1 または -xipo=2 を使用してコンパイルしないでください。それ以外の場合、foo() が bar() にインライン化され、それによって正しくない結果になる可能性があります。

A.2.124.5 相互の関連性

-xipo オプションでは最低でも最適化レベル -x04 が必要です。

A.2.124.6 警告

コンパイルとリンクを個別に実行する場合、-xipo をコンパイルとリンクの両方で指定しなければなりません。

-xipo なしでコンパイルされたオブジェクトは、-xipo でコンパイルされたオブジェクトと自由にリンクできます。

次の例に示すように、ライブラリは、-xipo を使用してコンパイルされている場合でもファイル間の内部手続き解析に関与しません。

example% CC -xipo -xO4 one.cc two.cc three.cc
example% CC -xar -o mylib.a one.o two.o three.o
...
example% CC -xipo -xO4 -o myprog main.cc four.cc mylib.a

この例では、内部手続き最適化は one.cc、two.cc、および three.cc 間と main.cc と four.cc 間で実行されますが、main.cc または four.cc と mylib.a のルーチン間では実行されません。最初のコンパイルは未定義のシンボルに関する警告を生成する場合がありますが、相互手続きの最適化は、コンパイル手順でありしかもリンク手順であるために実行されます。

-xipo オプションは、ファイルを介して最適化を実行する際に必要な情報を追加するため、非常に大きなオブジェクトファイルを生成します。ただし、この補足情報は最終的な実行可能バイナリファイルの一部にはなりません。実行可能プログラムのサイズの増加は、そのほかに最適化を実行したことに起因します。

A.2.124.7 関連項目

-xjobs

A.2.125 `-xipo_archive=`[`a`]

新しい -xipo_archive オプションは、実行可能ファイルを生成する前に、-xipo を付けてコンパイルされ、アーカイブライブラリ (.a) の中に存在しているオブジェクトファイルを使用してリンカーに渡すオブジェクトファイルを最適化します。コンパイル中に最適化されたライブラリに含まれるオブジェクトファイルはすべて、その最適化されたバージョンに置き換えられます。

次の表に、a に指定可能な値を示します。

表 A-35 -xipo_archive のフラグ

値	意味
`writeback`	実行可能ファイルを生成する前に、アーカイブライブラリ (`.a`) に存在する `-xipo` でコンパイルしたオブジェクトファイルを使ってリンカーに渡すオブジェクトファイルを最適化します。コンパイル中に最適化されたライブラリに含まれるオブジェクトファイルは、すべてその最適化されたバージョンに置き換えられます。アーカイブライブラリの共通セットを使用する並列リンクでは、最適化されるアーカイブライブラリの独自のコピーを、各リンクでリンク前に作成する必要があります。
`readonly`	実行可能ファイルを生成する前に、アーカイブライブラリ (`.a`) に存在する `-xipo` でコンパイルしたオブジェクトファイルを使ってリンカーに渡すオブジェクトファイルを最適化します。 `-xipo_archive=readonly` オプションを指定すると、リンク時に指定されたアーカイブライブラリのオブジェクトファイルで、モジュール間のインライン化と内部手続きデータフロー解析が有効になります。ただし、モジュール間インライン化によってほかのモジュールに挿入されたコードを除く、アーカイブライブラリのコードのモジュール間最適化は有効になりません。アーカイブライブラリ内のコードにモジュール間の最適化を適用するには、`-xipo_archive=writeback` を指定する必要があります。この設定によって、コードが抽出された元のアーカイブライブラリの内容が変更されます。
`none`	これはデフォルト値です。アーカイブファイルの処理は行いません。コンパイラは、モジュール間のインライン化やその他のモジュール間の最適化を、`-xipo` を使用してコンパイルされ、リンク時にアーカイブライブラリから抽出されたオブジェクトファイルに適用しません。これを行うには、`-xipo` と、`-xipo_archive=readonly` または `-xipo_archive=writeback` のいずれかをリンク時に指定する必要があります。

-xipo_archive の値が指定されない場合、-xipo_archive=none に設定されます。

-xipo_archive をフラグなしで指定することはできません。

A.2.126 `-xivdep`[`=` `p`]

#pragma ivdep プラグマの解釈を無効化または設定します (ベクトル依存を無視)。

ivdep プラグマは、最適化の目的でループ内で検出された、配列参照へのループがもたらす依存関係の一部またはすべてを無視するようにコンパイラに指示します。これにより、指定しない場合には実行不可能なマイクロベクトル化、分散、ソフトウェアパイプライン化などの各種ループ最適化を、コンパイラが実行できるようになります。これは、依存関係が重要ではない、または依存関係が実際に発生しないことをユーザーが把握している場合に使用されます。

#pragma ivdep 指令の解釈は、—xivdep オプションの値に応じて異なります。

次のリストは、p の値とそれらの意味です。

loop: ループキャリーのベクトル依存と想定されるものを無視
loop_any: ループキャリーのベクトル依存をすべて無視
back: 逆方向のループキャリーのベクトル依存と想定されるものを無視
back_any: 逆方向のループキャリーのベクトル依存をすべて無視
none: 依存を無視しない (ivdep プラグマの無効化)

これらの解釈は、ほかのベンダーの ivdep プラグマの解釈との互換性のために提供されます。

A.2.127 `-xjobs=n`

コンパイラが処理を行うために生成するプロセスの数を設定するには、-xjobs オプションを指定します。このオプションを使用すると、マルチプロセッサマシン上での構築時間を短縮できます。現時点では、-xjobs とともに使用できるのは -xipo オプションだけです。-xjobs=n を指定すると、内部手続きオプティマイザは、さまざまなファイルをコンパイルするために呼び出すことができるコードジェネレータインスタンスの最大数として、n を使用します。

A.2.127.1 値

-xjobs には必ず値を指定する必要があります。それ以外の場合は、エラー診断が発行され、コンパイルは中止されます。

一般に、n に指定する確実な値は、使用できるプロセッサ数に 1.5 を掛けた数です。使用可能なプロセッサの数の何倍もの値を使用すると、生成されるジョブ間のコンテキスト切り替えのオーバーヘッドのために、パフォーマンスが低下する場合があります。また、あまり大きな数を使用すると、スワップ領域などシステムリソースの限界を超える場合があります。

A.2.127.2 デフォルト

コマンド行に複数の -xjobs のインスタンスがある場合、一番右にあるインスタンスが実行されるまで相互に上書きします。

A.2.127.3 例

次の例に示すコマンドは 2 つのプロセッサを持つシステム上で、-xjobs オプションを指定しないで実行された同じコマンドよりも高速にコンパイルを実行します。

 example% CC -xipo -xO4 -xjobs=3 t1.cc t2.cc t3.cc

A.2.128 `-xkeepframe`[`=`[ `%all,%none`,`name`,`no%` `name`]]

指定した機能 (name) のスタック関連の最適化を禁止します。

%all: すべてのコードのスタック関連最適化を禁止します。
%none: すべてのコードのスタック関連最適化を許可します。

このオプションは累積的で、コマンド行で複数回指定できます。たとえば、—xkeepframe=%all —xkeepframe=no%func1 は、func1 を除くすべての関数のスタックフレームが保持されるはずであることを示します。また、—xkeepframe は —xregs=frameptr より優先されます。たとえば、—xkeepframe=%all —xregs=frameptr は、すべての関数のスタックが保持されるはずですが、—xregs=frameptr の最適化は無視されることを示します。

このオプションがコマンド行で指定されていないと、コンパイラはデフォルトの -xkeepframe=%none を使用します。このオプションが値なしで指定されると、コンパイラは -xkeepframe=%all を使用します。

A.2.129 `-xlang`=`language` [`,language`]

該当する実行時ライブラリをインクルードし、指定された言語に適切な実行時環境を用意します。

A.2.129.1 値

language は f77、f90、f95、c99 のいずれかとします。

f90 引数と f95 引数は同じです。c99 引数は、cc -xc99=%all を付けてコンパイルされ、CC を付けてリンクされようとしているオブジェクトに対して ISO 9899:1999 C プログラミング言語の動作を呼び出します。

A.2.129.2 相互の関連性

-xlang=f90 と -xlang=f95 の各オプションは -library=f90 を意味し、-xlang=f77 オプションは -library=f77 を意味します。ただし、-library=f77 と -library=f90 の各オプションは、-xlang オプションしか正しい実行時環境を保証しないので、言語が混合したリンクには不十分です。

言語が混合したリンクの場合、ドライバは次の順序で言語階層を使用してください。

C++
Fortran 95 (または Fortran 90)
Fortran 77
C または C99

Fortran 95、FORTRAN 77、および C++ のオブジェクトファイルを一緒にリンクする場合は、最上位言語のドライバを使用します。たとえば、C++ と Fortran 95 のオブジェクトファイルをリンクするには、次の C++ コンパイラコマンドを使用します。

example% CC -xlang=f95...

Fortran 95 と Fortran 77 のオブジェクトファイルをリンクするには、次のように Fortran 95 ドライバを使用します。

example% f95 -xlang=f77...

-xlang オプションと -xlic_lib オプションを同じコンパイラコマンドで使用することはできません。-xlang を使用していて、しかも Sun Performance Library でリンクする必要がある場合は、代わりに -library=sunperf を使用してください。

A.2.129.3 警告

-xlang と一緒に -xnolib を使用しないでください。

Fortran 並列オブジェクトを C++ オブジェクトと混合している場合は、リンク行に -mt フラグを指定する必要があります。

A.2.129.4 関連項目

-library、-staticlib

A.2.130 `-xldscope=`{v}

extern シンボルの定義に対するデフォルトのリンカースコープを変更するには、-xldscope オプションを指定します。デフォルトを変更すると、実装がよりうまく隠蔽されるため、共有ライブラリと実行可能ファイルをより高速かつ安全に使用できるようになります。

A.2.130.1 値

次の表に、v に指定可能な値を示します。

表 A-36 -xldscope の値

値	意味
`global`	大域リンカースコープは、もっとも制限の少ないリンカースコープです。シンボル参照はすべて、そのシンボルが定義されている最初の動的ロードモジュール内の定義と結合します。このリンカースコープは、extern シンボルの現在のリンカースコープです。
`symbolic`	シンボリックリンカースコープは、大域リンカースコープよりも制限的です。リンク対象の動的ロードモジュール内からのシンボルへの参照はすべて、そのモジュール内に定義されているシンボルと結合します。モジュール外については、シンボルは大域なものとなります。このリンカースコープはリンカーオプション `-Bsymbolic` に対応します。C++ ライブラリでは `-Bsymbolic` を使用できませんが、`-xldscope=symbolic` 指定子は問題なく使用できます。リンカーの詳細については、`ld`(1) のマニュアルページを参照してください。
`hidden`	隠蔽リンカースコープは、シンボリックリンカースコープや大域リンカースコープよりも制限されたリンカースコープです。動的ロードモジュール内の参照はすべて、そのモジュール内の定義に結合します。シンボルはモジュールの外側では認識されません。

A.2.130.2 デフォルト

-xldscope を指定しない場合は、コンパイラでは -xldscope=global が指定されます。値を指定しないで -xldscope を指定すると、コンパイラがエラーを出力します。コマンド行にあるこのオプションの複数のインスタンスは、右端のインスタンスに達するまで互いに上書きされます。

A.2.130.3 警告

クライアントがライブラリ内の関数をオーバーライドできるようにする場合は必ず、ライブラリの構築時に関数がインラインで生成されないようにしてください。コンパイラは次の状況で関数をインライン化します。

関数名は、-xinline で指定されます。
インライン化が自動的に実行される -xO4 以上を使用してコンパイルした場合。
インライン指示子またはファイル間の最適化を使用した場合。

たとえば、ABC というライブラリにデフォルトの allocator 関数があり、ライブラリクライアントがその関数を使用でき、ライブラリの内部でも使用されるものとします。

void* ABC_allocator(size_t size) { return malloc(size); }

-xO4 以上でライブラリを構築すると、コンパイラはライブラリ構成要素内での ABC_allocator の呼び出しをインライン化します。ライブラリクライアントが ABC_allocator を独自の allocator と置き換える場合、置き換えられた allocator は ABC_allocator を呼び出したライブラリ構成要素内では実行されません。最終的なプログラムには、この関数の相異なるバージョンが含まれることになります。

__hidden 指示子または __symbolic 指示子で宣言されたライブラリ関数は、ライブラリの構築時にインラインで生成することができます。これらの指示子がクライアントによって上書きされることは想定されていません。「4.1 リンカースコープ」を参照してください。

__global 指示子で宣言されたライブラリ関数はインラインで宣言しないでください。また、-xinline コンパイラオプションを使用することによってインライン化されることがないようにしてください。

A.2.130.4 関連項目

-xinline、-xO

A.2.131 `-xlibmieee`

例外時に libm が数学ルーチンに対し IEEE 754 値を返します。

libm のデフォルト動作は XPG に準拠します。

A.2.131.1 関連項目

『数値計算ガイド』

A.2.132 `-xlibmil`

選択された libm 数学ライブラリルーチンを最適化のためにインライン化します。

注 - このオプションは C++ インライン関数には影響しません。

このオプションは、現在使用されている浮動小数点オプションとプラットフォームのためのもっとも高速な実行可能ファイルを生成する、libm ルーチンのインラインテンプレートを選択します。

A.2.132.1 相互の関連性

このオプションの機能は、-fast オプションを指定した場合にも含まれます。

A.2.133 `-xlibmopt`

最適化された数学ルーチンのライブラリを使用します。このオプションを使用するときは -fround=nearest を指定することによって、デフォルトの丸めモードを使用する必要があります。

パフォーマンスが最適化された数学ルーチンのライブラリを使用し、より高速で実行できるコードを生成します。通常の数学ライブラリを使用した場合とは、結果が少し異なることがあります。このような場合、異なる部分は通常は最後のビットです。

このライブラリオプションをコマンド行に指定する順序は重要ではありません。

A.2.133.1 相互の関連性

このオプションの機能は、-fast オプションを指定した場合にも含まれます。

A.2.133.2 関連項目

-fast、-xnolibmopt、-fround

A.2.134 `-xlic_lib=sunperf`

非推奨。使用しないでください。代わりに、-library=sunperf を指定します。詳細は、「A.2.49 -library=l[ ,l...]」を参照してください。

A.2.135 `-xlicinfo`

このオプションは、コンパイル時には暗黙的に無視されます。

A.2.136 `-xlinkopt`[`=` level]

(SPARC のみ) コンパイラに、オブジェクトファイル内のすべての最適化に加えて、結果として得られる実行可能ファイルまたは動的ライブラリに対してリンク時の最適化を実行するよう指示します。このような最適化は、リンク時にオブジェクトのバイナリコードを解析することによって実行されます。オブジェクトファイルは書き換えられませんが、最適化された実行可能コードは元のオブジェクトコードとは異なる場合があります。

-xlinkopt をリンク時に有効にするには、少なくともコンパイルコマンドで -xlinkopt を使用する必要があります。-xlinkopt を指定しないでコンパイルされたオブジェクトバイナリについても、オプティマイザは限定的な最適化を実行できます。

-xlinkopt は、コンパイラのコマンド行にある静的ライブラリのコードは最適化しますが、コマンド行にある共有 (動的) ライブラリのコードは最適化しません。-xlinkopt は、共有ライブラリを構築する (-G でコンパイルする) 場合にも使用できます。

A.2.136.1 値

level には、実行する最適化のレベルを 0、1、2 のいずれかで設定します。最適化レベルを次の表に示します。

表 A-37 -xlinkopt の値

値	意味
0	リンクオプティマイザは無効になっています (デフォルト)。
1	リンク時の命令キャッシュカラーリングと分岐の最適化を含む、制御フロー解析に基づき最適化を実行します。
2	リンク時のデッドコードの除去とアドレス演算の簡素化を含む、追加のデータフロー解析を実行します。

コンパイル手順とリンク手順を別々にコンパイルする場合は、両方の手順に -xlinkopt を指定する必要があります。

example% cc -c -xlinkopt a.c b.c
example% cc -o myprog -xlinkopt=2 a.o

レベルパラメータは、コンパイラがリンクしている場合にのみ使用されます。この例では、オブジェクトバイナリが暗黙のレベル 1 でコンパイルされていても、リンクオプティマイザのレベルは 2 です。

A.2.136.2 デフォルト

レベルパラメータなしで -xlinkopt を使用することは、-xlinkopt=1 を指定することと同じです。

A.2.136.3 相互の関連性

このオプションは、プログラム全体のコンパイル時に、プロファイルのフィードバックとともに使用されると、もっとも効果的です。プロファイリングは、コードの使用頻度がもっとも高い部分ともっとも低い部分を明らかにし、オプティマイザにそれに基づいて処理を集中するよう指示します。これは、リンク時に実行されるコードの最適な配置が命令のキャッシュミスを低減できるような、大きなアプリケーションにとって特に重要です。このオプションは通常、次のように使用されます。

example% cc -o progt -xO5 -xprofile=collect:prog file.c
example% progt
example% cc -o prog -xO5 -xprofile=use:prog -xlinkopt file.c

プロファイルのフィードバックの使用についての詳細は、「A.2.164 -xprofile=p」を参照してください。

A.2.136.4 警告

-xlinkopt でコンパイルする場合は、-zcombreloc リンカーオプションは使用しないでください。

このオプションを指定してコンパイルすると、リンク時間がわずかに増えます。オブジェクトファイルも大きくなりますが、実行可能ファイルのサイズは変わりません。-xlinkopt と -g を指定してコンパイルすると、デバッグ情報が取り込まれるので、実行可能ファイルのサイズが増えます。

A.2.137 `-xloopinfo`

このオプションは、どのループが並列化されているかを表示し、通常は -xautopar オプションとともに使用されます。

A.2.138 `–xM`

指定された C++ プログラムに対して C++ プリプロセッサのみを実行し、そのプリプロセッサに対し、メイクファイルの依存関係を生成し、結果を標準出力に送信するよう要求します。make ファイルと依存関係についての詳細は、make(1) のマニュアルページを参照してください。

ただし、-xM を指定すると、インクルードされているヘッダーの依存関係のみを報告し、関連付けられているテンプレート定義ファイルの依存関係を報告しません。メイクファイルの中で .KEEP_STATE 機能を使用して、make ユーティリティーが使用する .make.state ファイルの中にあるすべての依存関係を使用することもできます。

A.2.138.1 例

次の例:

#include <unistd.h>
void main(void)
{}

この出力を生成します。

e.o: e.c
e.o: /usr/include/unistd.h
e.o: /usr/include/sys/types.h
e.o: /usr/include/sys/machtypes.h
e.o: /usr/include/sys/select.h
e.o: /usr/include/sys/time.h
e.o: /usr/include/sys/types.h
e.o: /usr/include/sys/time.h
e.o: /usr/include/sys/unistd.h

A.2.138.2 相互の関連性

-xM と -xMF を指定する場合、-xMF で指定したファイルに、コンパイラはすべてのメイクファイルの依存関係情報を書き込みます。プリプロセッサがこのファイルへの書き込みを行うたびに、このファイルは上書きされます。

A.2.138.3 関連項目

メイクファイルと依存関係についての詳細は、make(1S) のマニュアルページを参照してください。

A.2.139 `-xM1`

/usr/include ヘッダーファイルの依存関係を報告せず、またコンパイラで提供されるヘッダーファイルの依存関係を報告しない点を除き、-xM のようなメイクファイルの依存関係を生成します。

-xM1 と -xMF を指定する場合、-xMF で指定したファイルに、コンパイラはすべてのメイクファイルの依存関係情報を書き込みます。プリプロセッサがこのファイルへの書き込みを行うたびに、このファイルは上書きされます。

A.2.140 `-xMD`

-xM と同様にメイクファイルの依存関係を生成しますが、コンパイルを続行します。-xMD は、指定されている場合は -o 出力ファイル名から派生したメイクファイルの依存関係情報の出力ファイルを生成します。または、ファイル名接尾辞を .d に置換 (または追加) して、入力元ファイル名を生成します。-xMD と -xMF を指定した場合、プリプロセッサは、メイクファイルのすべての依存関係情報を -xMF で指定されたファイルに書き込みます。複数のソースファイルで -xMD -xMF または -xMD -o filename を使用してコンパイルすることはできず、エラーが生成されます。依存関係ファイルがすでに存在する場合は上書きされます。

A.2.141 `-xMF`

メイクファイルの依存関係の出力先ファイルを指定するには、このオプションを使用します。1 つのコマンド行で、複数の入力ファイルに対して -xMF で個別のファイル名を指定することはできません。複数のソースファイルを使用して -xMD -xMF または -xMMD -xMF を使用してコンパイルすることは許可されておらず、エラーが生成されます。依存関係ファイルがすでに存在する場合は上書きされます。

A.2.142 `-xMMD`

システムヘッダーファイルを除き、メイクファイルの依存関係を生成するには、このオプションを使用します。このオプションでは -xM1 と同じ機能が提供されますが、コンパイルは続行されます。-xMMD は、-o 出力ファイル名 (指定されている場合) または入力ソースファイル名から派生したメイクファイルの依存関係情報のための出力ファイルを生成して、ファイル名接尾辞を .d に置き換え (または追加) します。-xMF を指定する場合、コンパイラは代わりに、ユーザーが指定したファイル名を使用します。複数のソースファイルで -xMMD -xMF または -xMMD -o filename を使用してコンパイルすることはできず、エラーが生成されます。依存関係ファイルがすでに存在する場合は上書きされます。

A.2.143 `-xMerge`

(SPARC のみ) データセグメントをテキストセグメントにマージします。

オブジェクトファイル内のデータは読み取り専用であり、ld -N を使用してリンクしないかぎりプロセス間で共有されます。

3 つのオプション -xMerge -ztext -xprofile=collect を一緒に使用するべきではありません。-xMerge を指定すると、静的に初期化されたデータを読み取り専用記憶領域に強制的に配置します。 -ztext を指定すると、位置に依存するシンボルを読み取り専用記憶領域内で再配置することを禁止します。-xprofile=collect を指定すると、書き込み可能記憶領域内で、静的に初期化された、位置に依存するシンボルの再配置を生成します。

A.2.143.1 関連項目

ld(1) のマニュアルページ

A.2.144 `-xmaxopt`[=`v`]

このオプションは、pragma opt のレベルを指定されたレベルに制限します。v は、off、1、2、3、4、5 のいずれかです。デフォルト値は -xmaxopt=off であり、pragma opt は無視されます。引数を指定せずに -xmaxopt を指定したときのデフォルトは -xmaxopt=5 です。

-xO と -xmaxopt の両方を指定する場合、-xO で設定する最適化レベルが -xmaxopt 値を超えてはいけません。

A.2.145 `-xmemalign=`ab

(SPARC のみ) データの境界整列に関するコンパイラの前提を制御するには、-xmemalign オプションを使用します。境界整列が潜在的に正しくないメモリーアクセスにつながる生成コードを制御し、境界整列が正しくないアクセスが発生したときのプログラム動作を制御すれば、より簡単に SPARC にコードを移植できます。

想定するメモリー境界整列の最大値と、境界整列に失敗したデータがアクセスされた際の動作を指定します。a (境界整列) と b (動作) の両方に値を指定する必要があります。a は想定される最大メモリー境界整列を指定し、b は境界整列されていないメモリーアクセスに対応する動作を指定します。

コンパイル時に境界整列が判別できるメモリーへのアクセスの場合、コンパイラはそのデータの境界整列に適したロードおよびストア命令を生成します。

境界整列がコンパイル時に決定できないメモリーアクセスの場合、コンパイラは、境界整列を想定して、必要なロード/ストア命令のシーケンスを生成します。

実行時の実際のデータ境界整列が指定された整列に達しない場合、境界整列に失敗したアクセス (メモリー読み取りまたは書き込み) が行われると、トラップが発生します。このトラップに対して発生する可能性のある応答は次の 2 つです。

OS がトラップを SIGBUS シグナルに変換します。プログラムがこのシグナルを捕捉しなかった場合、プログラムは異常終了します。プログラムがシグナルを捕捉しても、境界整列に失敗したアクセスが成功するわけではありません。
境界整列に失敗したアクセスが正常に成功したかのように OS がアクセスを解釈し、プログラムに制御を戻すことによってトラップを処理します。

A.2.145.1 値

-xmemalign の境界整列と動作の値を次に示します。

a の値:

1: 最大で 1 バイトの境界整列を想定します。

2: 最大で 2 バイトの境界整列を想定します。

4: 最大で 4 バイトの境界整列を想定します。

8: 最大で 8 バイトの境界整列を想定します。

16: 最大で 16 バイトの境界整列を想定します。

b の値:

i: アクセスを解釈し、実行を継続する

s: シグナル SIGBUS を発生させます。

f

64 ビット SPARC アーキテクチャーの場合: 4 以下の境界整列に対してシグナル SIGBUS を発生させます。それ以外の場合は、アクセスを解釈し、実行を継続します。

その他のすべてのアーキテクチャーでは、このフラグは i と同等です。

b を i か f のいずれかに設定してコンパイルしたオブジェクトファイルにリンクする場合は、必ず、-xmemalign を指定する必要があります。「3.3.3 コンパイル時とリンク時のオプション」に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。

A.2.145.2 デフォルト

次のデフォルトの値は、-xmemalign オプションがまったく指定されていない場合にのみ適用されます。

-xmemalign=8i は、すべての 32 ビット SPARC アーキテクチャー (-m32) に適用されます。
-xmemalign=8s は、すべての 64 ビット SPARC アーキテクチャー (-m64) に適用されます。

-xmemalign オプションが存在するが、値が指定されていない場合は、次のデフォルト値が使用されます。

-xmemalign=1i は、すべてのアーキテクチャーに適用されます。

A.2.145.3 例

さまざまな境界整列の状況を処理する場合の -xmemalign の使用方法を次に示します。

-xmemalign=1s: すべてのメモリーアクセスの整列が正しくないため、トラップ処理が遅すぎる。

-xmemalign=8i: コード内で、不定期の、意図的な、境界整列されていないアクセスが発生する場合があるが、それ以外は正しい。

-xmemalign=8s: プログラム内で、境界整列されていないアクセスは発生しない。

-xmemalign=2s: 奇数バイトへのアクセスが存在しないか検査したい

-xmemalign=2i: 奇数バイトへのアクセスが存在しないか検査し、プログラムを実行したい

A.2.146 `-xmodel=`[a]

(x86 のみ) -xmodel オプションを使用すると、コンパイラは Oracle Solaris x86 プラットフォーム用の 64 ビットオブジェクトの形式を変更できるようになります。このオプションは、このようなオブジェクトのコンパイルに対してのみ指定してください。

このオプションは、64 ビット対応の x64 プロセッサで -m64 も指定した場合にのみ有効です。

次の表に、a に指定可能な値を示します。

表 A-38 -xmodel のフラグ

値	意味
`small`	このオプションは、実行されるコードの仮想アドレスがリンク時にわかっていて、すべてのシンボルが 0 ~ 2^31 - 2^24 - 1 の範囲の仮想アドレスに配置されることがわかっているスモールモデルのコードを生成します。
`kernel`	すべてのシンボルが 2^64 - 2^31 ~ 2^64 - 2^24 の範囲で定義されるカーネルモデルのコードを生成します。
`medium`	データセクションへのシンボリック参照の範囲に関する前提がないミディアムモデルのコードを生成します。テキストセクションのサイズとアドレスには、スモールコードモデルと同じ制限があります。静的データが大量にあるアプリケーションでは、`-m64` を指定してコンパイルするときに、`-xmodel=medium` が必要になることがあります。

このオプションは累積的ではないため、コンパイラは、コマンド行にある -xmodel の右端のインスタンスに従ってモデル値を設定します。

-xmodel を指定しない場合、コンパイラは -xmodel=small とみなします。引数を指定せずに-xmodel を指定すると、エラーになります。

すべての変換ユニットをこのオプションを使用してコンパイルする必要はありません。アクセスするオブジェクトが範囲内にあれば、選択したファイルをコンパイルできます。

すべての Linux システムが、ミディアムモデルをサポートしているわけではありません。

A.2.147 `-xnolib`

デフォルトのシステムライブラリとのリンクを無効にします。

通常 (このオプションを指定しない場合)、C++ コンパイラは、C++ プログラムをサポートするためにいくつかのシステムライブラリとリンクします。このオプションを指定すると、デフォルトのシステムサポートライブラリとリンクするための -llib オプションが ld に渡されません。

通常、コンパイラは、システムサポートライブラリにこの順序でリンクします。

デフォルトの -compat=5 の場合、ライブラリは次のとおりです。
```
-lCstd -lCrun -lm -lc
```
Linux 上の -compat=g の場合、ライブラリは次のとおりです。
```
 —lstdc++ —lCrunG3 —lm —lc 
```
Oracle x86 上の -compat=g の場合、ライブラリは次のとおりです。
```
 —lstdc++ —lgcc_s —lCrunG3 —lm —lc 
```

-l オプションの順序は重要です。-lm オプションは -lc の前にある必要があります。

注 - -mt コンパイラオプションを指定した場合、コンパイラは通常 -lm でリンクする直前に -lthread でリンクします。

デフォルトでどのシステムサポートライブラリがリンクされるかを知りたい場合は、コンパイルで-dryrun オプションを指定します。たとえば、次のコマンドを実行するとします。

example% CC foo.cc -m64 -dryrun

この出力には次の内容が示されます。

-lCstd -lCrun -lm -lc

A.2.147.1 例

C アプリケーションのバイナリインタフェースを満たす最小限のコンパイルを行う (つまり、必要な C サポートのみを含む C++ プログラムを生成する) には、次のコマンドを使用します。

example% CC -xnolib test.cc –lc

libm を一般的なアーキテクチャー命令セットを含むシングルスレッドアプリケーションに静的にリンクするには、次のコマンドを使用します。

example% CC -xnolib test.cc -lCstd -lCrun -Bstatic -lm -Bdynamic -lc

A.2.147.2 相互の関連性

-xnolib を指定する場合は、必要なすべてのシステムサポートライブラリを手動で一定の順序にリンクする必要があります。システムサポートライブラリは最後にリンクしなければいけません。

-xnolib を指定すると、-library は無視されます。

A.2.147.3 警告

多くの C++ 言語機能では、libCrun (標準モード) を使用する必要があります。

このリリースのシステムサポートライブラリは安定していないため、リリースごとに変更される可能性があります。

A.2.147.4 関連項目

-library、-staticlib、-l

A.2.148 `-xnolibmil`

コマンド行の -xlibmil を取り消します。

最適化された数学ライブラリとのリンクを変更するには、このオプションを -fast と一緒に使用してください。

A.2.149 `-xnolibmopt`

数学ルーチンのライブラリを使用しません。

A.2.149.1 例

次の例のように、このオプションはコマンド行で -fast オプションを指定した場合は、そのあとに使用してください。

example% CC –fast –xnolibmopt

A.2.150 `-xnorunpath`

「A.2.60 -norunpath」と同じです

A.2.151 `-xOlevel`

最適化レベルを指定します。大文字 O のあとに数字の 1、2、3、4、5 のいずれかが続きます。一般的に、プログラムの実行速度は最適化のレベルに依存します。最適化レベルが高いほど、実行時のパフォーマンスは向上します。しかし、最適化レベルが高ければ、それだけコンパイル時間が増え、実行可能ファイルが大きくなる可能性があります。

ごくまれに、-xO2 の方がほかの値より実行速度が速くなることがあり、-xO3 の方が -xO4 より早くなることがあります。すべてのレベルでコンパイルを行なってみて、こうしたことが発生するかどうか試してみてください。

メモリー不足になった場合、オプティマイザは最適化レベルを落として現在の手続きをやり直すことによってメモリー不足を回復しようとします。ただし、以降の手続きについては、-xOlevel オプションで指定された最適化レベルを使用します。

以降の節では、5 つの -xO level 最適化レベルが SPARC プラットフォームと x86 プラットフォーム上でどのように動作するかについて説明します。

A.2.151.1 値

SPARC プラットフォームの場合

-xO1 では、最小限の最適化 (ピープホール) が行われます。これはコンパイルの後処理におけるアセンブリレベルでの最適化です。-xO2 や -xO3 を使用するとコンパイル時間が著しく増加する場合や、スワップ領域が不足する場合だけ -xO1 を使用してください。
-xO2 では、次の基本的な局所的および大域的な最適化が行われます。
- 帰納的変数の削除
- 局所的および大域的な共通部分式の削除
- 計算の簡略化
- コピーの伝播
- 定数の伝播
- ループ不変式の最適化
- レジスタ割り当て
- 基本ブロックのマージ
- 末尾再帰の削除
- デッドコードの削除
- 末尾呼び出しの削除
- 複雑な式の展開
  
  このレベルでは、外部変数や間接変数の参照や定義は最適化されません。
-xO3 では、-xO2 レベルで行う最適化に加えて、外部変数に対する参照と定義も最適化されます。このレベルでは、ポインタ代入の影響は追跡されません。volatile で正しく保護されていないデバイスドライバか、またはシグナルハンドラ内から外部変数を変更するプログラムをコンパイルする場合は、-xO2 を使用します。一般に、このレベルを使用すると、-xspace オプションと組み合わせないかぎり、コードサイズが大きくなります。
-xO4 は、-xO3 の最適化の実行に加えて、同じファイルに含まれている関数の自動インライン化を実行します。インライン化を自動的に行なった場合、通常は実行速度が速くなりますが、遅くなることもあります。一般に、このレベルを使用すると、-xspace オプションと組み合わせないかぎり、コードサイズが大きくなります。
-xO5 では、最高レベルの最適化が行われます。これを使用するのは、コンピュータのもっとも多くの時間を小さなプログラムが使用している場合だけにしてください。このレベルで使用される最適化アルゴリズムでは、コンパイル時間が増えたり、実行時間が改善されないことがあります。このレベルの最適化によってパフォーマンスが改善される確率を高くするには、プロファイルのフィードバックを使用します。「A.2.164 -xprofile=p」を参照してください。

x86 プラットフォームの場合

-xO1 では、基本的な最適化を行います。このレベルには、計算の簡略化、レジスタ割り当て、基本ブロックのマージ、デッドコードとストアの削除、およびピープホールの最適化が含まれます。
-xO2 では、局所的な共通部分の削除、局所的なコピーと定数の伝播、末尾再帰の削除、およびレベル 1 で行われる最適化を実行します。
-xO3 では、局所的な共通部分の削除、大域的なコピーと定数の伝播、ループ強度低下、帰納的変数の削除、およびループ不変式の最適化、およびレベル 2 で行われる最適化を実行します。
-xO4 では、レベル 3 で行う最適化レベルに加えて、同じファイルに含まれる関数の自動的なインライン化も行われます。インライン化を自動的に行なった場合、通常は実行速度が速くなりますが、遅くなることもあります。このレベルでは一般用のフレームポインタ登録 (edp) も解放します。一般にこのレベルを使用するとコードサイズが大きくなります。
-xO5 では、最高レベルの最適化が行われます。このレベルで使用される最適化アルゴリズムでは、コンパイル時間が増えたり、実行時間が改善されないことがあります。

A.2.151.2 相互の関連性

-g または -g0 を使用するとき、最適化レベルが -xO3 以下の場合、最大限のシンボリック情報とほぼ最高の最適化が得られます。

-g または -g0 を使用するとき、最適化レベルが -xO4 以上の場合、最大限のシンボリック情報と最高の最適化が得られます。

-g によるデバッグでは、-xOlevel が抑制されませんが、-xOlevel はいくつかの方法で -g を制限します。たとえば、-xOlevel オプションを使用すると、dbx から渡された変数を表示できないなど、デバッグの機能が一部制限されます。しかし、dbx where コマンドを使用して、シンボリックトレースバックを表示することは可能です。詳細は、『dbx コマンドによるデバッグ』を参照してください。

-xipo オプションは、-xO4 または -xO5 と一緒に使用した場合にのみ効果があります。

-xinline オプションは -xO3 未満の最適化レベルには影響を与えません。-xO4 では、-xinline オプションを指定したかどうかは関係なく、オプティマイザはどの関数をインライン化するかを判断します。-xO4 では、コンパイラはどの関数が、インライン化されたときにパフォーマンスを改善するかを判断しようとします。-xinline を指定して関数のインライン化を強制すると、実際にパフォーマンスを低下させる可能性があります。

A.2.151.3 デフォルト

デフォルトでは最適化は行われません。ただし、これは最適化レベルを指定しない場合にかぎり有効です。最適化レベルを指定すると、最適化を無効にするオプションはありません。

最適化レベルを設定しないようにする場合は、最適化レベルを示すようなオプションを指定しないようにしてください。たとえば、-fast は最適化を -xO5 に設定するマクロオプションです。最適化レベルを暗黙に示すほかのすべてのオプションは、最適化レベルが設定されているという警告メッセージを発行します。最適化を設定せずにコンパイルする唯一の方法は、コマンド行またはメイクファイルから最適化レベルを指定するオプションをすべて削除することです。

A.2.151.4 警告

大規模な手続き (数千行のコードからなる手続き) に対して -xO3 または -xO4 を指定して最適化をすると、不合理な大きさのメモリーが必要になります。マシンのパフォーマンスが低下することがあります。

この低下が発生しないようにするには、limit コマンドを使用して、1 つのプロセスで使用できる仮想メモリーの量を制限します。csh(1) のマニュアルページを参照してください。たとえば、仮想メモリーを 4G バイトに制限するには、次のコマンドを使用します。

example% limit datasize 4G

このコマンドにより、データ領域が 4G バイトに達したときに、オプティマイザがメモリー不足を回復しようとします。

マシンが使用できるスワップ領域の合計容量を超える値は、制限値として指定することはできません。制限値は、大規模なコンパイル中でもマシンの通常の使用ができるぐらいの大きさにしてください。

最良のデータサイズ設定値は、要求する最適化のレベルと実メモリーの量、仮想メモリーの量によって異なります。

実際のスワップ領域を検索するには、swap- l と入力します。

実際の実メモリーを検索するには、dmesg | grep mem と入力します。

A.2.151.5 関連項目

-xldscope -fast、-xprofile=p、csh(1) のマニュアルページ

A.2.152 `-xopenmp`[`=` `i`]

OpenMP 指令による明示的並列化を使用するには、-xopenmp オプションを指定します。

A.2.152.1 値

次の表に i の値を示します。

表 A-39 -xopenmp の値

値	意味
`parallel`	OpenMP プラグマの認識を有効にします。`-xopenmp=parallel` での最小の最適化レベルは `-xO3` です。コンパイラは、必要に応じて最適化を低いレベルから `-xO3` に変更し、警告を発行します。このフラグは、プリプロセッサトークン `_OPENMP` も定義します。
`noopt`	OpenMP プラグマの認識を有効にします。最適化レベルが `-O3` より低い場合は、最適化レベルは上げられません。 `CC` `-O2` `-xopenmp=noopt` のように、`-O3` より低い最適化レベルを明示的に設定した場合、コンパイラはエラーを発生させます。`-xopenmp=noopt` で最適化レベルを指定しない場合は、OpenMP プラグマが認識され、それに応じてプログラムが並列化されますが、最適化は実行されません。このフラグは、プリプロセッサトークン `_OPENMP` も定義します。
`none`	このフラグはデフォルトであり、OpenMP プラグマの認識を無効にします。コンパイルの最適化レベルは変更せず、どのプリプロセッサトークンも事前定義しません。

A.2.152.2 デフォルト

-xopenmp を指定しない場合、コンパイラのデフォルトは -xopenmp=none です。

-xopenmp を引数なしで指定した場合、コンパイラのデフォルトは -xopenmp=parallel です。

A.2.152.3 相互の関連性

dbx を指定して OpenMP プログラムをデバッグする場合、-g と -xopenmp=noopt を指定してコンパイルすれば、並列化部分にブレークポイントを設定して変数の内容を表示することができます。

OpenMP プログラムを実行するときに使用するスレッドの数を指定するには、OMP_NUM_THREADS 環境変数を使用します。OMP_NUM_THREADS が設定されていない場合、使用されるスレッドの数のデフォルトは 2 です。より多くのスレッドを使用するには、OMP_NUM_THREADS をより高い値に設定します。1 つのスレッドだけで実行する場合は、OMP_NUM_THREADS を 1 に設定します。一般に、OMP_NUM_THREADS は、実行中のシステム上の使用可能な仮想プロセッサの数に設定します。これは、Oracle Solaris の psrinfo(1) コマンドを使用して特定できます。詳細は、『Oracle Solaris Studio OpenMP API ユーザーガイド』を参照してください。

入れ子並列を有効にするには、OMP_NESTED 環境変数を TRUE に設定する必要があります。入れ子並列は、デフォルトでは無効です。詳細は、『Oracle Solaris Studio OpenMP API ユーザーズガイド』を参照してください。

A.2.152.4 警告

-xopenmp のデフォルトは、将来変更される可能性があります。警告メッセージを出力しないようにするには、適切な最適化を明示的に指定します。

コンパイルとリンクを別々に実行する場合は、コンパイル手順とリンク手順の両方に -xopenmp を指定してください。共有オブジェクトを作成する場合、このことは重要です。実行可能ファイルのコンパイルに使用されたコンパイラは、xopenmp を使用して -.so を構築したコンパイラより古いものであってはいけません。これは、OpenMP 指令を含むライブラリをコンパイルする場合に特に重要です。「3.3.3 コンパイル時とリンク時のオプション」に、コンパイル時とリンク時の両方に指定する必要があるオプションの全一覧をまとめています。

最良のパフォーマンスを得るには、OpenMP 実行時ライブラリ libmtsk.so の最新パッチが、システムにインストールされていることを確認してください。

A.2.152.5 関連項目

多重処理アプリケーションを構築するのための OpenMP Fortran 95、C、および C++ アプリケーションプログラムインタフェース (API) の完全な概要については、『『Oracle Solaris Studio OpenMP API ユーザーズガイド』』を参照してください。

A.2.153 `-xpagesize=`n

スタックとヒープの優先ページサイズを設定します。

A.2.153.1 値

次の値は、SPARC で有効です。4k、8K、64K、512K、2M、4M、32M、256M、2G、16G、または default。

次の値は、x86/x64 で有効です。4K、2M、4M、1G、または default。

ターゲットプラットフォームに対して有効なページサイズを指定する必要があります。有効なページサイズを指定しない場合は、要求は実行時にサイレントに無視されます。

Oracle Solaris オペレーティングシステムでページのバイト数を判断するには、getpagesize(3C) コマンドを使用します。Solaris オペレーティングシステムでは、ページサイズ要求に従うという保証はありません。ターゲットプラットフォームのページサイズを判断するために、pmap(1) または meminfo(2) を使用できます。

注 - このオプションを使用してコンパイルすると、LD_PRELOAD 環境変数を同等のオプションを使用して mpss.so.1 に設定するか、またはプログラムを実行する前に同等のオプションを使用して Oracle Solaris のコマンド ppgsz(1) を実行するのと同じ効果があります。詳細は、Oracle Solaris の各マニュアルページを参照してください。

A.2.153.2 デフォルト

-xpagesize=default を指定する場合は、Oracle Solaris オペレーティングシステムがページサイズを設定します。

A.2.153.3 展開

このオプションは -xpagesize_heap と -xpagesize_stack のマクロです。これらの 2 つのオプションは -xpagesize と同じ次の引数を使用します。4k、8K、64K、512K、2M、4M、32M、256M、2G、16G、default のいずれか。両方に同じ値を設定するには -xpagesize を指定します。別々の値を指定するには個々に指定します。

A.2.153.4 警告

-xpagesize オプションは、コンパイル時とリンク時に使用しないかぎり無効です。「3.3.3 コンパイル時とリンク時のオプション」に、コンパイル時とリンク時の両方に指定する必要があるオプションの全一覧をまとめています。

A.2.154 `-xpagesize_heap=`n

メモリー上のヒープのページサイズを設定します。

A.2.154.1 値

n の値は、4k、8K、64K、512K、2M、4M、32M、256M、2G、16G、または default です。ターゲットプラットフォームに対して有効なページサイズを指定する必要があります。有効なページサイズを指定しない場合は、要求は実行時にサイレントに無視されます。

A.2.154.2 デフォルト

-xpagesize_heap=default を指定する場合は、Oracle Solaris オペレーティングシステムがページサイズを設定します。

A.2.154.3 警告

-xpagesize_heap オプションは、コンパイル時とリンク時に使用しないかぎり無効です。

A.2.155 `-xpagesize_stack=`n

メモリー上のスタックのページサイズを設定します。

A.2.155.1 値

Oracle Solaris オペレーティングシステムでページのバイト数を判断するには、getpagesize(3C) コマンドを使用します。Oracle Solaris オペレーティングシステムは、ページサイズ要求に従うという保証を提供しません。ターゲットプラットフォームのページサイズを判断するために、pmap(1) または meminfo(2) を使用できます。

A.2.155.2 デフォルト

-xpagesize_stack=default を指定する場合は、Oracle Solaris オペレーティングシステムがページサイズを設定します。

A.2.155.3 警告

-xpagesize_stack オプションは、コンパイル時とリンク時に使用しないかぎり無効です。

A.2.156 `-xpch=v`

このコンパイラオプションは、プリコンパイル済みヘッダー機能を有効にします。プリコンパイル済みヘッダー機能によって、ソースファイルが、大量のソースコードが含まれる一連の共通のインクルードファイルを共有しているアプリケーションのコンパイル時間が短縮される可能性があります。コンパイラは 1 つのソースファイルから一連のヘッダーファイルに関する情報を収集し、そのソースファイルを再コンパイルしたり、同じ一連のヘッダーファイルを持つほかのソースファイルをコンパイルしたりするときにその情報を使用します。コンパイラが収集する情報は、プリコンパイル済みヘッダーファイルに格納されます。この機能を利用するには、-xpch と -xpchstop オプションを、#pragma hdrstop 指令と組み合わせて使用できます。

A.2.156.1 プリコンパイル済みヘッダーファイルの作成

-xpch=v を指定する場合、v には collect:pch-filename または use:pch-filename を指定できます。-xpch を初回に使用するときは、collect モードを指定する必要があります。-xpch=collect を指定するコンパイルコマンドは、ソースファイルを 1 つしか指定できません。次の例では、-xpch オプションがソースファイル a.cc に基づいて myheader.Cpch というプリコンパイル済みヘッダーファイルを作成します。

CC -xpch=collect:myheader a.cc

有効なプリコンパイル済みヘッダーファイル名には、常に .Cpch という接尾辞が含まれます。pch-filename を指定する場合は、その接尾辞を追加するか、またはコンパイラによって追加されるようにすることができます。たとえば、cc -xpch=collect:foo a.cc と指定すると、プリコンパイル済みヘッダーファイルには foo.Cpch という名前が付けられます。

プリコンパイル済みヘッダーファイルを作成する場合、プリコンパイル済みヘッダーファイルを使用するすべてのソースファイルで共通な、一連のインクルードファイルを含むソースファイルを選択します。インクルードファイルの並びは、これらのソースファイル全体で同一でなければいけません。collect モードでは、1 つのソースファイル名だけが有効な値である点に注意してください。たとえば、CC -xpch=collect:foo bar.cc は有効ですが、CC -xpch=collect:foo bar.cc foobar.cc は、2 つのソースファイルを指定しているので無効です。

プリコンパイル済みヘッダーファイルの使用

プリコンパイル済みヘッダーファイルを使用するには、-xpch=use:pch-filename を指定します。プリコンパイル済みヘッダーファイルを作成するために使用されたソースファイルと同じインクルードファイルの並びを持つソースファイルであれば、いくつでも指定できます。たとえば、use モードで、次のようなコマンドがあるとします。CC -xpch=use:foo.Cpch foo.c bar.cc foobar.cc.

既存のプリコンパイル済みヘッダーファイルは、次の状況が当てはまる場合にのみ使用してください。当てはまらない場合は、プリコンパイル済みヘッダーファイルを再作成してください。

プリコンパイル済みヘッダーファイルにアクセスするために使用するコンパイラは、プリコンパイル済みヘッダーファイルを作成したコンパイラと同じであること。あるバージョンのコンパイラによって作成されたプリコンパイル済みヘッダーファイルが、インストール済みのパッチによる違いも含め、別のバージョンのコンパイラでは使用できない可能性があります。
-xpch オプション以外で -xpch=use とともに指定するコンパイラオプションは、プリコンパイル済みヘッダーファイルが作成されたときに指定されたオプションと一致すること。
-xpch=use で指定する一連のインクルードヘッダー群は、プリコンパイル済みヘッダーファイルが作成されたときに指定されたヘッダー群と同じであること。
-xpch=use で指定するインクルードヘッダーの内容が、プリコンパイル済みヘッダーファイルが作成されたときに指定されたインクルードヘッダーの内容と同じであること。
現在のディレクトリ (すなわち、コンパイルが実行中で指定されたプリコンパイル済みヘッダーファイルを使用しようとしているディレクトリ) が、プリコンパイル済みヘッダーファイルが作成されたディレクトリと同じであること。
-xpch=collect で指定したファイル内の前処理指令 (#include 指令を含む) の最初のシーケンスが、-xpch=use で指定したファイル内の前処理指令のシーケンスと同じであること。

プリコンパイル済みヘッダーファイルを複数のソースファイル間で共有するために、これらのソースファイルには、最初のトークンの並びとして一連の同じインクルードファイルを使用していなければいけません。この最初のトークンの並びは、活性文字列 (viable prefix) として知られています。活性文字列は、同じプリコンパイル済みヘッダーファイルを使用するすべてのソースファイル間で一貫して解釈される必要があります。

ソースファイルの活性文字列は、コメントと、次のプリプロセッサ指令のいずれかだけで構成できます。

#include
#if/ifdef/ifndef/else/elif/endif
#define/undef
#ident (if identical, passed through as is)
#pragma (if identical)

これらの指令はいずれかがマクロを参照していてもかまいません。#else、#elif、および #endif 指令は、活性文字列内で一致している必要があります。

プリコンパイル済みヘッダーファイルを共有する各ファイルの活性文字列内では、対応する各 #define 指令と #undef 指令は同じシンボルを参照する必要があります。#define の場合は、それぞれが同じ値を参照する必要があります。各活性文字列内での順序も同じである必要があります。対応する各プラグマも同じで、その順序もプリコンパイル済みヘッダーを共有するすべてのファイルで同じでなければいけません。

プリコンパイル済みヘッダーファイルに組み込まれるヘッダーファイルは、次の制約に違反してはいけません。これらの制限に違反するプログラムをコンパイルした場合、結果は予測できません。

ヘッダーファイルには、関数や変数の定義を含めることはできません。
ヘッダーファイルに、__DATE__ や __TIME__ が含まれていてはいけません。これらのプリプロセッサマクロを使用すると、予測できない結果が生成される場合があります。
ヘッダーファイルに、#pragma hdrstopが含まれていてはいけません。
ヘッダーファイルは、活性文字列内で __LINE__ と __FILE__ を使用できません。インクルードヘッダー内の __LINE__ と __FILE__ を使用できます。

メイクファイルを変更する方法

この節では、-xpch を構築に組み込むためにメイクファイルを変更する場合の考えられるアプローチについて説明します。

make と dmake の KEEP_STATE 機能と CCFLAGS 補助変数を使用すれば、暗黙的な make 規則を使用できます。プリコンパイル済みヘッダーは、個別の独立した手順として生成されます。

.KEEP_STATE:
CCFLAGS_AUX = -O etc
CCFLAGS = -xpch=use:shared $(CCFLAGS_AUX)
shared.Cpch: foo.cc
     $(CCC) -xpch=collect:shared $(CCFLAGS_AUX) foo.cc
a.out: foo.o ping.o pong.o
     $(CCC) foo.o ping.o pong.o

また、CCFLAGS 補助変数を使用する代わりに、独自のコンパイル規則を定義することもできます。

.KEEP_STATE:
.SUFFIXES: .o .cc
%.o:%.cc shared.Cpch
        $(CCC) -xpch=use:shared $(CCFLAGS) -c $<
shared.Cpch: foo.cc
        $(CCC) -xpch=collect:shared $(CCFLAGS) foo.cc -xe
a.out: foo.o ping.o pong.o
        $(CCC) foo.o ping.o pong.o

プリコンパイル済みヘッダーを通常のコンパイルの二次効果として、KEEP_STATE を使用せずに生成することは可能ですが、このアプローチには明示的なコンパイルコマンドが必要です。

shared.Cpch + foo.o: foo.cc bar.h
        $(CCC) -xpch=collect:shared foo.cc $(CCFLAGS) -c
ping.o: ping.cc shared.Cpch bar.h
        $(CCC) -xpch=use:shared ping.cc $(CCFLAGS) -c
pong.o: pong.cc shared.Cpch bar.h
        $(CCC) -xpch=use:shared pong.cc $(CCFLAGS) -c
a.out: foo.o ping.o pong.o
        $(CCC) foo.o ping.o pong.o

A.2.156.2 関連項目

A.2.157 `-xpchstop=file`

-xpch オプションを使用してコンパイル済みヘッダーファイルを作成するときに考慮される最後のインクルードファイルを指定するには、-xpchstop=file オプションを使用します。コマンド行で -xpchstop を使用することは、cc コマンドで指定する各ソースファイル内のファイルを参照する最初のインクルード指令のあとに、hdrstop プラグマを配置することと同じです。

次の例では、-xpchstop オプションで、プリコンパイル済みヘッダーファイルの活性文字列が projectheader.h をインクルードして終わるよう指定してます。したがって、privateheader.h は活性文字列の一部ではありません。

example% cat a.cc
     #include <stdio.h>
     #include <strings.h>
     #include "projectheader.h"
     #include "privateheader.h"
     .
     .
     .
example% CC -xpch=collect:foo.Cpch a.cc -xpchstop=projectheader.h -c

A.2.157.1 関連項目

-xpch、pragma hdrstop

A.2.158 `-xpec[={yes|no}]`

(Solaris のみ) 移植可能な実行可能コード (Portable Executable Code、PEC) バイナリを生成します。このオプションは、プログラム中間表現をオブジェクトファイルとバイナリに入れます。このバイナリは、あとでチューニングやトラブルシューティングのために、使用される場合があります。

-xpec で構築したバイナリは通常、-xpec なしで構築したバイナリより 5 ~ 10 倍の大きさになります。

-xpec を指定しない場合は、-xpec=no に設定されます。-xpec をフラグなしで指定した場合は、コンパイラは xpec を -xpec=yes に設定します。

A.2.159 `-xpg`

gprof プロファイラによるプロファイル処理用にコンパイルします。

-xpg オプションでは、gprof でプロファイル処理するためのデータを収集する自動プロファイルコードをコンパイルします。このオプションを指定すると、プログラムが正常に終了したときに gmon.out を生成する実行時記録メカニズムが呼び出されます。

注 - -xpg を指定した場合は、-xprofile を使用しても利点はありません。これら 2 つは、他方で使用できるデータを生成せず、他方で生成されたデータを使用できません。

プロファイルは、64 ビットの Solaris プラットフォーム上では prof(1) または gprof(1) を使用して、また 32 ビットの Solaris プラットフォーム上では gprof だけを使用して生成され、概略のユーザー CPU 時間が含まれます。これらの時間は、メインの実行可能ファイル内のルーチンと、実行可能ファイルがリンクされるときにリンカー引数として指定された共有ライブラリ内のルーチンの PC サンプルデータから導出されます。そのほかの共有ライブラリ (dlopen(3DL) を使用してプロセスの起動後に開かれたライブラリ) のプロファイルは作成されません。

32 ビットの Solaris システム上では、prof(1) を使用して生成されたプロファイルは実行可能ファイル内のルーチンに制限されます。32 ビット共有ライブラリは、実行可能ファイルを -xpg にリンクし、gprof(1) を使用することによってプロファイリングできます。

x86 システムでは、-xpg には -xregs=frameptr との互換性がないため、これらの 2 つのオプションは同時に使用できません。 -xregs=frameptr は -fast に含まれている点にも注意してください。

Oracle Solaris 10 ソフトウェアには、-p を使用してコンパイルされたシステムライブラリは含まれません。その結果、Solaris 10 プラットフォームで収集されたプロファイルには、システムライブラリルーチンの呼び出し回数が含まれません。

A.2.159.1 警告

コンパイルとリンクを個別に行い、-xpg を使用してコンパイルする場合は、必ず -xpg を使用してリンクしてください。「3.3.3 コンパイル時とリンク時のオプション」に、コンパイル時とリンク時の両方に指定する必要があるオプションの全一覧をまとめています。

gprof プロファイリングのために -xpg でコンパイルされたバイナリは、binopt(1) では使用しないでください。互換性がないため、内部エラーになる可能性があります。

A.2.159.2 関連項目

-xprofile=p、analyzer(1) のマニュアルページ、および『パフォーマンスアナライザ』のマニュアル

A.2.160 `-xport64[=(`v `)]`

このオプションを指定すると、64 ビット環境に移植するコードをデバッグできます。このオプションは、具体的には、V8 などの 32 ビットアーキテクチャーを V9 などの 64 ビットアーキテクチャーにコード移植する際によく見られる、型 (ポインタを含む) の切り捨て、符号の拡張、ビット配置の変更といった問題について警告します。

このオプションは、コンパイルも 64 ビットモード (-m64) で実行していないかぎり無効です。

A.2.160.1 値

次に、v に指定できる値を示します。

表 A-40 -xport64 の値

値	意味
`no`	32 ビット環境から 64 ビット環境へのコードの移植に関連した警告を生成しません。
`implicit`	暗黙の変換に関してのみ警告を生成する。明示的なキャストが存在する場合には警告を生成しない。
`full`	32 ビット環境から 64 ビット環境へのコードの移植に関連したすべての警告を生成します。これには、64 ビット値の切り捨て、ISO 値保護規則に基づく 64 ビットへの符号拡張、およびビットフィールドの配置の変更に対応する警告が含まれます。

A.2.160.2 デフォルト

-xport64 を指定しない場合のデフォルトは、-xport64=no です。-xport64 を指定したが、フラグは指定しない場合、デフォルトは -xport64=full です。

A.2.160.3 例

この節では、型の切り捨て、符号の拡張、およびビット配置の変更の原因になる可能性のあるコードの例について説明します。

64 ビット値の切り捨てのチェック

SPARC V9 などの 64 ビットアーキテクチャーに移植すると、データが切り捨てられる可能性があります。切り捨ては、初期化時に代入によって暗黙的に行われることもあれば、明示的なキャストによって行われることもあります。2 つのポインタの違いは typedef ptrdiff_t であり、32 ビットモードでは 32 ビット整数型、64 ビットモードでは 64 ビット整数型です。大きいサイズから小さいサイズの整数型に切り捨てると、次の例にあるような警告が生成されます。

example% cat test1.c
int x[10];

int diff = &x[10] - &x[5]; //warn

example% CC -c -m64 -Qoption ccfe -xport64=full test1.c
"test1.c", line 3: Warning: Conversion of 64-bit type value to "int" causes truncation.
1 Warning(s) detected.
example%

明示的なキャストがデータ切り捨ての原因である場合に 64 ビットコンパイルモードでの切り捨ての警告を無効にするには、-xport64=implicit を使用します。

example% CC -c -m64 -Qoption ccfe -xport64=implicit test1.c
"test1.c", line 3: Warning: Conversion of 64-bit type value to "int" causes truncation.
1 Warning(s) detected.
example%

64 ビットアーキテクチャーへの移植でよく発生するもう 1 つの問題として、ポインタの切り捨てがあります。これは常に、C++ におけるエラーです。-xport64 を指定した場合は、このような切り捨ての原因となる int へのポインタのキャストなどの操作を行うと、64 ビット SPARC アーキテクチャーではエラー診断が実行されます。

example% cat test2.c
char* p;
int main() {
  p =(char*) (((unsigned int)p) & 0xFF); // -m64 error
  return 0;
}
example% CC -c -m64 -Qoption ccfe -xport64=full test2.c
"test2.c", line 3: Error: Cannot cast from char* to unsigned.
1 Error(s) detected.
example%

符号拡張のチェック

符号なし整数型の式において、通常の ISO C 値保護規則が符号付き整数値の符号拡張に対処している状況があるかどうかを、-xport64 オプションを使用してチェックすることもできます。こういった符号拡張は、実行時に微妙なバグの原因となる可能性があります。

example% cat test3.c
int i= -1;
void promo(unsigned long l) {}

int main() {
    unsigned long l;
    l = i;  // warn
    promo(i);       // warn
}
example% CC -c -m64 -Qoption ccfe -xport64=full test3.c
"test3.c", line 6: Warning: Sign extension from "int" to 64-bit integer.
"test3.c", line 7: Warning: Sign extension from "int" to 64-bit integer.
2 Warning(s) detected.

ビットフィールドの配置変更のチェック

長いビットフィールドに対する警告を生成するには、-xport64 を使用します。こういったビットフィールドが存在していると、ビットフィールドの配置が大きく変わることがあります。ビットフィールド配置方式に関する前提事項に依存しているプログラムを、64 ビットアーキテクチャーに問題なく移植できるためには、あらかじめ確認作業を行う必要があります。

example% cat test4.c
#include <stdio.h>

union U {
   struct S {
       unsigned long b1:20;
       unsigned long b2:20;
   } s;

   long buf[2];
} u;

int main() {
   u.s.b1 = 0XFFFFF;
   u.s.b2 = 0XFFFFF;
   printf(" u.buf[0] = %lx u.buf[1] = %lx\n", u.buf[0], u.buf[1]);
   return 0;
}
example%

64 ビット SPARC システム (-m64) 上の出力:

example% u.buf[0] = ffffffffff000000 u.buf[1] = 0

A.2.160.4 警告

警告が生成されるのは、-m64 を使用して 64 ビットモードでコンパイルした場合だけです。

A.2.160.5 関連項目

「A.2.50 -m32|-m64」

A.2.161 `-xprefetch`[`=a`[`,a`...]]

先読みをサポートするアーキテクチャーで先読み命令を有効にします。

明示的な先読みは、測定値によってサポートされた特殊な環境でのみ使用すべきです。

次の表に、a の指定可能な値を示します。

表 A-41 -xprefetch の値

値	意味
`auto`	先読み命令の自動生成を有効にします。
`no%auto`	先読み命令の自動生成を無効にします。
`explicit`	(SPARC) 明示的な先読みマクロを有効にします。
`no%explicit`	(SPARC) 明示的な先読みマクロを無効にします。
`latx:factor`	指定された factor によってコンパイラで使用されるロードするための先読みと、ストアするための先読みを調整します。このフラグは、`-xprefetch=auto` とのみ組み合わせることができます。係数には必ず正の浮動小数点または整数を指定します。
`yes`	廃止。使用しないでください。代わりに `- xprefetch=auto,explicit` を使用します。
`no`	廃止。使用しないでください。代わりに `-xprefetch=no%auto,no%explicit` を使用します。

-xprefetch および -xprefetch=auto を指定すると、コンパイラは生成するコードに自由に先読み命令を挿入します。その結果、先読みをサポートするアーキテクチャーでパフォーマンスが向上します。

大量の計算を行うコードを大規模なマルチプロセッサ上で実行している場合は、-xprefetch=latx:factor を使用するとパフォーマンスが向上する可能性があります。このオプションは、指定の係数により、先読みからロードまたはストアまでのデフォルトの応答時間を調整するようにコード生成プログラムに指示します。

先読みの応答時間とは、先読み命令を実行してから先読みされたデータがキャッシュで利用可能となるまでのハードウェアの遅延のことです。コンパイラは、先読み命令と先読みされたデータを使用するロードまたはストア命令の距離を決定する際に先読み応答時間の値を想定します。

注 - 先読みからロードまでのデフォルト応答時間は、先読みからストアまでのデフォルト応答時間と同じでない場合があります。

コンパイラは、幅広いマシンとアプリケーションで最適なパフォーマンスを得られるように先読み機構を調整します。しかし、コンパイラの調整作業が必ずしも最適であるとはかぎりません。メモリーに負担のかかるアプリケーション、特に大型のマルチプロセッサでの実行を意図したアプリケーションの場合、先読みの応答時間の値を引き上げることにより、パフォーマンスを向上できます。この値を増やすには、1 よりも大きい係数を使用します。.5 と 2.0 の間の値は、おそらく最高のパフォーマンスを提供します。

外部キャッシュの中に完全に常駐するデータセットを持つアプリケーションの場合は、先読み応答時間の値を減らすことでパフォーマンスを向上できる場合があります。値を減らすには、1 未満の係数を使用します。

-xprefetch=latx:factor オプションを使用するには、1.0 に近い係数の値から始め、アプリケーションに対してパフォーマンステストを実施します。そのあと、テストの結果に応じて係数を増減し、パフォーマンステストを再実行します。係数の調整を継続し、最適なパフォーマンスに到達するまでパフォーマンステストを実行します。係数を小刻みに増減すると、しばらくはパフォーマンスに変化がなく、突然変化し、再び平常に戻ります。

A.2.161.1 デフォルト

デフォルトは -xprefetch=auto,explicit です。基本的に非線形のメモリーアクセスパターンを持つアプリケーションには、このデフォルトが良くない影響をもたらします。デフォルトを無効にするには、-xprefetch=no%auto,no%explicit を指定します。

no%auto か no の引数で明示的にオーバーライドされない限り、デフォルト auto が想定されます。たとえば、-xprefetch=explicit は -xprefetch=explicit,auto と同じことです。

デフォルト explicit は、引数に no%explicit か no を指定して明示的に無効にするまで継続されます。たとえば、-xprefetch=auto は -xprefetch=auto,explicit と同じことです。

-xprefetch だけを指定すると、-xprefetch=auto,explicit が使用されます。

自動先読みを有効にしても、応答時間係数を指定しないと、-xprefetch=latx:1.0 が想定されます。

A.2.161.2 相互の関連性

このオプションは、置き換えられる代わりに蓄積されます。

sun_prefetch.h ヘッダーファイルには、明示的な先読み命令を指定するためのマクロが含まれています。先読み命令は、実行コード中のマクロの位置にほぼ相当するところに挿入されます。

明示的な先読み命令を使用するには、使用するアーキテクチャーが適切なもので、sun_prefetch.h をインクルードし、かつコンパイラコマンドに -xprefetch が指定されていないか、-xprefetch、-xprefetch=auto,explicit、あるいは -xprefetch=explicit が指定されていなければいけません。

マクロを呼び出し、sun_prefetch.h ヘッダーファイルをインクルードしていても、-xprefetch=no%explicit を指定した場合は、明示的な先読みが実行可能ファイル内に組み込まれません。

latx:factor の使用は、自動先読みが有効になっている場合にのみ有効です。latx:factor は、-xprefetch=auto,latx:factor とともに使用していないかぎり無視されます。

A.2.161.3 警告

明示的な先読みは、測定方法によってサポートされる特殊な環境でのみ使用してください。

コンパイラは、幅広いマシンやアプリケーションにわたって最適なパフォーマンスを得るために先読みメカニズムを調整するため、-xprefetch=latx:factor は、パフォーマンステストで明らかな利点があることが示された場合にのみ使用してください。想定される先読みの応答時間は、リリースごとに変更される可能性があります。したがって、別のリリースに切り替えたら、その都度応答時間係数の影響を再テストすることを推奨します。

A.2.162 `-xprefetch_auto_type=` `a`

ここで a は [no%]indirect_array_access です。

このオプションは、コンパイラが -xprefetch_level オプションで示されたループのための間接先読みを、直接メモリーアクセスのための先読みが生成されるのと同じ方法で生成するかどうかを決定するために使用します。

-xprefetch_auto_type の値が指定されていない場合、-xprefetch_auto_type=no%indirect_array_access に設定されます。

-xdepend、-xrestrict、および -xalias_level などのオプションは、メモリー別名を明確化する情報の生成に役立つため、間接先読み候補の計算の攻撃性に影響し、このため、自動的な間接先読みの挿入が促進されることがあります。

A.2.163 `-xprefetch_level`[`=i`]

-xprefetch_level=i オプションを使用して、-xprefetch=auto で決定した先読み命令の自動挿入の攻撃性を調整することができます。コンパイラは、-xprefetch_level のレベルが高くなるたびに、より積極的になります。つまり、より多くの先読みを導入します。

-xprefetch_level に適した値は、アプリケーションでのキャッシュミス数によって異なります。-xprefetch_level の値を高くするほど、キャッシュミスが多いアプリケーションの性能が向上する可能性が高くなります。

A.2.163.1 値

i は、次の表に示す 1、2、3 のいずれかである必要があります。

表 A-42 -xprefetch_level の値

値	意味
`1`	先読み命令の自動的な生成を有効にします。
`2`	`-xprefetch_level=1` の対象以外にも、先読み挿入対象のループを追加します。`-xprefetch_level=1.` にある先読み以外に、追加の先読みを挿入できます。
`3`	`-xprefetch_level=2` の対象以外にも、先読み挿入対象のループを追加します。`-xprefetch_level=2` にある先読み以外に、追加の先読みを挿入できます。

A.2.163.2 デフォルト

デフォルトは、-xprefetch=auto を指定した場合は -xprefetch_level=1 になります。

A.2.163.3 相互の関連性

このオプションは、-xprefetch=auto を使用して、3 以上の最適化レベル (-xO3) で、かつ先読みをサポートする 64 ビット SPARC プラットフォーム (-m64) 上でコンパイルされた場合にのみ有効です。

A.2.164 `–xprofile=p`

プロファイルのデータを収集したり、プロファイルを使用して最適化したりします。

p には、collect[ :profdir]、use[ :profdir]、または tcov[ :profdir] を指定する必要があります。

このオプションを指定すると、実行頻度のデータが収集されて実行中に保存されます。このデータを以降の実行で使用すると、パフォーマンスを向上させることができます。プロファイルの収集は、マルチスレッド対応のアプリケーションにとって安全です。独自のマルチタスク (-mt) を実行するプログラムのプロファイリングによって、正確な結果が生成されます。このオプションは、最適化レベルを -xO2 かそれ以上に指定するときにのみ有効になります。コンパイルとリンクを別々の手順で実行する場合は、リンク手順とコンパイル手順の両方で同じ -xprofile オプションを指定する必要があります。

collect[:profdir ]

実行頻度のデータを集めて保存します。のちに -xprofile=use を指定した場合にオプティマイザがこれを使用します。コンパイラによって文の実行頻度を測定するためのコードが生成されます。

-xMerge、-ztext、および -xprofile=collect を一緒に使用しないでください。-xMerge を指定すると、静的に初期化されたデータを読み取り専用記憶領域に強制的に配置します。 -ztext を指定すると、位置に依存するシンボルを読み取り専用記憶領域内で再配置することを禁止します。-xprofile=collect を指定すると、書き込み可能記憶領域内で、静的に初期化された、位置に依存するシンボルの再配置を生成します。

プロファイルディレクトリ名として profdir を指定すると、この名前が、プロファイル化されたオブジェクトコードを含むプログラムまたは共有ライブラリの実行時にプロファイルデータが保存されるディレクトリのパス名になります。profdir パス名が絶対パスではない場合、プログラムがオプション -xprofile=use:profdir でコンパイルされるときの現在の作業用ディレクトリの相対パスとみなされます。

—xprofile=collect: prof_dir または —xprofile=tcov: prof_dir でプロファイルディレクトリ名を指定しない場合、プロファイルデータは実行時に、program.profile という名前のディレクトリに保存されます (program はプロファイリングされたプロセスのメインプログラムのベース名)。この場合は、環境変数 SUN_PROFDATA および SUN_PROFDATA_DIR を使用して、実行時にプロファイルデータが保存される場所を制御できます。設定する場合、プロファイルデータは $SUN_PROFDATA_DIR/$SUN_PROFDATA で指定されたディレクトリに書き込まれます。プロファイルディレクトリ名がコンパイル時に指定されても、実行時に SUN_PROFDATA_DIR および SUN_PROFDATA の効果はありません。これらの環境変数は、tcov で書き込まれるプロファイルデータファイルのパスと名前を同様に制御します。tcov(1) マニュアルページを参照してください。

これらの環境変数が設定されていない場合、プロファイルデータは現在のディレクトリ内のディレクトリ profdir.profile に書き込まれます (profdir は実行可能ファイルの名前または -xprofile=collect: profdir フラグで指定される名前)。profdir がすでに .profile で終わっている場合、-xprofile は .profile を profdir に追加しません。プログラムを複数回実行すると、実行頻度データは profdir.profile ディレクトリに蓄積されていくので、以前の実行頻度データは失われません。

別々の手順でコンパイルしてリンクする場合は、-xprofile=collect を指定してコンパイルしたオブジェクトファイルは、リンクでも必ず -xprofile=collect を指定してください。

次の例では、プログラムが構築されたディレクトリと同じディレクトリ内にある myprof.profile ディレクトリ内のプロファイルデータを収集して使用します。

demo: CC -xprofile=collect:myprof.profile -xO5 prog.cc -o prog  
demo: ./prog        
demo: CC -xprofile=use:myprof.profile -xO5 prog.cc -o prog

次の例では、/bench/myprof.profile ディレクトリ内のプロファイルデータを収集し、収集したプロファイルデータをあとでフィードバックコンパイルで最適化レベル -xO5 で使用します。

demo: CC -xprofile=collect:/bench/myprof.profile \ -xO5 prog.cc -o prog  
...run prog from multiple locations..
demo: CC -xprofile=use:/bench/myprof.profile \ -xO5 prog.cc -o prog

use[:profdir ]

プロファイリングされたコードが実行されたときに実行された作業のために最適化するときは、—xprofile=collect[: profdir] または —xprofile=tcov[: profdir] でコンパイルされたコードから収集された実行頻度データを使用します。profdir は、—xprofile=collect[: profdir] または —xprofile=tcov[: profdir] でコンパイルされたプログラムを実行して収集されたプロファイルデータを含むディレクトリのパス名です。

tcov と —xprofile=use[:profdir の両方で使用できるデータを生成するには、 —xprofile=tcov[:profdir] オプションを使用して、コンパイル時にプロファイルディレクトリを指定する必要があります。—xprofile=tcov: profdir と —xprofile=use: profdir の両方で同じプロファイルディレクトリを指定する必要があります。混乱を最小限に抑えるには、profdir を絶対パス名として指定します。

profdir パス名は省略可能です。 profdir が指定されていない場合、実行可能バイナリの名前が使用されます。-o が指定されていない場合、a.out が使用されます。 profdir が指定されていない場合、コンパイラは、profdir .profile/feedback、または a.out.profile/feedback を探します。例:

demo: CC -xprofile=collect -o myexe prog.cc  
demo: CC -xprofile=use:myexe -xO5 -o myexe prog.cc

-xprofile=collect オプションを付けてコンパイルしたときに生成され、プログラムの前の実行で作成されたフィードバックファイルに保存された実行頻度データを使用して、プログラムが最適化されます。

-xprofile オプションを除き、ソースファイルおよびコンパイラのほかのオプションは、フィードバックファイルを生成したコンパイル済みプログラムのコンパイルに使用したものと完全に同一のものを指定する必要があります。同じバージョンのコンパイラは、収集構築と使用構築の両方に使用する必要があります。

-xprofile=collect:profdir を付けてコンパイルした場合は、-xprofile=use: profdir のコンパイルの最適化に同じプロファイルディレクトリ名 profdir を使用する必要があります。

収集 (collect) 段階と使用 (use) 段階の間のコンパイル速度を高める方法については、-xprofile_ircache も参照してください。

tcov[:profdir ]

tcov(1) を使用する基本のブロックカバレッジ分析用の命令オブジェクトファイル。

オプションの profdir 引数を指定すると、コンパイラは指定された場所にプロファイルディレクトリを作成します。プロファイルディレクトリに保存されたデータは、tcov(1) または -xprofile=use:profdir を付けたコンパイラで使用できます。オプションの profdir パス名を省略すると、プロファイル化されたプログラムの実行時にプロファイルディレクトリが作成されます。プロファイルディレクトリに保存されたデータは、tcov(1) でのみ使用できます。プロファイルディレクトリの場所は、環境変数 SUN_PROFDATA および SUN_PROFDATA_DIR を使用して指定できます。

profdir で指定された場所が絶対パス名でない場合は、コンパイル時に、コンパイルの時点での現在の作業用ディレクトリの相対パスであると解釈されます。いずれかのオブジェクトファイルに対して profdir が指定されている場合は、同じプログラム内のすべてのオブジェクトファイルに対して同じ場所を指定する必要があります。場所が profdir で指定されているディレクトリには、プロファイル化されたプログラムを実行するときにすべてのマシンからアクセスできる必要があります。プロファイルディレクトリはその内容が必要なくなるまで削除できません。コンパイラでプロファイルディレクトリに保存されたデータは、再コンパイルする以外復元できません。

1 つ以上のプログラムのオブジェクトファイルが -xprofile=tcov:/test/profdata を使用してコンパイルされた場合は、/test/profdata.profile という名前のディレクトリがコンパイラによって作成され、プロファイリングされたオブジェクトファイルを表すデータを格納するために使用されます。実行時に同じディレクトリを使用して、プロファイル化されたオブジェクトファイルに関連付けられた実行データを保存できます。

myprog という名前のプログラムが -xprofile=tcov を使用してコンパイルされ、ディレクトリ /home/joe 内で実行された場合は、実行時にディレクトリ /home/joe/myprog.profile が作成され、実行時プロファイルデータを格納するために使用されます。

A.2.165 `-xprofile_ircache`[ `=path`]

(SPARC のみ) collect 段階で保存されたコンパイルデータを再利用することによって use 段階のコンパイル時間を改善するには、-xprofile_ircache[= path] を -xprofile=collect| use とともに使用します。

大きなプログラムでは、中間データが保存されるため、use 段階のコンパイル時間の効率を大幅に向上させることができます。保存されたデータが必要なディスク容量を相当増やすことがある点に注意してください。

-xprofile_ircache[=path] を使用すると、path はキャッシュファイルが保存されているディレクトリを上書きします。デフォルトでは、これらのファイルはオブジェクトファイルと同じディレクトリに保存されます。collect と use 段階が 2 つの別のディレクトリで実行される場合は、パスを指定しておくと便利です。次の例は一般的なコマンドシーケンスを示します。

example% CC -xO5 -xprofile=collect -xprofile_ircache t1.cc t2.cc
example% a.out // run collects feedback data
example% CC -xO5 -xprofile=use -xprofile_ircache t1.cc t2.cc

A.2.166 `-xprofile_pathmap`

(SPARC のみ) -xprofile=use コマンドも指定する場合は、-xprofile_pathmap= collect-prefix:use-prefix オプションを使用します。次の両方の条件が当てはまり、かつコンパイラが -xprofile=use を使用してコンパイルされたオブジェクトファイルのプロファイルデータを見つけることができない場合は、-xprofile_pathmap を使用します。

前回オブジェクトファイルが -xprofile=collect でコンパイルされたディレクトリとは異なるディレクトリで、オブジェクトファイルを -xprofile=use を指定してコンパイルしている。
オブジェクトファイルはプロファイルで共通ベース名を共有しているが、異なるディレクトリのそれぞれの位置で相互に識別されている。

collect-prefix は、オブジェクトファイルが -xprofile=collect を使用してコンパイルされたときのディレクトリツリーの UNIX パス名の接頭辞です。

use-prefix は、オブジェクトファイルが -xprofile=use を使用してコンパイルされるディレクトリツリーの UNIX パス名の接頭辞です。

-xprofile_pathmap の複数のインスタンスを指定すると、コンパイラは指定した順序でインスタンスを処理します。-xprofile_pathmap のインスタンスで指定された各 use-prefix は、一致する use-prefix が識別されるか、または最後に指定された use-prefix がオブジェクトファイルのパス名に一致しないことが確認されるまで、オブジェクトファイルのパス名と比較されます。

A.2.167 `-xreduction`

自動的な並列化を実行するときにループの縮約を解析します。このオプションは、-xautopar が指定する場合のみ有効です。それ以外の場合は、コンパイラは警告を発行します。

縮約の認識が有効になっている場合、コンパイラは内積、最大値発見、最小値発見などの縮約を並列化します。これらの縮約によって非並列化コードによる四捨五入の結果と異なります。

A.2.168 `-xregs=r`[`,r`...]

生成コード用のレジスタの使用法を指定します。

r には、appl、float、frameptr サブオプションのいずれか 1 つ以上をコンマで区切って指定します。

サブオプションの前に no% を付けるとそのサブオプションは無効になります。例: -xregs=appl,no%float

—xregs サブオプションは、特定のハードウェアプラットフォームでしか使用できません。

表 A-43 -xregs のサブオプション

値	意味
`appl`	(SPARC) コンパイラがアプリケーションレジスタをスクラッチレジスタとして使用してコードを生成することを許可します。アプリケーションレジスタは次のとおりです。 g2、g3、g4 ( 32 ビットプラットフォーム) g2、g3 (64 ビットプラットフォーム) すべてのシステムソフトウェアとライブラリを `-xregs=no%appl` を使用してコンパイルしてください。システムソフトウェア (共有ライブラリを含む) は、アプリケーション用のレジスタの値を保持する必要があります。これらの値は、コンパイルシステムによって制御されるもので、アプリケーション全体で整合性が確保されている必要があります。 SPARC ABI では、これらのレジスタはアプリケーションレジスタと記述されています。これらのレジスタを使用すると必要なロードおよびストア命令が少なくてすむため、パフォーマンスが向上します。ただし、アセンブリコードで記述された古いライブラリプログラムとの間で衝突が起きることがあります。
`float`	(SPARC) コンパイラが浮動小数点レジスタを整数値用のスクラッチレジスタとして使用してコードを生成することを許可します。浮動小数点値を使用する場合は、このオプションとは関係なくこれらのレジスタを使用します。浮動小数点レジスタへのすべての参照をコードからなくす場合は、`-xregs=no%float` を使用するとともに、コードで浮動小数点型をどのような方法でも使用しないようにする必要があります。
`frameptr`	(x86 のみ) コンパイラでフレームポインタレジスタ (IA32 上では `%ebp`、AMD64 上では `%rbp`) を汎用レジスタとして使用できるようにします。デフォルトは `-xregs=no%frameptr` です。 `—features=no%except` によって例外も無効になっているのでなければ、C++ コンパイラは `—xregs=frameptr` を無視します。`-xregs=frameptr` は `-fast` の一部ですが、`-features=no%except` も同時に指定されないかぎり C++ コンパイラによって無視されます。 `-xregs=framptr` を使用すると、コンパイラは浮動小数点レジスタを自由に使用できるので、プログラムのパフォーマンスが向上します。ただし、この結果としてデバッガおよびパフォーマンス測定ツールの一部の機能が制限される場合があります。スタックトレース、デバッガ、およびパフォーマンスアナライザは、`—xregs=frameptr` を使用してコンパイルされた機能についてレポートできません。さらに、Posix `pthread_cancel()` の C++ 呼び出しは、クリーンアップハンドラの検索に失敗します。 C または Fortran 関数から直接または間接的に呼び出された C++ 関数が例外をスローする可能性がある場合は、C、Fortran、および C++ が混在したコードを `-xregs=frameptr` を使用してコンパイルしてはいけません。このような言語が混在するソースコードを `—fast` でコンパイルする場合は、コマンド行の `—fast` オプションのあとに `—xregs=no%frameptr` を追加します。 64 ビットのプラットフォームでは利用できるレジスタが多いため、`—xregs=frameptr` でコンパイルすると、64 ビットコードよりも 32 ビットコードのパフォーマンスが向上する可能性が高くなります。 `-xpg` も指定されている場合、コンパイラは `-xregs=frameptr` を無視し、警告を表示します。また、`-xkeepframe` によって `-xregs=frameptr` が上書きされます。

SPARC のデフォルトは -xregs=appl,float です。

x86 のデフォルトは -xregs=no%frameptr です。

アプリケーションにリンクする共有ライブラリを目的に作成されたコードは、-xregs=no%appl,float を使用してコンパイルしてください。少なくとも、共有ライブラリとリンクするアプリケーションがこれらのレジスタの割り当てを認識するように、共有ライブラリがアプリケーションレジスタを使用する方法を明示的に示す必要があります。

たとえば、大局的な方法で (重要なデータ構造体を示すためにレジスタを使用するなど) レジスタを使用するアプリケーションは、ライブラリと確実にリンクするため、-xregs=no%appl なしでコンパイルされたコードを含むライブラリがアプリケーションレジスタをどのように使用するかを正確に特定する必要があります。

A.2.169 `-xrestrict`[`=` `f`]

ポインタ値の関数パラメータを制限付きポインタとして扱います。f は、次の表に示されている値のいずれかである必要があります。

表 A-44 -xrestrict の値

値	意味
`%all`	ファイル全体のすべてのポインタ型引数を制限付きとして扱います。
`%none`	ファイル内のどのポインタ型引数も制限付きとして扱いません。
`%source`	メインソースファイル内に定義されている関数のみ制限付きにします。インクルードファイル内に定義されている関数は制限付きにしません。
`fn`[,`fn`...]	1 つ以上の関数名のコンマ区切りのリスト。関数リストが指定された場合は、指定された関数内のポインタ型引数を制限付きとして扱います。詳細については、次の「A.2.169.1 制限付きポインタ」を参照してください。

このコマンド行オプションは独立して使用できますが、最適化時に使用するのがもっとも適しています。

たとえば、次のコマンドは、ファイル prog.c 内のすべてのポインタパラメータを制限付きポインタとして扱います。

%CC -xO3 -xrestrict=%all prog.cc

次のコマンドは、ファイル prog.c 内の関数 agc 内のすべてのポインタパラメータを制限付きポインタとして扱います。

%CC -xO3 -xrestrict=agc prog.cc

C プログラミング言語の C99 標準では restrict キーワードが導入されましたが、このキーワードは現在の C++ 標準に含まれていません。一部のコンパイラでは、C99 の restrict キーワードのための C++ 言語拡張が適用されており、__restrict または __restrict__ とも表記されます。ただし、Oracle Solaris Studio の C++ コンパイラには現在、この拡張はありません。-xrestrict オプションは、ソースコードで restrict キーワードを部分的に置き換えます。(このキーワードを使用しても、関数のすべてのポインタ引数を restrict と宣言する必要があるわけではありません。)このキーワードは、主に最適化の機会に影響を与え、関数に渡すことができる引数を制限します。ソースコードから restict または __restrict のすべてのインスタンスを削除しても、プログラムの見た目の動作には影響しません。

デフォルトは %none で、-xrestrict と指定すると -xrestrict=%sourcel と指定した場合と同様の結果が得られます。

A.2.169.1 制限付きポインタ

コンパイラが効率よくループを並列化できるようにするには、左辺値が記憶領域の特定の領域を示している必要があります。別名とは、記憶領域の決まった位置を示していない左辺値のことです。オブジェクトへの 2 個のポインタが別名であるかどうかを判断することは困難です。これを判断するにはプログラム全体を解析することが必要であるため、非常に時間がかかります。次の例にある関数 vsq() について考えてみます。

extern "C"
void vsq(int n, double *a, double *b) {
    int i;
    for (i=0; i<n; i++) {
            b[i] = a[i] * a[i];
    }
}

ポインタ a および b が異なるオブジェクトをアクセスすることをコンパイラが知っている場合には、ループ内の異なる繰り返しを並列に実行することができます。しかし、ポインタ a および b でアクセスされるオブジェクトが重なりあっていれば、ループを安全に並列実行できなくなります。

コンパイル時に、コンパイラは、関数 vsq() を単純に解析しても a と b でアクセスされるオブジェクトが重なりあっているかどうかを知ることはできません。コンパイラがこの情報を得るために、プログラム全体の解析が必要になることがあります。コマンド行オプション -xrestrict[= func1,...,funcn] を使用して、ポインタ値の関数パラメータを制限付きポインタとして扱うように指定できます。関数リストが指定されている場合は、指定された関数内のポインタパラメータが制限付きとして扱われます。それ以外の場合は、ソースファイル全体にあるすべてのポインタパラメータが制限付きとして扱われます (推奨されません)。たとえば、-xrestrict=vsq を使用すると、関数 vsq() についての例では、ポインタ a および b が修飾されます。

ポインタ引数を制限付きとして宣言する場合は、ポインタが個別のオブジェクトを指定すると明示することになります。コンパイラは、a および b が個別の記憶領域を指していると想定します。この別名情報によって、コンパイラはループの並列化を実行することができます。

-xrestrict は正しく使用するようにしてください。区別できないオブジェクトを指しているポインタを制限付きポインタにしてしまうと、ループを正しく並列化できなくなり、不定な動作をすることになります。たとえば、b[i] と a[i+1] が同じオブジェクトである場合のように、関数 vsq() のポインタ a と b が重なりあっているオブジェクトを指しているとします。このとき a および b が制限付きポインタとして宣言されていなければ、ループは順次実行されます。a と b が誤って制限付きポインタとして修飾された場合、コンパイラはループの実行を並列化する可能性があります。b[i+1] は b[i] が計算されたあとでのみ計算されるべきであるため、これは安全ではありません。

A.2.170 `-xs`

オブジェクト (.o) ファイルなしに dbx でデバッグできるようにします。

このオプションを指定すると、すべてのデバッグ情報が実行可能ファイルにコピーされます。このオプションは、dbx のパフォーマンスやプログラムの実行時のパフォーマンスにほとんど影響を与えませんが、取得するディスク容量は増えます。

このオプションは、-xdebugformat=stabs で指定した場合だけ影響があります。この場合のデフォルトは、デバッグデータを実行可能ファイルにコピーしません。デフォルトのデバッグ形式である -xdebugformat=dwarf を使用する場合は、デバッグデータは常に実行可能ファイルにコピーされます。コピーを防止するオプションはありません。

A.2.171 `-xsafe=mem`

(SPARC のみ) メモリー保護違反が発生しないことをコンパイラで想定できるようにします。

このオプションを使用すると、コンパイラでは SPARC V6 アーキテクチャーで違反のないロード命令を使用できます。

A.2.171.1 相互の関連性

このオプションは、最適化レベルの -xO5 と、次のいずれかの値の -xarch を組み合わせた場合にだけ有効です。m32 と m64 の両方で sparc、sparcvis、-sparcvis2、または -sparcvis3。

A.2.171.2 警告

アドレスの位置合わせが合わない、またはセグメンテーション侵害などの違反が発生した場合は違反のないロードはトラップを引き起こさないので、このオプションはこのような違反が起こる可能性のないプログラムでしか使用しないでください。ほとんどのプログラムではメモリーに関するトラップは起こらないので、大多数のプログラムでこのオプションを安全に使用できます。例外条件の処理にメモリーベースのトラップを明示的に使用するプログラムでは、このオプションは使用しないでください。

A.2.172 `-xspace`

SPARC: コードサイズが大きくなるような最適化を行いません。

A.2.173 `-xtarget=t`

命令セットと最適化処理の対象システムを指定します。

コンパイラにハードウェアシステムを正確に指定すると、プログラムによってはパフォーマンスが向上します。プログラムのパフォーマンスが重要な場合は、対象となるハードウェアを正確に指定してください。これは特に、新しい SPARC プロセッサ上でプログラムを実行する場合に当てはまります。しかし、ほとんどのプログラムおよび旧式の SPARC システムではパフォーマンスの向上はわずかであるため、汎用的な指定方法で十分です。

t には次の値のいずれかを指定します。native、generic、native64、 generic64、system-name。

-xtarget に指定する値は、-xarch、-xchip、-xcache の各オプションの値に展開されます。実行中のシステムで -xtarget=native の展開を調べるには、-xdryrun コマンドを使用します。

たとえば、-xtarget=ultraT2 は次のものと同等です: -xarch=sparcvis2 -xchip=ultraT2 -xcache=8/16/4:4096/64/16

注 - 特定のホストプラットフォームで -xtarget を展開した場合、そのプラットフォームでコンパイルすると -xtarget=native と同じ -xarch、-xchip、または -xcache 設定にならない場合があります。

A.2.173.1 プラットフォームごとの -xtarget の値

この節では、—xtarget 値をプラットフォームごとに説明します。次の表は、すべてのプラットフォーム向けの —xtarget の値を一覧表示します。

表 A-45 すべてのプラットフォームでの -xtarget の値

値	意味
`native`	次と同等です。 `—m32 —xarch=native —xchip=native —xcache=native` ホスト 32 ビットシステムに最高のパフォーマンスを与えます。
`native64`	次と同等です。 `—m64 —xarch=native64 —xchip=native64 —xcache=native64` ホスト 64 ビットシステムに最高のパフォーマンスを与えます。
`generic`	次と同等です。 `—m32 —xarch=generic —xchip=generic —xcache=generic` ほとんどの 32 ビットシステムに最高のパフォーマンスを与えます。
`generic64`	次と同等です。 `—m64 —xarch=generic64 —xchip=generic64 —xcache=generic64` ほとんどの 64 ビットシステムに最高のパフォーマンスを与えます。
`system-name`	指定するシステムで最高のパフォーマンスが得られます。対象となる実際のシステムを表すシステム名を、次のリストから選択してください。

SPARC プラットフォームの `-xtarget` の値

SPARC または UltraSPARC V9 での 64 ビット Solaris ソフトウェアのコンパイルは、-m64 オプションで指定します。-xtarget を native64 または generic64 以外のフラグとともに指定する場合は、-xtarget=ultra ... -m64 のように、-m64 オプションも指定する必要があります。それ以外の場合、コンパイラは 32 ビットメモリーモデルを使用します。

表 A-46 SPARC アーキテクチャーでの -xtarget の展開

-xtarget=	-xarch	-xchip	-xcache
`ultra`	`sparcvis`	`ultra`	`16/32/1:512/64/1`
`ultra1/140`	`sparcvis`	`ultra`	`16/32/1:512/64/1`
`ultra1/170`	`sparcvis`	`ultra`	`16/32/1:512/64/1`
`ultra1/200`	`sparcvis`	`ultra`	`16/32/1:512/64/1`
`ultra2`	`sparcvis`	`ultra2`	`16/32/1:512/64/1`
`ultra2/1170`	`sparcvis`	`ultra`	`16/32/1:512/64/1`
`ultra2/1200`	`sparcvis`	`ultra`	`16/32/1:1024/64/1`
`ultra2/1300`	`sparcvis`	`ultra2`	`16/32/1:2048/64/1`
`ultra2/2170`	`sparcvis`	`ultra`	`16/32/1:512/64/1`
`ultra2/2200`	`sparcvis`	`ultra`	`16/32/1:1024/64/1`
`ultra2/2300`	`sparcvis`	`ultra2`	`16/32/1:2048/64/1`
`ultra2e`	`sparcvis`	`ultra2e`	`16/32/1:256/64/4`
`ultra2i`	`sparcvis`	`ultra2i`	`16/32/1:512/64/1`
`ultra3`	`sparcvis2`	`ultra3`	`64/32/4:8192/512/1`
`ultra3cu`	`sparcvis2`	`ultra3cu`	`64/32/4:8192/512/2`
`ultra3i`	`sparcvis2`	`ultra3i`	`64/32/4:1024/64/4`
`ultra4`	`sparcvis2`	`ultra4`	`64/32/4:8192/128/2`
`ultra4plus`	`sparcvis2`	`ultra4plus`	`64/32/4:2048/64/4:32768/64/4`
`ultraT1`	`sparcvis2`	`ultraT1`	`8/16/4/4:3072/64/12/32`
`ultraT2`	`sparc`	`ultraT2`	`8/16/4:4096/64/16`
`ultraT2plus`	`sparcvis2`	`ultraT2plus`	`8/16/4:4096/64/16`
`T3`	`sparcvis3`	`T3`	`8/16/4:6144/64/24`
`T4`	`sparc4`	`T4`	`16/32/4:128/32/8:4096/64/16`
`sparc64vi`	`sparcfmaf`	`sparc64vi`	`128/64/2:5120/64/10`
`sparc64vii`	`sparcima`	`sparc64vii`	`64/64/2:5120/256/10`
`sparc64viiplus`	`sparcima`	`sparc64viiplus`	`64/64/2:11264/256/11`

x86 プラットフォーム上の -xtarget の値

64 ビット x86 プラットフォームでの 64 ビット Solaris ソフトウェアのコンパイルは、-m64 オプションで指定します。native64 または generic64 以外のフラグで -xtarget を指定する場合は、-m64 オプションも次のように指定する必要があります: -xtarget=opteron ... -m64。それ以外の場合、コンパイラは 32 ビットメモリーモデルを使用します。

表 A-47 x86 プラットフォームでの -xtarget の値

-xtarget=	-xarch	-xchip	-xcache
`opteron`	`sse2`	`opteron`	`64/64/2:1024/64/16`
`pentium`	`386`	`pentium`	`generic`
`pentium_pro`	`pentium_pro`	`pentium_pro`	`generic`
`pentium3`	`sse`	`pentium3`	`16/32/4:256/32/4`
`pentium4`	`sse2`	`pentium4`	`8/64/4:256/128/8`
`nehalem`	`sse4_2`	`nehalem`	`32/64/8:256/64/8:` `8192/64/16`
`penryn`	`sse4_1`	`penryn`	`2/64/8:4096/64/16`
`woodcrest`	`ssse3`	`core2`	`32/64/8:4096/64/16`
`barcelona`	`amdsse4a`	`amdfam10`	`64/64/2:512/64/16`
`sandybridge`	`avx`	`sandybridge`	`32/64/8:256/64/8:8192/64/16`
`westmere`	`aes`	`westmere`	`32/64/8:256/64/8:12288/64/16`

A.2.173.2 デフォルト

SPARC および x86 で、-xtarget を指定しないと、-xtarget=generic が想定されます。

A.2.173.3 展開

-xtarget オプションは、市販で購入したプラットフォーム上で使用する -xarch、-xchip、-xcache の組み合わせを素早く、簡単に指定するためのマクロです。-xtarget の意味は = のあとに指定した値を展開したものにあります。

A.2.173.4 例

-xtarget=ultra は、-xchip=ultra -xcache=16/32/1:512/64/1 -xarch=sparcvis を示します。

A.2.173.5 相互の関連性

-m64 オプションで示された 64 ビット SPARC V9 アーキテクチャー用のコンパイル。-xtarget=ultra または ultra2 の設定は必要でないか、または十分ではありません。-xtarget が指定されている場合は、-xarch、-xchip、または -xcache 値のすべての変更を -xtarget のあとに指定する必要があります。例:

–xtarget=ultra3 -xarch=ultra

A.2.173.6 警告

別々の手順でコンパイルしてリンクする場合は、コンパイル手順とリンク手順で同じ -xtarget の設定値を使用する必要があります。

A.2.174 `-xthreadvar`[`=` o]

スレッドローカルな変数の実装を制御するには -xthreadvar を指定します。コンパイラのスレッドローカルな記憶機能を利用するには、このオプションを __thread 宣言指定子と組み合わせて使用します。__thread 指示子を使用してスレッド変数を宣言したあとは、-xthreadvar を指定することにより、動的 (共有) ライブラリ内の位置依存コード (PIC 以外のコード) でスレッドローカルな記憶領域を使用できるようにします。__thread の使用方法についての詳細は、「4.2 スレッドローカルな記憶装置」を参照してください。

A.2.174.1 値

次の表に、o の指定可能な値を示します。

表 A-48 -xthreadvar の値

値	意味
`[no%]dynamic`	動的ロード用の変数をコンパイルします。`-xthreadvar=no%dynamic` を指定すると、スレッド変数へのアクセスは非常に早くなりますが、動的ライブラリ内のオブジェクトファイルは使用できません。すなわち、実行可能ファイル内のオブジェクトファイルだけが使用可能です。

A.2.174.2 デフォルト

-xthreadvar を指定しない場合、コンパイラが使用するデフォルトは位置独立コード (PIC) が有効になっているかどうかによって決まります。位置独立コードが有効になっている場合、オプションは -xthreadvar=dynamic に設定されます。位置独立コードが無効になっている場合、オプションは -xthreadvar=no%dynamic に設定されます。

引数を指定しないで -xthreadvar を指定する場合、オプションは -xthreadvar=dynamic に設定されます。

A.2.174.3 相互の関連性

-mt オプションは、__thread を使用しているファイルのコンパイルおよびリンクを実行するときに指定する必要があります。

A.2.174.4 警告

動的ライブラリに位置独立でないコードが含まれている場合は、-xthreadvar を指定する必要があります。

リンカーは、動的ライブラリ内の位置依存コード (非 PIC) スレッド変数と同等のスレッド変数はサポートできません。非 PIC スレッド変数は非常に高速なため、実行可能ファイルのデフォルトとして指定できます。

A.2.174.5 関連項目

-xcode、-KPIC、-Kpic

A.2.175 `–xtime`

CC ドライバが、さまざまなコンパイル過程の実行時間を報告します。

A.2.176 `-xtrigraphs`[`=`{ `yes`|`no`}]

ISO/ANSI C 標準の定義に従って文字表記シーケンスの認識を有効または無効にします。

コンパイラが文字表記シーケンスとして解釈している疑問符 (?) の入ったリテラル文字列がソースコードにある場合は、-xtrigraph=no サブオプションを使用して文字表記シーケンスの認識をオフにすることができます。

A.2.176.1 値

-xtrigraphs に指定可能な値を次に示します。

表 A-49 -xtrigraphs の値

値	意味
`yes`	コンパイル単位全体の 3 文字表記の認識を有効にします。
`no`	コンパイル単位全体の 3 文字表記の認識を無効にします。

A.2.176.2 デフォルト

コマンド行に -xtrigraphs オプションを指定しなかった場合、コンパイラは -xtrigraphs=yes を使用します。

-xtrigraphs だけを指定すると、コンパイラは -xtrigraphs=yes を使用します。

A.2.176.3 例

trigraphs_demo.cc という名前のソースファイル例を考えてみましょう。

#include <stdio.h>

int main ()
{
    (void) printf("(\?\?) in a string appears as (??)\n");
    return 0;
}

次の例は、-xtrigraphs=yes を使用してこのコードをコンパイルしたときの出力を示しています。

example% CC -xtrigraphs=yes trigraphs_demo.cc
example% a.out
(??) in a string appears as (]

次の例は、-xtrigraphs=no を使用してこのコードをコンパイルしたときの出力を示しています。

example% CC -xtrigraphs=no trigraphs_demo.cc
example% a.out
(??) in a string appears as (??)

A.2.176.4 関連項目

3 文字表記については、『C ユーザーズガイド』の ANSI/ISO C への移行に関する章を参照してください。

A.2.177 `-xunroll=n`

このオプションはコンパイラに、可能な場合はループを展開して最適化するよう指示します。

A.2.177.1 値

n が 1 の場合、コンパイラはループを展開しません。

n が 1 より大きな整数の場合は、-unroll=n によってコンパイラがループを n 回展開します。

A.2.178 `-xustr=`{`ascii_utf16_ushort` |`no`}

コンパイラにオブジェクトファイル内で UTF-16 文字列に変換させたい文字列リテラルまたは文字リテラルがコードに含まれる場合、を使用します。このオプションが指定されていない場合、コンパイラは 16 ビット文字列リテラルを生成することも認識することもしません。このオプションにより、U"ASCII-string" 文字列リテラルを unsigned short int の配列として認識できるようになります。このような文字列はまだどの標準にも含まれていないため、このオプションによって非標準 C++ の認識が可能になります。

すべてのファイルを、このオプションによってコンパイルしなければならないわけではありません。

A.2.178.1 値

ISO10646 UTF--16 文字列リテラルを使用する国際化アプリケーションをサポートする必要がある場合、-xustr=ascii_utf-16_ushort を指定します。-xustr=no を指定すれば、コンパイラが U"ASCII_string" 文字列リテラルまたは文字リテラルを認識しなくなります。このオプションのコマンド行の右端にあるインスタンスは、それまでのインスタンスをすべて上書きします。

-xustr=ascii_ustf16_ushort の場合は、U"ASCII-string" 文字列リテラルを同時に指定しなくても指定できます。そのようにしても、エラーにはなりません。

A.2.178.2 デフォルト

デフォルトは -xustr=no です。引数を指定しないで -xustr を指定した場合、コンパイラはこの指定を受け付けず、警告を出力します。C または C++ 標準で構文の意味が定義された場合は、デフォルトが変更される可能性があります。

A.2.178.3 例

次の例では、前に U が付いた引用符内の文字列リテラルを示します。また、-xustr を指定するコマンド行も示されます。

example% cat file.cc
const unsigned short *foo = U"foo";
const unsigned short bar[] = U"bar";
const unsigned short *fun() {return foo;}
example% CC -xustr=ascii_utf16_ushort file.cc -c

8 ビットの文字列リテラルに U を付加して、unsigned short 型を持つ 16 ビットの UTF-16 文字を形成できます。例:

const unsigned short x = U'x';    
const unsigned short y = U'\x79';

A.2.179 `-xvector`[`=` `a`]

ベクトルライブラリ関数呼び出しの自動生成、または SIMD (Single Instruction Multiple Data) をサポートする x86 プロセッサ上での SIMD 命令の生成を可能にします。このオプションを使用するときは -fround=nearest を指定することによって、デフォルトの丸めモードを使用する必要があります。

-xvector オプションを指定するには、最適化レベルが -xO3 かそれ以上に設定されていることが必要です。最適化レベルが指定されていない場合や —xO3 よりも低い場合はコンパイルは続行されず、メッセージが表示されます。

a に指定可能な値を次の表に示します。no% 接頭辞は関連付けられたサブオプションを無効にします。

表 A-50 -xvector のサブオプション

値	意味
[`no%`]`lib`	(Solaris のみ) コンパイラで、ループ内の数学ライブラリ呼び出しを同等のベクトル数学ルーチンへの 1 回の呼び出しに変換できるようにします (このような変換が可能な場合)。大きなループカウントを持つループでは、これによりパフォーマンスが向上します。このオプションを無効にするには `no%lib` を使用します。
[`no%`]`simd`	(x86 のみ) コンパイラに、特定のループのパフォーマンスを向上させるためにネイティブ x86 SSE SIMD 命令を使用するよう指示します。ストリーミング拡張機能は、x86 で最適化レベルが 3 かそれ以上に設定されている場合にデフォルトで使用されます。このオプションを無効にするには、`no%simd` を使用します。コンパイラは、ストリーミング拡張機能がターゲットのアーキテクチャーに存在する場合、つまりターゲットの ISA が SSE2 以上である場合にのみ SIMD を使用します。たとえば、最新のプラットフォームで `-xtarget=woodcrest、—xarch=generic64、-xarch=sse2、-xarch=sse3`、または `-fast` を指定して使用できます。ターゲットの ISA にストリーミング拡張機能がない場合、このサブオプションは無効です。
`%none`	このオプションを完全に無効にします。
`yes`	このオプションは非推奨です。代わりに `-xvector=lib` を指定してください。
`no`	このオプションは非推奨です。代わりに `-xvector=%none` を指定してください。

A.2.179.1 デフォルト

デフォルトは、x86 では -xvector=simd で、SPARC プラットフォームでは -xvector=%none です。-xvector をサブオプションなしで指定した場合、コンパイラでは x86 Solaris では -xvector=simd,lib が、SPARC Solaris では -xvector=lib、Linux プラットフォームでは -xvector=simd が使用されます。

A.2.179.2 相互の関連性

コンパイラは、リンク時に libmvec ライブラリを取り込みます。

コンパイルとリンクを個別のコマンドで実行する場合は、リンク時の CC コマンドでも必ず -xvector を使用してください。

A.2.180 `-xvis`[`=`{ `yes`|`no`}]

(SPARC のみ) VIS Software Developers Kit (VSDK) で定義されているアセンブリ言語のテンプレートを使用する場合、または VIS 命令と vis.h ヘッダーファイルを使用するアセンブラインラインコードを使用する場合は、-xvis=[ yes|no] コマンドを使用します。

VIS 命令セットは、SPARC v9 命令セットの拡張です。UltraSPARC プロセッサが 64 ビットの場合でも、多くの場合、特にマルチメディアアプリケーションではデータサイズが 8 ビットまたは 16 ビットに制限されています。VIS 命令では 1 つの命令で 4 ワードの 16 ビットデータを処理できるため、画像処理、線形代数、信号処理、オーディオ、ビデオ、ネットワーキングなどの新しいメディアを処理するアプリケーションのパフォーマンスが大幅に向上します。

A.2.180.1 デフォルト

デフォルトは -xvis=no です。-xvis と指定すると -xvis=yes と指定した場合と同様の結果が得られます。

A.2.181 `-xvpara`

OpenMP の使用時に正しくない結果をもたらす可能性のある、並列プログラミングに関連した潜在的な問題に関する警告を発行します。-xopenmp および OpenMP API 指令とともに使用します。

次の状況が検出された場合は、コンパイラは警告を発行します。

異なるループ繰り返し間でデータに依存関係がある場合に、MP 指令を使用して並列化されたループ。
OpenMP データ共有属性節に問題がある場合。たとえば、「shared」と宣言された変数に、OpenMP 並列領域からアクセスするとデータ競合が発生する可能性がある場合や、並列領域の中に値を持つ変数を「private」と宣言し、並列領域よりあとでその変数を使用する場合です。

すべての並列化命令が問題なく処理される場合、警告は表示されません。

注 - Solaris Studio のコンパイラは OpenMP API の並列化をサポートしています。そのため、MP プラグマ命令は非推奨で、サポートされません。OpenMP API への移植については、『OpenMP API ユーザーズガイド』を参照してください。

A.2.182 `–xwe`

ゼロ以外の終了状態を返すことによって、すべての警告をエラーとして扱います。

A.2.182.1 関連項目

「A.2.15 -errwarn[= t]」

A.2.183 -Y`c`,`path`

構成要素 c がある場所の新しいパスを指定します。

コンポーネントの場所が指定されている場合、そのコンポーネントの新しいパス名は path/component-name です。このオプションは ld に渡されます。

A.2.183.1 値

次の表に、c に指定可能な値を示します。

表 A-51 -Y のフラグ

値	意味
P	`cpp` のデフォルトのディレクトリを変更します。
0	`ccfe` のデフォルトのディレクトリを変更します。
a	`fbe` のデフォルトのディレクトリを変更します。
2	`iropt` のデフォルトのディレクトリを変更します。
c (SPARC)	`cg` のデフォルトのディレクトリを変更します。
O	`ipo` のデフォルトのディレクトリを変更します。
k	`CClink` のデフォルトのディレクトリを変更します。
l	`ld` のデフォルトのディレクトリを変更します。
f	`c++filt` のデフォルトのディレクトリを変更します。
m	`mcs` のデフォルトのディレクトリを変更します。
u (x86)	`ube` のデフォルトのディレクトリを変更します。
h (x86)	`ir2hf` のデフォルトのディレクトリを変更します。
A	すべてのコンパイラ構成要素を検索するときのディレクトリを指定します。`path` にコンポーネントが見つからない場合は、コンパイラがインストールされているディレクトリに戻って検索が行われます。
P	デフォルトのライブラリ検索パスにパスを追加します。デフォルトのライブラリ検索パスの前にこのパスが調べられます。
S	起動用のオブジェクトファイルのデフォルトのディレクトリを変更します。

A.2.183.2 相互の関連性

コマンド行に複数の -Y オプションを配置できます。2 つ以上の -Y オプションが 1 つの項目に適用されている場合には、最後に指定されたものが有効です。

A.2.183.3 関連項目

リンカーとライブラリ

A.2.184 `-z`[ ]`arg`

リンクエディタのオプション。詳細は、ld(1) のマニュアルページおよび Oracle Solaris の『リンカーとライブラリ』を参照してください。

「A.2.98 -Xlinker arg」も参照してください。

ナビゲーションリンクをスキップ
印刷ビューの終了
	Oracle Solaris Studio 12.3: C++ ユーザーズガイド Oracle Solaris Studio 12.3 Information Library (日本語)