付録 A C++ コンパイラオプション

この付録では、C++ コンパイラのコマンド行オプションを詳しく説明します。ここで説明する機能は、特に記載がないかぎりすべてのプラットフォームに適用されます。SPARC システム版の Solaris に特有の機能は SPARC、x86 システム版の Solaris と Linux に特有の機能は x86 として識別されます。Solaris OS のみに限定されている機能には Solaris というマークが付きます。Linux OS のみに限定されている機能には Linux というマークが付きます。Solaris OS に関する言及には、OpenSolaris OS も暗黙的に含まれることに注意してください。

この節では、個別のオプションを説明するために、このマニュアルの「はじめに」に記載した表記上の規則を使用しています。

括弧、中括弧、角括弧、パイプ文字、および省略符号は、オプションの説明で使用されているメタキャラクタです。これらは、オプションの一部ではありません。

A.1 オプション情報の構成

簡単に情報を検索できるように、次の見出しに分けてコンパイラオプションを説明しています。オプションがほかのオプションで置き換えられたり、ほかのオプションと同じである場合、詳細についてはほかのオプション説明を参照してください。

A.2 オプションの一覧

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

A.2.1 -386

x86: -xtarget=386 と同じです。このオプションは廃止され、下位互換のためだけに用意されています。

A.2.2 -486

x86: -xtarget=486 と同じです。このオプションは廃止され、下位互換のためだけに用意されています。

A.2.3 -Bbinding

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

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

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

A.2.3.1 値

binding には次のいずれかの値を指定します。

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

デフォルト

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

相互の関連性

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

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

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

例

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

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

警告

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

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

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

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

関連項目

-nolib、-staticlib、 ld(1)、「11.5 標準ライブラリの静的リンク」、『リンカーとライブラリ』

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 ファイルは削除されません。

関連項目

-o filename、-xe

A.2.5 -cg{89|92}

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

A.2.6 –compat[={ 4|5|g}]

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

C++ コンパイラには主要なモードが 3 つあります。1 つは互換モードで、4.2 コンパイラで定義された ARM の意味解釈と言語が有効です。標準モードは、2003 年に更新された ANSI/ISO 1998 C++ 標準に従って構造体を受け入れます。これらのモードには互換性はありません。ANSI/ISO 標準では、名前の符号化、vtable の配置、そのほかの ABI の細かい点で互換性のない変更がかなり必要であるためです。—compat=g オプションにより、Linux の gcc/g++ コンパイラとの互換性が追加されます。

これらのモードは、-compat オプションで次に示す値を使用して指定します。

A.2.6.1 値

-compat オプションには次の値を指定できます。

-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 が使用されます。

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

相互の関連性

標準ライブラリは互換モード (-compat[=4]) で使用できません。

-compat[=4] では次のオプションの使用はサポートしていません。

• -Bsymbolic

• -features=[no%]strictdestrorder

• -features=[no%]tmplife

• -library=[no%]iostream

• -library=[no%]Cstd

• -library=[no%]Crun

• -library=[no%]rwtools7_std

• -xarch=native64、-xarch=generic64、-xarch=v9、-xarch=v9a、または -xarch=v9b

-compat=5 では次のオプションの使用はサポートされません。

• -Bsymbolic

• +e

• features=[no%]arraynew

• features=[no%]explicit

• features=[no%]namespace

• features=[no%]rtti

• library=[no%]complex

• library=[no%]libC

• -vdelx

警告

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

関連項目

『C++ 移行ガイド』

A.2.7 +d

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

C++ 言語の規則では、C++ は、次の条件のうち 1 つがあてはまる場合にインライン化します。

• 関数が inline キーワードを使用して定義されている

• 関数がクラス定義の中に (宣言されているだけでなく) 定義されている

• 関数がコンパイラで生成されたクラスメンバー関数である

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

相互の関連性

デバッグオプション -g を指定すると、このオプションが自動的に有効になります。

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

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

関連項目

-g0、-g

A.2.8 -Dname[ =def]

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

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

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

A.2.9 -d{y| n}

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

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

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

A.2.9.1 値

デフォルト

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

相互の関連性

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

警告

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

関連項目

ld(1)、『リンカーとライブラリ』

A.2.10 -dalign

(SPARC) -dalign は、-xmemalign=8s を指定することと同じです。詳細は、「A.2.151 -xmemalign=ab」を参照してください。

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

A.2.10.1 警告

あるプログラム単位を -dalign でコンパイルした場合は、プログラムのすべての単位を -dalign でコンパイルします。コンパイルしない場合予期しない結果が生じることがあります。

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++ コンパイラの入力に使用できないことがあります。

関連項目

-P

A.2.13 +e{0|1}

互換モード (-compat[=4]) のときに仮想テーブルの生成を制御します。標準モード (デフォルトモード) のときには無効な指定として無視されます。

A.2.13.1 値

+e オプションには次の値を指定できます。

相互の関連性

このオプションを使用してコンパイルする場合は、-features=no%except オプションも使用してください。使用しなかった場合は、例外処理で使用される内部型の仮想テーブルがコンパイラによって生成されます。

テンプレートクラスに仮想関数があると、コンパイラで必要な仮想テーブルがすべて生成され、しかもこれらのテーブルが複写されないようにすることができない場合があります。

関連項目

『C++ 移行ガイド』

A.2.14 -erroff[= t]

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

A.2.14.1 値

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

デフォルト

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

例

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

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

警告

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

関連項目

-errtags、-errwarn

A.2.15 -errtags[= a]

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

A.2.15.1 値とデフォルト

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

警告

C++ コンパイラのドライバおよび C のコンパイルシステムのほかのコンポーネントから出力されるメッセージにはエラータグが含まれないため、-erroff で無効にしたり、-errwarn で重大なエラーに変換したりすることはできません。

関連項目

-erroff、-errwarn

A.2.16 -errwarn[= t]

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

A.2.16.1 値

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

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

デフォルト

デフォルトは -errwarn=%none です。-errwarn だけを指定した場合、-errwarn=%all を指定したことと同じになります。

警告

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

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

関連項目

-erroff、-errtags、-xwe

A.2.17 -fast

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

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

A.2.17.1 拡張

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

相互の関連性

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

誤

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

正

example% CC -fast -xarch=v9 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 標準の浮動小数点演算を使用しているプログラムには、-fast を指定しないでください。計算結果が違ったり、プログラムが途中で終了する、あるいは予期しない SIGFPE シグナルが発生する可能性があります。

以前のリリースの SPARC では、-fast マクロは -fsimple=1 に展開されました。現在では、-fsimple=2 に展開されます。

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

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

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

-xbuiltin=none -U__MATHERR_ERRNO_DONTCARE -xnolibmopt -xnolibmil

これを、コマンド行で -fast のあとに使用することで、コンパイラはそのようなライブラリ呼び出しを最適化しなくなり、errno が確実に正しく処理されるようになります。

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

>CC -dryrun -fast
###     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

関連項目

-fns、-fsimple、-ftrap=%none、-xlibmil、-nofstore、-xO5、-xlibmopt、-xtarget=native

A.2.18 -features=a[ ,a...]

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

A.2.18.1 値

互換モード (-compat[=4]) と標準モード (デフォルトモード) の両方で、次の値の 1 つを指定できます。

標準モード (デフォルトのモード) では、a にはさらに次の値の 1 つを指定できます。

互換モード (-compat[=4]) では、a にはさらに次の値の 1 つを指定できます。

[no%]castop の設定は、C++ 4.2 コンパイラ用に作成されたメイクファイルとの互換性を維持するために使用できますが、それ以降のバージョンのコンパイラには影響はありません。新しい書式の型変換 (const_cast、dynamic_cast、reinterpret_cast、static_cast) は常に認識され、無効にすることはできません。

デフォルト

–features を指定しないと、互換モードのデフォルト (-compat[=4]) が使用されます。

-features=%none,anachronisms,except,split_init,transitions

デフォルトである「標準モード」では、

-features=%all,no%altspell,no%bool,no%conststrings,no%extensions,no%iddollar,\ 
              no%rvalueref,no%tmplrefstatic

が使用されます。

相互の関連性

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

次の値の標準モードによる使用 (デフォルト) は、標準ライブラリやヘッダーと互換性がありません。

• no%bool

• no%except

• no%mutable

• no%explicit

互換モード (-compat[=4]) では、+w オプションまたは +w2 オプションを指定しないかぎり、-features=transitions オプションは無効です。

警告

-features=%all や -features=%none を使用するときは注意してください。機能群がコンパイラおよびパッチのリリースのたびに変わる可能性があります。その結果、予期しない動作になる可能があります。

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

互換モード (-compt=4) の場合、デフォルトではコンパイラは -features=split_init と見なします。-features=%none オプションを使用してほかの機能を使用できないようにした場合は、代わりに -features=%none,split_init を使用して初期設定子の個別の関数への分割をまた有効にすることをお勧めします。

関連項目

表 3–17 および『C++ 移行ガイド』

A.2.19 -filt[= filter[,filter...]]

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

A.2.19.1 値

filter は次の値のいずれかである必要があります。

デフォルト

-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.20 -flags

-xhelp=flags と同じです。

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

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

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

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

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

A.2.22 -fnonstd

浮動小数点オーバーフローのハードウェアによるトラップ、ゼロによる除算、無効演算の例外を有効にします。これらの結果は、SIGFPE シグナルに変換されます。プログラムに SIGFPE ハンドラがない場合は、メモリーダンプを行なってプログラムを終了します (ただし、コアダンプのサイズをゼロに制限した場合を除きます)。

SPARC: さらに、-fnonstd は SPARC 非標準浮動小数点を選択します。

A.2.22.1 デフォルト

-fnonstd を指定しないと、IEEE 754 浮動小数点演算例外が起きても、プログラムは異常終了しません。アンダーフローは段階的です。

拡張

x86: -fnonstd は -ftrap=common に拡張されます。

SPARC: -fnonstd は -fns -ftrap=common に拡張されます。

関連項目

-fns、-ftrap=common、『数値計算ガイド』

A.2.23 -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.23.1 値

-fns オプションには次の値を指定できます。

デフォルト

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

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

例

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

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

警告

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

1 つのルーチンを -fns オプションでコンパイルした場合は、そのプログラムのすべてのルーチンを -fns オプションでコンパイルする必要があります。コンパイルしない場合、予期しない結果が生じることがあります。

このオプションは、SPARC プラットフォームでメインプログラムをコンパイルするときしか有効ではありません。x86 プラットフォームでは、このオプションは無視されます。

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

関連項目

『数値計算ガイド』、ieee_sun(3M)

A.2.24 -fprecision=p

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

-fprecision オプションを指定すると、FPU (Floating Point Unit) 制御ワードの丸め精度モードのビットが設定されます。これらのビットは、基本演算 (加算、減算、乗算、除算、平方根) の結果をどの精度に丸めるかを制御します。

A.2.24.1 値

p は次のいずれかでなければいけません。

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.25 -fround=r

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

このオプションは、次に示す IEEE 754 丸めモードを設定します。

• 定数式を評価する時にコンパイラが使用できる。

• プログラム初期化中の実行時に設定される。

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

A.2.25.1 値

r には次の値のいずれかを指定します。

デフォルト

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

警告

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

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

A.2.26 –fsimple[= n]

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

このオプションで浮動小数点演算に影響する前提を設けることにより、オプティマイザで行う浮動小数点演算が簡略化されます。

A.2.26.1 値

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

デフォルト

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

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

相互の関連性

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

警告

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

関連項目

-fast

最適化が精度に与える影響の詳細は、『Techniques for Optimizing Applications: High Performance Computing』(Rajat Garg、Ilya Sharapov 共著) をお読みください。

A.2.27 -fstore

x86:

浮動小数点式の精度を強制的に使用します。

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

• 式や関数を変数に代入する。

• 式をそれより短い浮動小数点型にキャストする。

このオプションを解除するには、オプション -nofstore を使用してください。

A.2.27.1 警告

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

関連項目

-nofstore

A.2.28 -ftrap=t[,t...]

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

A.2.28.1 値

t には次の値のいずれかを指定できます。

[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 を使用してください。

関連項目

ieee_handler(3M) および fex_set_handling(3M) のマニュアルページ

A.2.29 -G

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

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

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

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

「A.2.118 -xcode=a」で推奨しているように、共有オブジェクトの作成では、-xarch=v9 を付けてコンパイルしたすべてのオブジェクトファイルもまた、明示的な -xcode 値を付けてコンパイルする必要があります。

A.2.29.1 相互の関連性

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

• -dy

• -G

• -R

警告

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

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

関連項目

-dy、-Kpic、-xcode=pic13、-ztext、ld(1) のマニュアルページ、「15.3 動的 (共有) ライブラリの構築」

A.2.30 -g

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

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

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

• オブジェクトファイルと実行可能ファイルのシンボルテーブル内に、詳細情報 (スタブ) を生成する。

• 「補助関数」を生成する。デバッガはこれを呼び出して、その一部の機能を実現する。

• 最適化レベルが指定されていない場合は、関数のインライン生成を無効にします。つまり、最適化レベルも指定されていない場合、このオプションを使用すると +d オプションが指定されていることになります。-O レベルまたは -xO レベルが指定された -g では、インラインは無効になりません。

• 特定のレベルの最適化を無効にする。

A.2.30.1 相互の関連性

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

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

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

以前のリリースでは、このオプションは、コンパイラのリンク専用の呼び出しにおいて、デフォルトで強制的にリンカー (ld) ではなく、インクリメンタルリンカー (ild) を使用するようにしていました。すなわち、-g が指定されたときのコンパイラは、そのデフォルトの動作として、コマンド行に -G またはソースファイルの指定がなくてもオブジェクトファイルのリンクで必ず、ld の代わりに ild を自動的に呼び出していました。現在、このようなことはありません。インクリメンタルリンカーは利用できなくなりました。

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

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

警告

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

関連項目

+d、-g0、-xs、analyzer(1) マニュアルページ、er_src(1) マニュアルページ、および ld(1) のマニュアルページ『dbx コマンドによるデバッグ』(スタブの詳細について)『プログラムのパフォーマンス解析』

A.2.31 -g0

デバッグ用のコンパイルとリンクを行いますが、インライン展開は行いません。

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

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

A.2.31.1 関連項目

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

A.2.32 -H

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

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

A.2.33 -h[ ]name

生成する動的共有ライブラリに名前 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" の形式) ファイルを次の順序で検索します。

1. ソースが存在するディレクトリ

2. -I オプションで指定したディレクトリ内 (存在する場合)

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

4. /usr/include ディレクトリ内

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

1. -I オプションで指定したディレクトリ内 (存在する場合)

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

3. /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 を検索ディレクトリに指定しないでください。

関連項目

-I-

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 の設定を無視します。

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 には次のいずれかを指定します。

デフォルト

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

関連項目

「7.2.4 テンプレートインスタンスの配置とリンケージ」

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

関連項目

-template、-instances、-pti

A.2.42 -KPIC

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

x86: -Kpic と同じです。

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

A.2.43 -Kpic

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

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

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

A.2.44 -keeptmp

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

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

A.2.44.1 関連項目

–v、–verbose

A.2.45 -Lpath

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

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

A.2.45.1 相互の関連性

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

警告

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

A.2.46 -llib

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

このオプションは ld に渡されます。通常のライブラリは、名前が liblib.a か liblib.so の形式です (lib と .a または .so の部分は必須です)。このオプションでは lib の部分を指定できます。コマンド行には、ライブラリをいくつでも指定できます。指定したライブラリは、-Ldir で指定された順に検索されます。

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

A.2.46.1 相互の関連性

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

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

警告

libthread とリンクする場合は、ライブラリを正しい順序でリンクするために -lthread ではなく -mt を使用してください。

関連項目

-Ldir、-mt、「10.4.8 アプリケーションの例」、『 Tools.h++ クラスライブラリリファレンスマニュアル』

A.2.47 -libmieee

-xlibmieee と同じです。

A.2.48 -libmil

-xlibmil と同じです。

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

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

A.2.49.1 値

互換モード (-compat[-4]]) の場合、l には次のいずれかを指定します。

標準モード (デフォルトモード) の場合、l には次のいずれかを指定します。

デフォルト

• 互換モード (-compat[=4])

  • -library を指定しない場合は、-library=libC が想定されます。

  • library=no%libC で特に除外されないかぎり、libC ライブラリは常に含まれます。

  標準モード (デフォルトモード)

  • -library=%none、-library=no%Cstd、-library=stlport4 のいずれかで特に除外されないかぎり、libCstd ライブラリは常に含まれます。

  • -library=no%Crun で特に除外されないかぎり、libCrun ライブラリは常に含まれます。

  -library=%none が指定されたとしても、標準または互換のどちらのモードであるかに関わりなく、libm および libc ライブラリは常に含まれます。

例

標準モードで libCrun 以外の C++ ライブラリを除外してリンクするには、次のコマンドを使用します。

example% CC -library=%none

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

example% CC –library=rwtools7,iostream

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

example% CC -library=rwtools7_std

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

example% CC -compat -library=rwtools7

相互の関連性

-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 ライブラリを Solaris OS の /usr/include および /usr/lib にインストールする必要があります。このライブラリは、最近の OpenSolaris リリースでも使用できます。

-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 -compat -library=rwtools7 foo.cc        <-- valid
% CC -compat -library=rwtools7_std foo.cc    <-- invalid

% 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 が混在し、その両方のコードから同じファイルにアクセスすると、問題が発生する可能性があります。

libC ライブラリをリンクしない互換モードプログラムは、C++ 言語のすべての機能を使用できるわけではありません。同様に、Crun ライブラリ、または Cstd と stlport4 いずれのライブラリもリンクしない標準モードプログラムは、C++ 言語のすべての機能を使用できるわけではありません。

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

警告

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

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

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

関連項目

-I、-l、-R、-staticlib、-xia、-xlang、-xnolib、「10.4.8 アプリケーションの例」、「警告:」、「12.3.1 再配布とサポートされる STLport ライブラリ」、『Tools.h++ ユーザーズガイド』、『Tools.h++ クラスライブラリリファレンスマニュアル』、『Standard C++ Class Library Reference』、『 C++ Interval Arithmetic Programming Reference』

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

A.2.50 -m32|-m64

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

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

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

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

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

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

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

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

-xarch も参照してください。

A.2.51 -mc

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

A.2.52 -migration

以前のバージョンのコンパイラ用に作成されたソースコードの移行に関する情報の参照先を表示します。

このオプションは次のリリースでは存在しなくなる可能性があります。

A.2.53 -misalign

SPARC: 通常はエラーになる、メモリー中の境界整列の誤ったデータを許可します。次に例を示します。

char b[100];
int f(int * ar) {
return *(int *) (b +2) + *ar;
}

このオプションは、プログラムの中に正しく境界整列されていないデータがあることをコンパイラに知らせます。したがって、境界整列が正しくない可能性があるデータに対しては、ロードやストアを非常に慎重に、つまり 1 度に 1 バイトずつ行う必要があります。このオプションを使用すると、実行速度が大幅に低下することがあります。低下する程度はアプリケーションによって異なります。

A.2.53.1 相互の関連性

SPARC プラットフォーム上で #pragma pack を使用して、型のデフォルトの境界整列よりも密に配置するには、アプリケーションのコンパイルとリンクの両方で -misalign オプションを指定する必要があります。

境界整列が正しくないデータは、実行時に ld のトラップ機構によって処理されます。misalign オプションとともに最適化フラグ (-xO{1|2|3|4|5} またはそれと同等のフラグ) を使用すると、ファイル境界整列の正しくないデータを正しい境界に整列に合わせるための命令がオブジェクトに挿入されます。この場合には、実行時不正境界整列トラップは生成されません。

警告

できれば、プログラムの境界整列が正しい部分と境界整列が誤った部分をリンクしないでください。

コンパイルとリンクを別々に行う場合は、-misalign オプションをコンパイルコマンドとリンクコマンドの両方で指定する必要があります。

A.2.54 -mr[, string]

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

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

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

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

Solaris スレッドを使用するには、thread.h ヘッダーファイルをインクルードし、—mt=yes オプションを使用してコンパイルします。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.55.1 関連項目

–xnolib、Solaris 『Multithreaded Programming Guide』、および『Linker and Libraries Guide』

A.2.56 -native

-xtarget=native と同じです。

A.2.57 -noex

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

A.2.58 -nofstore

x86: 強制された式の精度を無効にします。

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

• 式や関数を変数に割り当てる

  または

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

A.2.58.1 関連項目

-fstore

A.2.59 -nolib

-xnolib と同じです。

A.2.60 -nolibmil

-xnolibmil と同じです。

A.2.61 -noqueue

(廃止) ライセンスを待ち行列に入れません。

ライセンスを確保できない場合、コンパイラはコンパイル要求を待ち行列に入れず、コンパイルもしないで終了します。メイクファイルのテストには、ゼロ以外の状態が返されます。このオプションは廃止されたので無視します。

A.2.62 -norunpath

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

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

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

A.2.62.1 相互の関連性

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

A.2.63 -O

このリリースから、-O マクロは、-xO2 でなく、-xO3 に展開されます。

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

A.2.64 -Olevel

-Olevel、コンパイラオプション同じです。

A.2.65 -o filename

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

A.2.65.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 は、コンパイラが作成するファイルの型に合った接尾辞を含むする必要があります。また、CC ドライバはソースファイルには上書きしないため、ソースファイルとは異なるファイルを指定する必要があります。

A.2.66 +p

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

A.2.66.1 デフォルト

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

相互の関連性

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

• sun

• unix

• sparc

• i386

A.2.67 -P

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

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

A.2.67.1 関連項目

-E

A.2.68 -p

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

A.2.69 -pentium

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

A.2.70 -pg

-xpg と同じです。

A.2.71 -PIC

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

x86: -Kpic と同じです。

A.2.72 -pic

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

x86: -Kpic と同じです。

A.2.73 -pta

-template=wholeclass と同じです。

A.2.74 -ptipath

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

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

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

A.2.74.1 相互の関連性

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

関連項目

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

A.2.75 -pto

-instances=static と同じです。

A.2.76 –ptr

このオプションは廃止されたため、コンパイル時には無視されます。

A.2.76.1 警告

-ptr オプションは存在しても無視されますが、すべてのコンパイルコマンドから削除するようにしてください。これは将来のリリースで、-ptr が以前とは異なる動作のオプションとして再実装される可能性があるためです。

関連項目

リポジトリのディレクトリについては、「7.4 テンプレートリポジトリ」を参照してください。

A.2.77 -ptv

-verbose=template と同じです。

A.2.78 -Qoption phase option[,option…]

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

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

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

-z オプションは、この順序でリンカーに渡されます。一方、次のようなコマンドを指定したとします。

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

-z オプションの順序が変わり、不正な結果が生じる可能性があります。

A.2.78.1 値

phase には、次の値のいずれか 1 つを指定します。

例

次に示すコマンド行では、ld が CC ドライバによって起動されたとき、-Qoption で指定されたオプションの -i と -m が ld に渡されます。

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

警告

意図しない結果にならないように注意してください。たとえば、次を見てください。

-Qoption ccfe -features=bool,iddollar

しかしこの指定は、意図に反して次のように解釈されてしまいます。

-Qoption ccfe -features=bool -Qoption ccfe iddollar

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

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

A.2.79 -qoption phase option

-Qoption と同じです。

A.2.80 -qp

-p と同じです。

A.2.81 -Qproduce sourcetype

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

sourcetype に指定する接尾辞の定義は次のとおりです。

A.2.82 -qproduce sourcetype

-Qproduce と同じです。

A.2.83 -Rpathname[ :pathname…]

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

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

A.2.83.1 デフォルト

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

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

相互の関連性

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

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

関連項目

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

A.2.84 -readme

-xhelp=readme と同じです。

A.2.85 -S

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

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

A.2.86 -s

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

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

A.2.87 -sb

廃止され、メッセージを表示されずに無視されます。

A.2.88 -sbfast

廃止され、メッセージを表示されずに無視されます。

A.2.89 -staticlib=l[ ,l…]

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

A.2.89.1 値

l には、次の値のいずれか 1 つを指定します。

デフォルト

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

例

-library のデフォルト値は Crun であるため、次のコマンド行は、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 オプションを Sun Performance Library のライブラリのリンクに反映させるために -library=sunperf を -staticlib=sunperf に関連させて使用する必要があるからです。

example% CC -xlic_lib=sunperf -staticlib=sunperf (incorrect)
 This command links the Sun Performance Libraries statically:

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

相互の関連性

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

-staticlib オプションは、-xia、-xlang および -library オプションで明示的に選択された C++ ライブラリ、または、デフォルトで暗黙的に選択された C++ ライブラリだけに機能します。互換モードでは (-compat=[4])、libC がデフォルトで選択されます。標準モードでは (デフォルトのモード)、Cstd と Crun がデフォルトで選択されます。

-xarch=v9、-xarch=v9a、-xarch=v9b のいずれか、あるいは、64 ビットアーキテクチャーのオプションと同等のオプションを使用する場合、静的ライブラリとしては使用できない C++ ライブラリがあります。

警告

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

-xarch=v9、-xarch=v9a、-xarch=v9b のいずれか、あるいは、64 ビットアーキテクチャーのオプションと同等のオプションを使用する場合、静的ライブラリとしては使用できない C++ ライブラリがあります。

64 ビット Solaris x86 プラットフォームでは、-staticlib=Crun および -staticlib=Cstd オプションは機能しません。どのプラットフォームであれ、これらのライブラリを静的にリンクすることは推奨しません。静的リンクすることによって、プログラムが機能しなくなることがあります。

関連項目

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

A.2.90 -sync_stdio=[yes| no]

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

A.2.90.1 デフォルト

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

次に例を示します。

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

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

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

Hello beautiful world!
:

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

警告

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

A.2.91 -temp=path

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

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

A.2.91.1 関連項目

-keeptmp

A.2.92 -template=opt[,opt…]

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

A.2.92.1 値

opt は次のいずれかの値である必要があります。

デフォルト

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

例

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

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_]

関連項目

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

A.2.93 -time

-xtime と同じです。

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

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

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

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

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

= 記号を指定せずに、-traceback だけを指定すると、-traceback=common と同義になります。

注: コアダンプが不要な場合は、次を使用して coredumpsize 制限を 0 に設定できます。

% limit coredumpsize 0            

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

A.2.95 -Uname

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

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

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

A.2.95.1 例

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

example% CC -U__sun foo.cc

相互の関連性

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

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

関連項目

-D

A.2.96 -unroll=n

-xunroll=n と同じです。

A.2.97 -V

-verbose=version と同じです。

A.2.98 -v

-verbose=diags と同じです。

A.2.99 -vdelx

非推奨。使用しないでください。

互換モード (-compat[=4]) のみ

delete[] を使用する式に対し、実行時ライブラリ関数 _vector_delete_ の呼び出しを生成する代わりに _vector_deletex_ の呼び出しを生成します。関数 _vector_delete_ は、削除するポインタおよび各配列要素のサイズという 2 つの引数をとります。

関数 _vector_deletex_ は _vector_delete_ と同じように動作しますが、3 つ目の引数として そのクラスのデストラクタのアドレスをとります。この引数は Sun 以外のベンダーが使用するためのもので、関数では使用しません。

A.2.99.1 デフォルト

コンパイラは、delete[] を使用する式に対して _vector_delete_ の呼び出しを生成します。

警告

これは旧式フラグであり、将来のリリースでは削除されます。Sun 以外のベンダーからソフトウェアを購入し、ベンダーがこのフラグの使用を推奨していないかぎり、このオプションは使用しないでください。

A.2.100 -verbose=v[,v…]

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

A.2.100.1 値

v には、次に示す値の 1 つを指定します。

デフォルト

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

相互の関連性

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

A.2.101 +w

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

次のような問題のありそうな構造について、追加の警告を生成します。

• 移植性がない

• 間違っていると考えられる

• 効率が悪い

A.2.101.1 デフォルト

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

関連項目

–w、+w2

A.2.102 +w2

+w で発行される警告に加えて、技術的な違反についての警告を発行します。これは、危険性はないが、プログラムの移植性を損なう可能性がある違反に対するものです。

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

A.2.102.1 関連項目

+w

A.2.103 -w

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

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

A.2.103.1 関連項目

+w

A.2.104 -Xm

-features=iddollar と同じです。

A.2.105 -xaddr32

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

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

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

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

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

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

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

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

詳細は、『Linker and Libraries Guide』で説明されている SF1_SUNW_ADDR32 ソフトウェア機能の定義を参照してください。

A.2.106 -xalias_level[= n]

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

• -xalias_level[=n ]

  ここで、n には any、simple、compatible のいずれかを指定します。

• -xalias_level=any

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

• -xalias_level=simple

  単純型は別名で定義されていないものとして処理されます。次の単純型のいずれかの動的な型である記憶オブジェクトの場合を説明します。

  char	short int	long int	float
  signed char	unsigned short int	unsigned long int	double
  unsigned char	int	long long int	long double
  wchar_t	unsigned int	unsigned long long int	enumeration types
  データポインタ型	関数ポインタ型	データメンバーのポインタ型	関数メンバーのポインタ型

  これらは、次の型の lvalue を使用してだけアクセスされます。

  • オブジェクトの動的な型

  • オブジェクトの動的な型を constant または volatile で修飾したもの。つまり、オブジェクトの動的な型に相当する符号付きまたは符号なしの型。

  • オブジェクトの動的な型を constant または volatile で修飾したものに相当する、符号付きまたは符号なしの型。

  • 前述の型のいずれかがメンバーに含まれる集合体または共用体 (再帰的に、その下位の集合体またはそれに含まれる共用体のメンバーについても該当します)。

  • char 型または unsigned char 型

• -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.106.1 デフォルト

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

相互の関連性

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

警告

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

union bitbucket{
  int i;
  float f;
};

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

A.2.107 -xannotate[=yes| no]

(Solaris) binopt(1) のようなバイナリ変更ツールであとで変換できるバイナリを作成するようコンパイラに指示します。将来のバイナリ解析、コードガバレージ、およびメモリーエラー検出ツールでも、このオプションを使用して構築されたバイナリを使用できます。

これらのツールによるバイナリファイルの変更を防止するには、-xannotate=no オプションを使用します。

-xannotate=yes オプションを有効にするには、最適化レベルを -xO1 かそれ以上に設定して使用する必要があります。また、このオプションは、新しいリンカーサポートライブラリインタフェース -ld_open() をサポートしているシステムでのみ有効です。Solaris 9 OS のように、このリンカーインタフェースをサポートしていないオペレーティングシステムでコンパイラを使用している場合は、コンパイラはメッセージを表示せずに -xannotate=no に戻します。新しいリンカーインタフェースは、Solaris 10 patch 127111-07、Solaris 10 Update 5、および OpenSolaris で使用できます。

デフォルトは -xannotate=yes ですが、前述の条件のいずれかが満たされていない場合は、デフォルトは -xannotate=no に戻されます。

Linux プラットフォームでは、このオプションはありません。

A.2.108 -xar

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

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

A.2.108.1 値

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

例

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

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

警告

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

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

関連項目

ar(1)、表 14–3

A.2.109 -xarch=isa

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

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

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

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

A.2.109.1 SPARC での -xarch のフラグ

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

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

• generic、sparc、sparcvis2、sparcvis3、sparcfmaf、sparcima でコンパイルされたオブジェクトライブラリファイル (.o) をリンクして、一度に実行できます。ただし、実行できるのは、リンクされているすべての命令セットをサポートしているプロセッサのみです。

• 特定の設定で、生成された実行可能ファイルが実行されなかったり、従来のアーキテクチャーよりも実行速度が遅くなったりする場合があります。また、4 倍精度 (REAL*16 および long double) 浮動小数点命令は、これらの命令セットアーキテクチャーのいずれにも実装されないため、コンパイラは、そのコンパイラが生成したコードではそれらの命令を使用しません。

A.2.109.2 x86 での -xarch のフラグ

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

A.2.109.3 x86 の特記事項

x86 Solaris プラットフォーム用にコンパイルを行う場合に注意が必要な、重要な事項がいくつかあります。

従来の Sun 仕様の並列化プログラムは、x86 では使用できません。代わりに OpenMP を使用してください。従来の並列化命令を OpenMP に変換する方法については、『Solaris Studio OpenMP API ユーザーズガイド』を参照してください。

-xarch を sse、sse2、sse2a、または sse3 以降に設定してコンパイルしたプログラムは、必ずこれらの拡張子と機能を提供するプラットフォームでのみ実行してください。

Pentium 4 互換プラットフォームの場合、Solaris OS リリースは SSE/SSE2 に対応しています。これより前のバージョンの Solaris OS は SSE/SSE2 に対応していません。-xarch で選択した命令セットが、実行中の Solaris OS で有効ではない場合、コンパイラはその命令セットのコードを生成またはリンクできません。

コンパイルとリンクを別々に行う場合は、必ずコンパイラを使ってリンクし、-xarch 設定で適切な起動ルーチンがリンクされるようにしてください。

x86 の 80 バイト浮動小数点レジスタが原因で、x86 での演算結果が SPARC の結果と異なる数値になる場合があります。この差を最小にするには、 -fstore オプションを使用するか、ハードウェアが SSE2 をサポートしている場合は -xarch=sse2 でコンパイルします。

Solaris と Linux でも、固有の数学ライブラリ (たとえば、sin(x)) が同じではないため、演算結果が異なることがあります。

A.2.109.4 バイナリの互換性の妥当性検査

Solaris Studio 11 と Solaris 10 OS から、これらの特殊化された -xarch ハードウェアフラグを使用してコンパイルし、構築されたプログラムバイナリは、適切なプラットフォームで実行されることが確認されます。

Solaris 10 以前のシステムでは妥当性検査が行われないため、これらのフラグを使用して構築したオブジェクトが適切なハードウェアに配備されることをユーザが確認する必要があります。

これらの -xarch オプションでコンパイルしたプログラムを、適切な機能または命令セット拡張に対応していないプラットフォームで実行すると、セグメント例外や明示的な警告メッセージなしの不正な結果が発生することがあります。

このことは、.il インラインアセンブリ言語関数を使用しているプログラムや、SSE、SSE2、SSE2a、および SSE3 の命令と拡張機能を利用している __asm() アセンブラコードにも当てはまります。

A.2.109.5 相互の関連性

このオプションは単体でも使用できますが、-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.109.6 警告

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

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

A.2.110 -xautopar

このオプションは OpenMP の並列化命令を受け付けません。Sun 固有の MP プラグマは推奨されず、サポートされません。標準命令への移植情報については、『Solaris Studio OpenMP API ユーザーズガイド』を参照してください。

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

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

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

並列化されたプログラムをマルチスレッド環境で実行するには、実行前に OMP_NUM_THREADS 環境変数を設定しておく必要があります。詳細は、『Solaris Studio OpenMP API ユーザーズガイド』を参照してください。

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

A.2.110.1 関連項目

「A.2.158 -xopenmp[= i]」

A.2.111 -xbinopt={prepare| off}

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

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

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

A.2.111.1 デフォルト

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

相互の関連性

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

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

A.2.112 -xbuiltin[={ %all|%none}]

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

デフォルトでは、標準ライブラリヘッダで宣言された関数は、コンパイラによって通常の関数として処理されます。ただし、これらの関数の一部は、「組み込み」として認識されます。組み込み関数として処理されるときは、コンパイラでより効果的なコードを生成できます。たとえば、一部の関数は副作用がないことをコンパイラで認識でき、同じ入力が与えられると常に同じ出力が戻されます。一部の関数はコンパイラによって直接インラインで生成できます。オブジェクトファイル内のコンパイラのコメントからコンパイラが実際に置換を行う関数を特定する方法については、er_src(1) のマニュアルページを参照してください。

-xbuiltin=%all オプションは、コンパイラにできるだけ多数の組み込み標準関数を認識するように指示します。認識される関数の正確なリストは、コンパイラコードジェネレータのバージョンによって異なります。

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

A.2.112.1 デフォルト

-xbuiltin を指定しないと、コンパイラでは -xbuiltin=%none が使用されます。

-xbuiltin だけを指定すると、コンパイラでは -xbuiltin=%all が使用されます。

相互の関連性

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

例

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

example% CC -xbuiltin -c foo.cc

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

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

A.2.113 -xcache=c

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

このオプションは単独で指定できますが、-xtarget オプションの拡張機能の一部です。-xtarget オプションによって供給された値をオーバーライドするために使用されます。

このリリースで、キャッシュを共有できるスレッド数を指定するオプションの特性 [/ti] が導入されました。

A.2.113.1 値

c には次の値のいずれかを指定します。

キャッシュ属性 si/li/ai/ti の定義は、次のとおりです。

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

デフォルト

-xcache が指定されない場合、デフォルト -xcache=generic が想定されます。この値を指定すると、ほとんどの SPARC プロセッサで良好なパフォーマンスが得られ、どのプロセッサでも顕著なパフォーマンスの低下がないキャッシュ属性がコンパイラで使用されます。

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

例

-xcache=16/32/4:1024/32/1 の設定内容は、次のとおりです。

関連項目

-xtarget=t

A.2.114 -xcg[89|92]

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

A.2.115 -xchar[= o]

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

A.2.115.1 値

o には、次のいずれかを指定します。

デフォルト

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

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

相互の関連性

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

警告

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

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

A.2.116 -xcheck[= i]

SPARC: -xcheck=stkovfを指定してコンパイルすると、シングルスレッドのプログラム内のメインスレッドのスタックオーバーフローおよびマルチスレッドプログラム内のスレーブスレッドのスタックが実行時にチェックされます。スタックオーバーフローが検出された場合は、SIGSEGV が生成されます。アプリケーションで、スタックオーバーフローで生成される SIGSEGV をほかのアドレス空間違反と異なる方法で処理する必要がある場合は、sigaltstack(2) を参照してください。

A.2.116.1 値

i には、次のいずれかを指定します。

デフォルト

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

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

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

A.2.117 -xchip=c

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

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

• 命令の順序 (スケジューリング)

• コンパイラが分岐を使用する方法

• 意味が同じもので代用できる場合に使用する命令

  ---

  注 –

  このオプションは単独で指定できますが、-xtarget オプションの拡張機能の一部です。-xtarget オプションによって供給された値をオーバーライドするために使用されます。

  ---

A.2.117.1 値

c には次の値のいずれかを指定します。

デフォルト

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

A.2.118 -xcode=a

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

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

A.2.118.1 値

a には次のいずれかを指定します。

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

一般に、-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.119 -xcrossfile[= n]

廃止。使用しないでください。代わりに -xipo を使用してください。

A.2.120 -xdebugformat=[stabs|dwarf]

コンパイラは、 デバッグ情報の形式をスタブ形式から「DWARF Debugging Information Format」で規定されている dwarf 形式に変換します。デフォルト設定は -xdebugformat=dwarf です。

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

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

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

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

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

これは過渡的なインタフェースなので、今後のリリースでは、マイナーリリースであっても互換性なく変更されることがあります。stab と dwarf のどちらであっても、特定のフィールドまたは値の詳細は、今後とも変更される可能性があります。

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

A.2.121 -xdepend=[yes| no]

(SPARC) ループの繰り返し内部でのデータ依存性の解析およびループ再構成を実行します。この中には、ループ交換、ループ融合、スカラー交換、「デッドアレイ」代入の回避が含まれます。

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

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

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

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

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

関連項目: -xprefetch_auto_type

A.2.122 -xdumpmacros[= value[,value...]]

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

A.2.122.1 値

value の代わりに次の引数を使用できます。

オプションの値は追加されていきます。-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

関連項目

dumpmacros プラグマと end_dumpmacros プラグマを使用すれば、-xdumpmacros のスコープを変更できます。

A.2.123 -xe

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

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

A.2.123.1 関連項目

-c

A.2.124 -xF[=v[, v...]]

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

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

変数を並べ替えることによって、実行時間のパフォーマンスにマイナスの影響を与える次のような問題を解決できます。

• メモリー内で関係ない変数どうしが近接しているために生じる、キャッシュやページの競合

• 関係のある変数がメモリー内で離れた位置にあるために生じる、不必要に大きな作業セットサイズ

• 使用していない weak 変数のコピーが有効なデータ密度を低下させた結果生じる、不必要に大きな作業セットサイズ

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

1. -xF によるコンパイルとリンク

2. 『プログラムのパフォーマンス解析』マニュアル内の、関数のマップファイルを生成する方法に関する指示に従うか、または、『リンカーとライブラリ』内の、データのマップファイルを生成する方法に関する指示に従います。

3. リンカーの -M オプションを使用して新しいマップファイルを再リンクします。

4. アナライザで再実行して、パフォーマンスが向上したかどうかを検証します。

A.2.124.1 値

v には、次のいずれかを指定します。

デフォルト

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

相互の関連性

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

関連項目

analyzer(1)、ld(1) のマニュアルページも参照してください。

A.2.125 -xhelp=flags

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

A.2.126 -xhelp=readme

README (最新情報) ファイルの内容を表示します。

README ファイルのページングには、環境変数 PAGER で指定されているコマンドが使用されます。PAGER が設定されていない場合、デフォルトのページングコマンド more が使用されます。

A.2.127 -xhwcprof

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

-xhwcprof が有効な場合、ツールがプロファイリング済み負荷を関連付け、命令をデータ型および構造メンバーと一緒に (参照先の -g で生成されたシンボリック情報と組み合わせて) 格納するために役立つ情報を、コンパイラが生成します。プロファイルデータは、ターゲットの命令空間ではなく、データ空間と関連付けられ、命令のプロファイリングだけでは入手の容易でない、動作に関する詳細情報が提供されます。

指定した一連のオブジェクトファイルは、-xhwcprof を指定してコンパイルできます。ただし、-xhwcprof がもっとも役に立つのは、アプリケーション内のすべてのオブジェクトファイルに適用したときです。このオプションによって、アプリケーションのオブジェクトファイルに分散しているすべてのメモリー参照を識別したり、関連付けたりするカバレージが提供されます。

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

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

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

-xhwcprof では、最適化を有効にして、デバッグのデータ形式を DWARF (-xdebugformat=dwarf) に設定する必要があります。

-xhwcprof と -g を組み合わせて使用すると、コンパイラに必要な一時ファイル記憶領域は、-xhwcprof と -g を単独で指定することによって増える量の合計を超えて大きくなります。

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

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

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

A.2.128 -xia

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

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

x86 プラットフォームでは、SSE2 命令セットのサポートが必要です。

A.2.128.1 拡張

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

相互の関連性

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

区間演算ライブラリを使用するときは、libC、Cstd、または iostream のいずれかのライブラリを取り込む必要があります。これらのライブラリを取り込む方法については、-library を参照してください。

警告

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

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

関連項目

-library

A.2.129 -xinline[=func_spec[,func_spec...]]

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

A.2.129.1 値

func_spec には次の値のいずれかを指定します。

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

デフォルト

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

-xinline= に引数を指定しないと、最適化のレベルにかかわらず関数がインライン化されます。

例

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

相互の関連性

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

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

• 最適化は -xO3 以上

• インライン化に効果があって安全

• コンパイル中のファイルの中に関数がある、または-xipo[=1|2] を使用してコンパイルしたファイルの中に関数がある

警告

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

関連項目

「A.2.136 -xldscope={v}」

A.2.130 -xinstrument=[ no%]datarace

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

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

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

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

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

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

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

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

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

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

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

A.2.131.1 値

-xipo オプションには次の値があります。

デフォルト

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

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

例

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

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

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

相互の関連性

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

同じコンパイラコマンド行に -xipo オプションと -xcrossfile オプションの両方は使用できません。

警告

コンパイルとリンクを個別に実行する場合、-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.131.2 -xipo= を使用しない内部手続き解析を行う場合

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

• 実行時、このオブジェクトファイル群の外部で定義されている別のルーチンによって foo() が明示的に呼び出されない。

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

アプリケーションに対して仮定 1 が当てはまらない場合は、コンパイルで -xipo=2 を使わないでください。

仮定 2 が当てはまらない場合は、コンパイルで -xipo=1 および -xipo=2 を使わないでください。

1 例として、独自のバージョンの malloc() で関数 malloc() を置き換え、-xipo=2 を指定してコンパイルするケースを考えてみましょう。-xipo=2 を使ってコンパイルする場合、その独自のコードとリンクされる malloc() を参照する、あらゆるライブラリのあらゆる関数のコンパイルで -xipo=2 を使用する必要があるとともに、リンクステップでそれらのオブジェクトファイルが必要になります。システムライブラリでは、このことが不可能なことがあり、このため、独自のバージョンの malloc のコンパイルに -xipo=2 を使ってはいけません。

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

関連項目

-xjobs

A.2.132 -xipo_archive=[a]

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

a には、次のいずれかを指定します。

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

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

A.2.133 -xjobs=n

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

A.2.133.1 値

-xjobs には必ず値を指定する必要があります。値を指定しないと、エラー診断が表示され、コンパイルは中止します。

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

デフォルト

コマンド行に複数の -xjobs のインスタンスがある場合、一番右にあるインスタンスが実行されるまで相互に上書きします。

例

次の例に示すコマンドは 2 つのプロセッサを持つシステム上で、-xjobs オプションを指定しないで実行された同じコマンドよりも高速にコンパイルを実行します。

 example% CC -xipo -xO4 -xjobs=3 t1.cc t2.cc t3.cc

A.2.134 -xkeepframe[=[ %all,%none,name,no% name]]

指定した機能 (name) のスタック関連の最適化を禁止します。

%all - すべてのコードのスタック関連の最適化を禁止します。

%none - すべてのコードのスタック関連の最適化を許可します。

このオプションがコマンド行で指定されていないと、コンパイラはデフォルトの -xkeepframe=%none を使用します。このオプションが値なしで指定されると、コンパイラは -xkeepframe=%all を使用します。

A.2.135 -xlang=language[,language]

該当する実行時ライブラリをインクルードし、指定された言語に適切な実行時環境を用意します。

A.2.135.1 値

language は f77、f90、f95、c99 のいずれかとします。

f90 引数と f95 引数は同じです。c99 引数は、cc -xc99=%all を付けてコンパイルされ、CC を付けてリンクされようとしているオブジェクトに対して ISO 9899:1999 C プログラミング言語の動作を呼び出します。

相互の関連性

-xlang=f90 と -xlang=f95 の各オプションは -library=f90 を意味し、-xlang=f77 オプションは -library=f77 を意味します。ただし、-library=f77 と -library=f90 の各オプションは、-xlang オプションしか正しい実行時環境を保証しないので、言語が混合したリンクには不十分です。

言語が混合したリンクの場合、ドライバは次の順序で言語階層を使用してください。

1. C++

2. Fortran 95 (または Fortran 90)

3. FORTRAN 77

4. 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 を使用してください。

警告

-xlang と一緒に -xnolib を使用しないでください。

Fortran 並列オブジェクトを C++ オブジェクトと混合している場合は、リンク行に -mt フラグを指定する必要があります。

関連項目

-library、-staticlib

A.2.136 -xldscope={v}

extern シンボルの定義に対するデフォルトのリンカースコープを変更するには、-xldscope オプションを指定します。デフォルトを変更すると、実装がよりうまく隠蔽されるため、共有ライブラリと実行可能ファイルをより高速かつ安全に使用できるようになります。

A.2.136.1 値

v には、次のいずれかを指定します。

デフォルト

-xldscope を指定しない場合は、コンパイラでは -xldscope=global が指定されます。値を指定しないで -xldscope を指定すると、コンパイラがエラーを出力します。コマンド行にこのオプションの複数のインスタンスがある場合、一番右にあるインスタンスが実行されるまで前のインスタンスが上書きされていきます。

警告

クライアントがライブラリ内の関数をオーバーライドできるようにする場合は必ず、ライブラリの構築時に関数がインラインで生成されないようにしてください。-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 コンパイラオプションを使用することによってインライン化されることがないようにしてください。

関連項目

-xinline、-xO、-xcrossfile

A.2.137 -xlibmieee

例外時に libm が数学ルーチンに対し IEEE 754 値を返します。

libm のデフォルト動作は XPG に準拠します。

A.2.137.1 関連項目

数値計算ガイド

A.2.138 -xlibmil

選択された libm ライブラリルーチンを最適化のためにインライン展開します。

このオプションは C++ インライン関数には影響しません。

一部の libm ライブラリルーチンにはインラインテンプレートがあります。このオプションを指定すると、これらのテンプレートが選択され、現在選択されている浮動小数点オプションとプラットフォームに対してもっとも高速な実行可能コードが生成されます。

A.2.138.1 相互の関連性

このオプションの機能は、-fast オプションを指定した場合にも含まれます。

関連項目

-fast、『数値計算ガイド』

A.2.139 -xlibmopt

最適化された数学ルーチンのライブラリを使用します 。このオプションを使用するときは -fround=nearest を指定することによって、デフォルトの丸めモードを使用する必要があります。

パフォーマンスが最適化された数学ルーチンのライブラリを使用し、より高速で実行できるコードを生成します。通常の数学ライブラリを使用した場合とは、結果が少し異なることがあります。このような場合、異なる部分は通常は最後のビットです。

このライブラリオプションをコマンド行に指定する順序は重要ではありません。

A.2.139.1 相互の関連性

このオプションの機能は、-fast オプションを指定した場合にも含まれます。

関連項目

-fast、-xnolibmopt、-fround

A.2.140 -xlic_lib=sunperf

非推奨。使用しないでください。代わりに、-library=sunperf を指定します。詳細は、「A.2.49 -library=l[ ,l...]」を参照してください。

A.2.141 -xlicinfo

このオプションは、コンパイル時には暗黙的に無視されます。

A.2.142 -xlinkopt[= レベル]

オブジェクトファイル内のあらゆる最適化のほかに、 結果として出力される実行可能ファイルや動的ライブラリに対してリンク時の最適化も行うようコンパイラに指示します。このような最適化は、リンク時にオブジェクトのバイナリコードを解析することによって実行されます。オブジェクトファイルは書き換えられませんが、最適化された実行可能コードは元のオブジェクトコードとは異なる場合があります。

-xlinkopt をリンク時に有効にするには、少なくともコンパイルコマンドで -xlinkopt を使用する必要があります。-xlinkopt を指定しないでコンパイルされたオブジェクトバイナリについても、オプティマイザは限定的な最適化を実行できます。

-xlinkopt は、コンパイラのコマンド行にある静的ライブラリのコードは最適化しますが、コマンド行にある共有 (動的) ライブラリのコードは最適化しません。共有ラ イブラリを構築する場合 (-G でコンパイルする場合) にも、-xlinkopt を使用できます。

A.2.142.1 値

level には、実行する最適化のレベルを 0、1、2 のいずれかで設定します。最適化レベルは、次のとおりです。

コンパイル手順とリンク手順を別々にコンパイルする場合は、両方の手順に -xlinkopt を指定する必要があります。

example% cc -c -xlinkopt a.c b.c
example% cc -o myprog -xlinkopt=2 a.o

レベルパラメータは、コンパイラのリンク時にだけ使用されます。前述の例では、オブジェクトバイナリが指定された 1 のレベルでコンパイルされていても、リンクオプティマイザレベルは 2 です。

デフォルト

レベルパラメータなしで -xlinkopt を使用することは、-xlinkopt=1 を指定することと同じです。

相互の関連性

このオプションは、プログラム全体のコンパイル時に、プロファイルのフィードバックとともに使用されると、もっとも効果的です。プロファイリングによって、コードでもっともよく使用される部分と、もっとも使用されない部分が明らかになるので、それに基づき処理を集中するよう、構築はオプティマイザに指示します。これは、リンク時に実行されるコードの最適な配置が命令のキャッシュミスを低減できるような、大きなアプリケーションにとって特に重要です。このようなコンパイルの例を次に示します。

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.170 –xprofile=p」を参照してください。

警告

-xlinkopt を指定してコンパイルする場合は、-zcombreloc リンカーオプションは指定しないでください。

このオプションを指定してコンパイルすると、リンク時間がわずかに増えます。オブジェクトファイルも大きくなりますが、実行可能ファイルのサイズは変わりません。-xlinkopt と -g を指定してコンパイルすると、デバッグ情報が取り込まれるので、実行可能ファイルのサイズが増えます。

A.2.143 -xloopinfo

このオプションは、並列化されているループとされていないループを示します。通常は、-xautopar オプションとともに使用します。

A.2.144 -xM

指定した C++ プログラムに対してプリプロセッサだけを実行します。その際、メイクファイル用の依存関係を生成してその結果を標準出力に出力します (make ファイルと依存関係についての詳細は make(1) のマニュアルページを参照してください)。

ただし、-xM を指定すると、インクルードされているヘッダーの依存関係のみを報告し、関連付けられているテンプレート定義ファイルの依存関係を報告しません。メイクファイルの中で .KEEP_STATE 機能を使用して、make ユーティリティが使用する .make.state ファイルの中にあるすべての依存関係を使用することもできます。

A.2.144.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

相互の関連性

-xM と -xMF を指定する場合、-xMF で指定したファイルに、コンパイラはすべてのメイクファイルの依存関係情報を書き込みます。プリプロセッサがこのファイルへの書き込みを行うたびに、このファイルは上書きされます。

関連項目

メイクファイルおよび依存関係についての詳細は、make(1S) のマニュアルページを参照してください。

A.2.145 -xM1

/usr/include ヘッダーファイルの依存関係とコンパイラで提供されるヘッダーファイルの依存関係を報告しないという点を除くと、-xM と同様にメイクファイルの依存関係を生成します。

-xM1 と -xMF を指定する場合、-xMF で指定したファイルに、コンパイラはすべてのメイクファイルの依存関係情報を書き込みます。プリプロセッサがこのファイルへの書き込みを行うたびに、このファイルは上書きされます。

A.2.146 -xMD

-xM と同様にメイクファイルの依存関係を生成しますが、コンパイルを続行します。-xMD は、指定されている場合は -o 出力ファイル名から派生したメイクファイルの依存関係情報の出力ファイルを生成します。または、ファイル名接尾辞を .d に置換 (または追加) して、入力元ファイル名を生成します。-xMD と -xMF を指定する場合、-xMF で指定したファイルに、プリプロセッサはすべてのメイクファイルの依存関係情報を書き込みます。複数のソースファイルで -xMD -xMF または -xMD -o filename を使用してコンパイルすることはできず、エラーが生成されます。依存関係ファイルがすでに存在する場合は上書きされます。

A.2.147 -xMF

メイクファイルの依存関係の出力先ファイルを指定するには、このオプションを使用します。コマンド行で -xMF を使用して、複数の入力ファイルのファイル名を個別に指定することはできません。複数のソースファイルで -xMD -xMF または -xMMD -xMF を使用してコンパイルすることはできず、エラーが生成されます。依存関係ファイルがすでに存在する場合は上書きされます。

A.2.148 -xMMD

システムヘッダーファイルを除き、メイクファイルの依存関係を生成するには、このオプションを使用します。これは、-xM1 と同様の機能ですが、コンパイルが続行されます。-xMMD は、指定されている場合は -o 出力ファイル名から派生したメイクファイルの依存関係情報の出力ファイルを生成します。または、ファイル名接尾辞を .d に置換 (または追加) して、入力元ファイル名を生成します。-xMF を指定する場合、コンパイラは代わりに、ユーザーが指定したファイル名を使用します。複数のソースファイルで -xMMD -xMF または -xMMD -o filename を使用してコンパイルすることはできず、エラーが生成されます。依存関係ファイルがすでに存在する場合は上書きされます。

A.2.149 -Merge

SPARC: データセグメントとテキストセグメントをマージします。

オブジェクトファイルのデータは読み取り専用です。また、このデータは ld -N を指定してリンクしないかぎりプロセス間で共有されます。

3 つのオプション -xMerge -ztext -xprofile=collect を一緒に使用するべきではありません。-xMerge を指定すると、静的に初期化されたデータを読み取り専用記憶領域に強制的に配置します。 -ztext を指定すると、位置に依存するシンボルを読み取り専用記憶領域内で再配置することを禁止します。-xprofile=collect を指定すると、書き込み可能記憶領域内で、静的に初期化された、位置に依存するシンボルの再配置を生成します。

A.2.149.1 関連項目

ld(1) のマニュアルページ

A.2.150 -xmaxopt[=v]

このコマンドは、コマンド pragma opt のレベルを指定されたレベルに制限します。v は、off、1、2、3、4、5 のいずれかです。デフォルト値は -xmaxopt=off であり、pragma opt は無視されます。引数を指定せずに -xmaxopt を指定すると、-xmaxopt=5 を指定したことになります。

-xO と -xmaxopt の両方を指定する場合、-xO で設定する最適化レベルが -xmaxopt 値を超えてはいけません。

A.2.151 -xmemalign=ab

(SPARC) データの境界整列についてコンパイラが使用する想定を制御するには、-xmemalign オプションを使用します。境界整列が潜在的に正しくないメモリーアクセスにつながる生成コードを制御し、境界整列が正しくないアクセスが発生したときのプログラム動作を制御すれば、より簡単に SPARC にコードを移植できます。

想定するメモリー境界整列の最大値と、境界整列に失敗したデータがアクセスされた際の動作を指定します。a (境界整列) と b (動作) の両方の値が必要です。a は、想定する最大メモリー境界整列です。b は、境界整列に失敗したメモリーへのアクセスに対する動作です。

コンパイル時に境界整列が判別できるメモリーへのアクセスの場合、コンパイラはそのデータの境界整列に適したロードおよびストア命令を生成します。

境界整列がコンパイル時に決定できないメモリーアクセスの場合、コンパイラは、境界整列を想定して、必要なロード/ストア命令のシーケンスを生成します。

実行時の実際のデータ境界整列が指定された整列に達しない場合、境界整列に失敗したアクセス (メモリー読み取りまたは書き込み) が行われると、トラップが発生します。このトラップに対して可能な応答は 2 つあります。

• OS がトラップを SIGBUS シグナルに変換します。プログラムがこのシグナルを捕捉しなかった場合、プログラムは異常終了します。プログラムがシグナルを捕捉しても、境界整列に失敗したアクセスが成功するわけではありません。

• 境界整列に失敗したアクセスが正常に成功したかのように OS がアクセスを解釈し、プログラムに制御を戻すことによってトラップを処理します。

A.2.151.1 値

次に、-memalign の境界整列と動作の値を示します。

b を i か f のいずれかに設定してコンパイルしたオブジェクトファイルにリンクする場合は、必ず、-xmemalign を指定する必要があります。「3.3.3 コンパイル時とリンク時のオプション」に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。

デフォルト

次のデフォルトの値は、-xmemalign オプションがまったく指定されていない場合にのみ適用されます。

• -xmemalign=8i すべての v8 アーキテクチャーに適用される。

• -xmemalign=8s すべての v9 アーキテクチャーに適用される。

次に、-xmemalign オプションが指定されているが値を持たない場合のデフォルト値を示します。

• -xmemalign=1i すべての -xarch 値に適用される。

例

次の表は、-xmemalign で処理できるさまざまな境界整列の状況とそれに適した -xmemalign 指定を示しています。

A.2.152 -xmodel=[a]

(x86) -xmodel オプションを使用すると、コンパイラで 64 ビットオブジェクトの形式を Solaris x86 プラットフォーム用に変更できます。このオプションは、そのようなオブジェクトのコンパイル時にのみ指定してください。

このオプションは、64 ビット対応の x64 プロセッサで -m64 も指定した場合にのみ有効です。

a には次のいずれかを指定します。

このオプションは累積的ではないため、コンパイラはコマンド行でもっとも右の -xmodel に従って、モデルの値を設定します。

-xmodel を指定しない場合、コンパイラは -xmodel=small とみなします。引数を指定せずに-xmodel を指定すると、エラーになります。

すべての翻訳単位をこのオプションでコンパイルする必要はありません。アクセスするオブジェクトが範囲内にあれば、選択したファイルをコンパイルできます。

すべての Linux システムが、ミディアムモデルをサポートしているわけではありません。

A.2.153 -xnolib

デフォルトのシステムライブラリとのリンクを無効にします。

通常 (このオプションを指定しない場合)、C++ コンパイラは、C++ プログラムをサポートするためにいくつかのシステムライブラリとリンクします。このオプションを指定すると、デフォルトのシステムサポートライブラリとリンクするための -llib オプションが ld に渡されません。

通常、コンパイラは、システムサポートライブラリにこの順序でリンクします。

• 標準モード (デフォルトモード)

-lCstd -lCrun -lm -lc

• 互換モード (-compat)

-lC -lm -lc

-l オプションの順序は重要です。-lm オプションは -lc の前にある必要があります。

-mt コンパイラオプションを指定した場合、コンパイラは通常 -lm でリンクする直前に -lthread でリンクします。

デフォルトでどのシステムサポートライブラリがリンクされるかを知りたい場合は、コンパイルで-dryrun オプションを指定します。たとえば、次のコマンドを実行するとします。

example% CC foo.cc -xarch=v9 -dryrun

前述の出力には次の行が含まれます。

-lCstd -lCrun -lm -lc

A.2.153.1 例

C アプリケーションのバイナリインタフェースを満たす最小限のコンパイルを行う場合、つまり、C サポートだけが必要な C++ プログラムの場合は、次のように指定します。

example% CC– xnolib test.cc –lc

一般的なアーキテクチャー命令を持つシングルスレッドアプリケーションに libm を静的にリンクするには、次のように指定します。

相互の関連性

-xnolib を指定する場合は、必要なすべてのシステムサポートライブラリを手動で一定の順序にリンクする必要があります。システムサポートライブラリは最後にリンクしなければいけません。

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

警告

C++ 言語の多くの機能では、libC (互換モード) または libCrun (標準モード) を使用する必要があります。

このリリースのシステムサポートライブラリは安定していないため、リリースごとに変更される可能性があります。

関連項目

-library、-staticlib、-l

A.2.154 -xnolibmil

コマンド行の -xlibmil を取り消します。

最適化された数学ライブラリとのリンクを変更するには、このオプションを -fast と一緒に使用してください。

A.2.155 -xnolibmopt

数学ルーチンのライブラリを使用しません。

A.2.155.1 例

次の例のように、このオプションはコマンド行で -fast オプションを指定した場合は、そのあとに使用してください。

example% CC –fast –xnolibmopt

A.2.156 -xnorunpath

「A.2.62 -norunpath」 と同じ

A.2.157 -xOlevel

最適化レベルを指定します。大文字 O のあとに数字の 1、2、3、4、5 のいずれかが続きます。一般的に、プログラムの実行速度は最適化のレベルに依存します。最適化レベルが高いほど、実行時のパフォーマンスは向上します。しかし、最適化レベルが高ければ、それだけコンパイル時間が増え、実行可能ファイルが大きくなる可能性があります。

ごくまれに、-xO2 の方がほかの値より実行速度が速くなることがあり、-xO3 の方が -xO4 より早くなることがあります。すべてのレベルでコンパイルを行なってみて、こうしたことが発生するかどうか試してみてください。

メモリー不足になった場合、オプティマイザは最適化レベルを落として現在の手続きをやり直すことによってメモリー不足を回復しようとします。ただし、以降の手続きについては、-xOlevel オプションで指定された最適化レベルを使用します。

-xO には 5 つのレベルがあります。以降では各レベルが SPARC および x86 プラットフォームでどのように動作するかを説明します。

A.2.157.1 値

SPARC プラットフォームの場合

• -xO1 では、最小限の最適化 (ピープホール) が行われます。これはコンパイルの後処理におけるアセンブリレベルでの最適化です。-xO2 や -xO3 を使用するとコンパイル時間が著しく増加する場合や、スワップ領域が不足する場合だけ -xO1 を使用してください。

• -xO2 では、次の基本的な局所的および大域的な最適化が行われます。

  • 帰納的変数の削除

  • 局所的および大域的な共通部分式の削除

  • 計算の簡略化

  • コピーの伝播

  • 定数の伝播

  • ループ不変式の最適化

  • レジスタ割り当て

  • 基本ブロックのマージ

  • 末尾再帰の削除

  • デッドコードの削除

  • 末尾呼び出しの削除

  • 複雑な式の展開

    このレベルでは、外部変数や間接変数の参照や定義は最適化されません。

  -xO3 では、-xO2 レベルで行う最適化に加えて、外部変数に対する参照と定義も最適化されます。このレベルでは、ポインタ代入の影響は追跡されません。volatile で適切に保護されていないデバイスドライバをコンパイルする場合か、シグナルハンドラの中から外部変数を修正するプログラムをコンパイルする場合は、-xO2 を使用してください。一般に、このレベルを使用すると、-xspace オプションと組み合わせないかぎり、コードサイズが大きくなります。

• -xO4 では、-xO3 レベルで行う最適化レベルに加えて、同じファイルに含まれる関数のインライン化も自動的に行われます。インライン化を自動的に行なった場合、通常は実行速度が速くなりますが、遅くなることもあります。一般に、このレベルを使用すると、-xspace オプションと組み合わせないかぎり、コードサイズが大きくなります。

• -xO5 では、最高レベルの最適化が行われます。これを使用するのは、コンピュータのもっとも多くの時間を小さなプログラムが使用している場合だけにしてください。このレベルで使用される最適化アルゴリズムでは、コンパイル時間が増えたり、実行時間が改善されないことがあります。このレベルの最適化によってパフォーマンスが改善される確率を高くするには、プロファイルのフィードバックを使用します。詳細は、「A.2.170 –xprofile=p」を参照してください。