この付録では、C++ コンパイラのコマンド行オプションを詳しく説明します。ここで説明する機能は、特に記載がないかぎりすべてのプラットフォームに適用されます。SPARC システム版の Solaris に特有の機能は SPARC、x86 システム版の Solaris と Linux に特有の機能は x86 として識別されます。Solaris OS のみに限定されている機能には Solaris というマークが付きます。Linux OS のみに限定されている機能には Linux というマークが付きます。Solaris OS に関する言及には、OpenSolaris OS も暗黙的に含まれることに注意してください。
この節では、個別のオプションを説明するために、このマニュアルの「はじめに」に記載した表記上の規則を使用しています。
括弧、中括弧、角括弧、パイプ文字、および省略符号は、オプションの説明で使用されているメタキャラクタです。これらは、オプションの一部ではありません。
簡単に情報を検索できるように、次の見出しに分けてコンパイラオプションを説明しています。オプションがほかのオプションで置き換えられたり、ほかのオプションと同じである場合、詳細についてはほかのオプション説明を参照してください。
表 A–1 オプションの見出し
見出し |
内容 |
---|---|
オプションの定義 |
各オプションのすぐあとには短い定義があります (小見出しはありません)。 |
値 |
オプションに値がある場合は、その値を示します。 |
デフォルト |
オプションに一次または二次のデフォルト値がある場合は、それを示します。 一次のデフォルトとは、オプションが指定されなかったときに有効になるオプションの値です。たとえば、-compat を指定しないと、デフォルトは -compat=5 になります。 二次のデフォルトとは、オプションは指定されたが、値が指定されなかったときに有効になるオプションの値です。たとえば、値を指定せずに -compat を指定すると、デフォルトは -compat=4 になります。 |
拡張 |
オプションにマクロ展開がある場合は、ここに示します。 |
例 |
オプションの説明のために例が必要な場合は、ここに示します。 |
相互の関連性 |
ほかのオプションとの相互の関連性がある場合は、その関係をここに示します。 |
警告 |
オプションの使用について注意がある場合はここに示します。予測できない動作の原因となる操作についてもここに示します。 |
関連項目 |
ここには、参考情報が得られるほかのオプションや文書を示します。 |
「置き換え」、「同じ」 |
そのオプションが廃止され、ほかのもので置き換えられていたり、そのオプションの代わりに別のオプションを使用する方がよい場合は、置き換えるオプションを「置き換え」や「同じ」という表記とともに示しています。このような指示のあるオプションは、将来のリリースでサポートされない可能性があります。 一般的な意味と目的が同じであるオプションが 2 つある場合は、望ましいオプションを示します。たとえば、「-xO と同じです」は、-xO が望ましいオプションであることを示します。 |
次の節では、C++ コンパイラオプションのアルファベット順の一覧と、プラットフォームの制限を示しています。
x86: -xtarget=386 と同じです。このオプションは廃止され、下位互換のためだけに用意されています。
x86: -xtarget=486 と同じです。このオプションは廃止され、下位互換のためだけに用意されています。
ライブラリのリンク形式を、シンボリックか、動的 (共有)、静的 (共有でない) のいずれかから指定します。
-B オプションは同じコマンド行で何回も指定できます。このオプションはリンカー (ld) に渡されます。
Solaris の 64 ビットコンパイル環境では、多くのシステムライブラリは、動的ライブラリのみ使用できます。このため、コマンド行の最後に -Bstatic を使用しないでください。
binding には次のいずれかの値を指定します。
値 |
意味 |
---|---|
dynamic |
まず liblib.so (共有) ファイルを検索するようにリンカーに指示します。これらのファイルが見つからないと、リンカーは liblib.a (静的で共有されない) ファイルを検索します。ライブラリのリンク方式を共有にしたい場合は、このオプションを指定します。 |
static |
-Bstatic オプションを指定すると、リンカーは liblib.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 ビットの Solaris オペレーティングシステムでリンクエラーが生じる可能性があります。この場合、アプリケーションを動的ライブラリとリンクさせる必要があります。
次の例では、libfoo.so があっても libfoo.a がリンクされます。ほかのすべてのライブラリは動的にリンクされます。
example% CC a.o –Bstatic –lfoo –Bdynamic |
C++ コードが含まれているプログラムでは、-Bsymbolic を使用せずに、リンカーのマップファイルを使用してください。
-Bsymbolic を使用すると、異なるモジュール内の参照が、本来 1 つの大域オブジェクトの複数の異なる複製に結合されてしまう可能性があります。
例外メカニズムは、アドレスの比較によって機能します。オブジェクトの複製が 2 つある場合は、アドレスが同一であると評価されず、本来一意のアドレスを比較することで機能する例外メカニズムで問題が発生することがあります。
コンパイルとリンクを別々に行う場合で、コンパイル時に -Bbinding オプションを使用した場合は、このオプションをリンク時にも指定する必要があります。
-nolib、-staticlib、 ld(1)、「11.5 標準ライブラリの静的リンク」、『リンカーとライブラリ』
コンパイルのみ。オブジェクト .o ファイルを作成しますが、リンクはしません。
この オプションは ld によるリンクを抑止し、各ソースファイルに対する .o ファイルを 1 つずつ生成するように、CC ドライバに指示します。コマンド行にソースファイルを 1 つだけ指定する場合には、-o オプションでそのオブジェクトファイルに明示的に名前を付けることができます。
CC -c x.cc と入力すると、x.o というオブジェクトファイルが生成されます。
CC -c x.cc -o y.o と入力すると、y.o というオブジェクトファイルが生成されます。
コンパイラは、入力ファイル (.c、.i) に対するオブジェクトコードを作成する際に、.o ファイルを作業ディレクトリに作成します。リンク手順を省略すると、この .o ファイルは削除されません。
-o filename、-xe
(SPARC) 非推奨、使用しないでください。現在の Solaris オペレーティングシステムのソフトウェアは、SPARC V7 アーキテクチャーをサポートしません。このオプションでコンパイルすると、現在の SPARC プラットフォームでの実行速度が遅いコードが生成されます。-xO を使用して、-xarch、-xchip、および -xcache のコンパイラのデフォルトを利用します。
コンパイラの主要リリースとの互換モードを設定します。このオプションは、__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 オプションで次に示す値を使用して指定します。
-compat オプションには次の値を指定できます。
値 |
意味 |
---|---|
-compat=4 |
(互換モード) 言語とバイナリの互換性を 4.0.1、4.1、4.2 コンパイラに合わせます。__cplusplus プリプロセッサマクロを 1 に、__SUNPRO_CC_COMPAT プリプロセッサマクロを 4 にそれぞれ設定します。 |
-compat=5 |
(標準モード) 言語とバイナリの互換性を ANSI/ISO 標準モード 5.0 コンパイラに合わせます。__cplusplus プリプロセッサマクロを 1997IIL に、__SUNPRO_CC_COMPAT プリプロセッサマクロを 5 にそれぞれ設定します。 |
-compat=g |
(Linux のみ) g++ 言語拡張の認識を有効にし、Linux プラットフォームの g++ とバイナリ互換性があるコードを生成するように、コンパイラに指示します。__cplusplus プリプロセッサマクロを 199711L に、__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 が使用されます。
-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++ 移行ガイド』
C++ 言語の規則では、C++ は、次の条件のうち 1 つがあてはまる場合にインライン化します。
関数が inline キーワードを使用して定義されている
関数がクラス定義の中に (宣言されているだけでなく) 定義されている
関数がコンパイラで生成されたクラスメンバー関数である
C++ 言語の規則では、呼び出しを実際にインライン化するかどうかをコンパイラが選択します。ただし、次の場合を除きます。
関数が複雑すぎる、
+d オプションが選択されている、または
—xOn 最適化レベルが指定されずに —g オプションが選択されている
デフォルトでは、コンパイラは次のコード例で関数 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
プリプロセッサに対してマクロシンボル名 name を def と定義します。
このオプションは、ソースファイルの先頭に #define 指令を記述するのと同じです。-D オプションは複数指定できます。
コンパイラの定義済みマクロのリストについては、CC(1) のマニュアルページを参照してください。
実行可能ファイル全体に対して動的ライブラリを 使用できるかどうか指定します。
このオプションは ld に渡されます。
このオプションは、コマンド行では 1 度だけしか使用できません。
値 |
意味 |
---|---|
-dy |
リンカーで動的リンクを実行します。 |
-dn |
リンカーで静的リンクを実行します。 |
-d オプションを指定しないと、-dy が使用されます。
64 ビットの環境では、多くのシステムライブラリは共有の動的ライブラリとしてのみ利用できます。これらのシステムライブラリには、libm.so および libc.so があります。libm.a と libc.a は提供していません。その結果、-Bstatic と -dn を使用すると 64 ビットの Solaris オペレーティングシステムでリンクエラーが生じる可能性があります。この場合、アプリケーションを動的ライブラリとリンクさせる必要があります。
このオプションを動的ライブラリと組み合わせて使用すると、重大なエラーが発生します。ほとんどのシステムライブラリは、動的ライブラリでのみ使用できます。
ld(1)、『リンカーとライブラリ』
(SPARC) -dalign は、-xmemalign=8s を指定することと同じです。詳細は、「A.2.151 -xmemalign=ab」を参照してください。
x86 プラットフォームでは、このオプションはメッセージを表示せずに無視されます。
あるプログラム単位を -dalign でコンパイルした場合は、プログラムのすべての単位を -dalign でコンパイルします。コンパイルしない場合予期しない結果が生じることがあります。
ドライバによって作成されたコマンドを表示しますが、コンパイルはしません。
このオプションは、コンパイルドライバが作成したサブコマンドの表示のみを行い、実行はしないように CC ドライバ に指示します。
ソースファイルに対してプリプロセッサを実行しますが、コンパイルはしません。
C++ のソースファイルに対してプリプロセッサだけを実行し、結果を stdout (標準出力) に出力するよう CC ドライバに指示します。コンパイルは行われません。したがって .o ファイルは生成されません。
このオプションを使用すると、プリプロセッサで作成されるような行番号情報が出力に含まれます。
ソースコードにテンプレートが含まれている場合に -E オプションの出力をコンパイルするには、-E オプションとともに -template=no%extdef オプションを使用する必要が生じることがあります。アプリケーションコードで「定義分離」テンプレートのソースコードモデルが使用されている場合、それでも -E オプションの出力がコンパイルされない可能性があります。詳細は、テンプレートの章を参照してください。
このオプションは、プリプロセッサの処理結果を知りたいときに便利です。たとえば、次に示すプログラムでは、foo.cc は、「A.2.12.1 例」に示す出力を生成します。
#if __cplusplus < 199711L int power(int, int); #else template <> int power(int, int); #endif int main () { int x; x=power(2, 10); } . |
example% CC -E foo.cc #4 "foo.cc" template < > int power (int, int); int main () { int x; x = power (2, 10); } |
コードの中に「定義分離」モデルのテンプレートが含まれている場合は、このオプションの結果を C++ コンパイラの入力に使用できないことがあります。
-P
互換モード (-compat[=4]) のときに仮想テーブルの生成を制御します。標準モード (デフォルトモード) のときには無効な指定として無視されます。
+e オプションには次の値を指定できます。
値 |
意味 |
---|---|
0 |
仮想テーブルを生成せず、必要とされているテーブルへの外部参照を生成します。 |
1 |
仮想関数を使用して定義したすべてのクラスごとに仮想テーブルを生成します。 |
このオプションを使用してコンパイルする場合は、-features=no%except オプションも使用してください。使用しなかった場合は、例外処理で使用される内部型の仮想テーブルがコンパイラによって生成されます。
テンプレートクラスに仮想関数があると、コンパイラで必要な仮想テーブルがすべて生成され、しかもこれらのテーブルが複写されないようにすることができない場合があります。
『C++ 移行ガイド』
このコマンドは、C++ コンパイラの警告メッセージを無効にします。エラーメッセージには影響しません。このオプションは、-errwarn でゼロ以外の終了状態を発生させるように指定されているかどうかにかかわらず、すべての警告メッセージに適用されます。
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 オプションを指定したときにタグを表示する警告メッセージだけです。
-errtags、-errwarn
C++ コンパイラのフロントエンドで出力される警告メッセージのうち、-erroff オプションで無効にできる、または -errwarn オプションで重大な警告に変換できるメッセージのメッセージタグを表示します。
a には yes または no のいずれかを指定します。デフォルトは -errtags=no です。-errtags だけを指定すると、-errtags=yes を指定するのと同じことになります。
C++ コンパイラのドライバおよび C のコンパイルシステムのほかのコンポーネントから出力されるメッセージにはエラータグが含まれないため、-erroff で無効にしたり、-errwarn で重大なエラーに変換したりすることはできません。
-erroff、-errwarn
指定した警告メッセージが生成された場合に、重大なエラーを出力して C++ コンパイラを終了する場合は、-errwarn を使用します。
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 を指定してエラーなしでコンパイルされるコードでも、コンパイラの次期リリースではエラーを出力してコンパイルされる可能性があります。
-erroff、-errtags、-xwe
このオプションは、 実行ファイルの実行時のパフォーマンスのチューニングで効果的に使用することができるマクロです。-fast は、コンパイラのリリースによって変更される可能性があるマクロで、ターゲットのプラットフォーム固有のオプションに展開されます。-dryrun オプションまたは -xdryrun を使用して -fast の展開を調べ、-fast の該当するオプションを使用して実行可能ファイルのチューニングを行なってください。
このオプションは、コードをコンパイルするマシン上でコンパイラオプションの最適な組み合わせを選択して実行速度を向上するマクロです。
このオプションは、次のコンパイラオプションを組み合わせて、多くのアプリケーションのパフォーマンスをほぼ最大にします。
表 A–4 -fast の拡張
オプション |
SPARC |
x86 |
---|---|---|
-fns |
X |
X |
-fsimple=2 |
X |
X |
-nofstore |
- |
X |
-xarch |
X |
X |
-xbuiltin=%all |
X |
X |
-xcache |
X |
X |
-xchip |
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=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
コンマで区切って指定された C++ 言語のさまざまな機能を、有効または無効にします。
互換モード (-compat[=4]) と標準モード (デフォルトモード) の両方で、次の値の 1 つを指定できます。
表 A–5 互換モードと標準モードでの -features オプション
値 |
意味 |
---|---|
%all |
指定されているモード (互換モードか標準モード) に対して有効なすべての -feature オプションを有効にします。 |
[no%]altspell |
トークンの代替スペル (たとえば、&& の代わりの and) を認識します [しません]。デフォルトは互換モードで no%altspell、標準モードで altspell です。 |
廃止されている構文を許可します [しません]。無効にした場合 (つまり、-features=no%anachronisms)、廃止されている構文は許可されません。デフォルトは anachronisms です。 |
|
ブール型とリテラルを許可します [しません]。有効にした場合、マクロ _BOOL=1 が定義されます。有効にしないと、マクロは定義されません。デフォルトは互換モードで no%bool、標準モードで bool です。 |
|
リテラル文字列を読み取り専用メモリーに入れます [入れません]。デフォルトは互換モードで no%conststrings、標準モードで conststrings です。 |
|
C++ 例外を許可します [しません]。C++ 例外を無効にした場合 (つまり、-features=no%except)、関数に指定された throw は受け入れられますが無視されます。つまり、コンパイラは例外コードを生成しません。キーワード try、throw、および catch は常に予約されています。「8.3 例外の無効化」を参照してください。デフォルトは except です。 |
|
キーワード export を認識します [しません]。デフォルトは互換モードで no%export、標準モードで export です。この機能はまだ実装されていませんが、export キーワードは認識されます。 |
|
ほかの C++ コンパイラによって一般に受け入れられた非標準コードを許可します [しません]。デフォルトは no%extensions です。 |
|
識別子の最初以外の文字に $ を許可します [しません]。デフォルトは no%iddollar です。 |
|
for 文に対して標準準拠の新しい局所スコープ規則を使用します [しません]。デフォルトは互換モードで no%localfor、標準モードで localfor です。 |
|
[no%]mutable |
キーワード mutable を認識します [しません]。デフォルトは互換モードで no%mutable、標準モードで mutable です。 |
(標準モードのみ) ネストしたクラスが、包含するクラスの private メンバーにアクセスできるようにします [しません]。デフォルト: -features=nestedaccess |
|
右辺値または一時値への const 以外の参照のバインドを許可します [しません]。デフォルト: -features=no%rvalueref デフォルトでは、C++ コンパイラは const 以外の参照を一時値または右辺値にバインドできないという規則を適用します。この規則を上書きするには、-features=rvalueref オプションを使用します。 |
|
非ローカル静的オブジェクトの初期設定子を個別の関数に入れます [入れません]。-features=no%split_init を使用すると、コンパイラではすべての初期設定子が 1 つの関数に入れられます。-features=no%split_init を使用すると、コンパイル時間を可能なかぎり費やしてコードサイズを最小化します。デフォルトは split_init です。 |
|
標準 C++ で問題があり、しかもプログラムが予想とは違った動作をする可能性があるか、または将来のコンパイラで拒否される可能性のある ARM 言語構造を許可します [しません]。-features=no%transitions を使用すると、コンパイラではこれらの言語構造をエラーとして扱います。-features=transitions を標準モードで使用すると、これらの言語構造に関してエラーメッセージではなく警告が出されます。-features=transitions を互換モード (-compat[=4]) で使用すると、コンパイラでは +w または +w2 が指定された場合にかぎりこれらの言語構造に関する警告が表示されます。次の構造は移行エラーとみなされます。テンプレートの使用後にテンプレートを再定義する、typename 指示をテンプレートの定義に必要なときに省略する、int 型を暗黙的に宣言する。一連の移行エラーは将来のリリースで変更される可能性があります。デフォルトは transitions です。 |
|
%none |
指定されているモードに対して無効にできるすべての機能を無効にします。 |
標準モード (デフォルトのモード) では、a にはさらに次の値の 1 つを指定できます。
表 A–6 標準モードだけに使用できる -features オプション
値 |
意味 |
---|---|
静的記憶領域にあるオブジェクトを破棄する順序に関する、C++ 標準の必要条件に従います [従いません]。デフォルトは strictdestrorder です。 |
|
[no%]tmplrefstatic |
関数テンプレートからの依存静的関数または静的関数テンプレートの参照を許可します [許可しません]。デフォルトは標準準拠の no%tmplrefstatic です。 |
完全な式の終わりに式によって作成される一時オブジェクトを ANSI/ISO C++ 標準の定義に従って整理します [しません]。-features=no%tmplife が有効である場合は、大多数の一時オブジェクトはそのブロックの終わりに整理されます。デフォルトは compat=4 モードで no%tmplife、標準モードで tmplife です。 |
互換モード (-compat[=4]) では、a にはさらに次の値の 1 つを指定できます。
表 A–7 互換モードだけに使用できる -features オプション
値 |
意味 |
---|---|
operator new と operator delete の配列形式を認識します [しません] (たとえば、operator new [ ] (void*))。これを有効にすると、マクロ __ARRAYNEW=1 が定義されます。有効にしないと、マクロは定義されません。デフォルトは no%arraynew です。 |
|
キーワード explicit を認識します [しません]。デフォルトは no%explicit です。 |
|
キーワード namespace と using を許可します [しません]。デフォルトは no%namespace です。 -features=namespace は、コードを標準モードに変換しやすくするために使用します。このオプションを有効にすると、これらのキーワードを識別子として使用している場合にエラーメッセージが表示されます。キーワード認識オプションを使用すると、標準モードでコンパイルすることなく、追加キーワードが使用されているコードを特定することができます。 |
|
実行時の型識別 (RTTI) を許可します [しません]。dynamic_cast<> および typeid 演算子を使用する場合は、RTTI を有効にする必要があります。-compat=4 mode の場合、デフォルトは no%rtti です。そうでない場合、デフォルトは -features=rtti で、オプション -features=no%rtti は使用できません。 |
[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++ 移行ガイド』
コンパイラによってリンカーとコンパイラのエラーメッセージに通常適用されるフィルタリングを制御します。
filter は次の値のいずれかである必要があります。
表 A–8 -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
(SPARC) 浮動小数点の積和演算 (FMA) 命令の自動生成を有 効にします。-fma=none を指定すると、これらの命令の生成を無効にします。-fma=fused を指定すると、コンパイラは浮動小数点の積和演算 (FMA) 命令を使用して、コードのパフォーマンスを改善する機会を検出しようとします。
デフォルトは -fma=none です。
コンパイラが積和演算 (FMA) 命令を生成するための最小要件は、-xarch=sparcfmaf と、最適化レベルが -xO2 以上であることです。積和演算 (FMA) 命令をサポートしていないプラットフォームでプログラムが 実行されないようにするため、コンパイラは積和演算 (FMA) 命令を生成する場合、バイナリプログラムにマーク付けをします。
積和演算 (FMA) により、積と和 (乗算と加算) の間で中間の丸め手順が排除されます。その結果、-fma=fused を指定してコンパイルしたプログラムは、精度は減少ではなく増加する傾向にありますが、異なる結果になることがあります。
浮動小数点オーバーフローのハードウェアによるトラップ、ゼロによる除算、無効演算の例外を有効にします。これらの結果は、SIGFPE シグナルに変換されます。プログラムに SIGFPE ハンドラがない場合は、メモリーダンプを行なってプログラムを終了します (ただし、コアダンプのサイズをゼロに制限した場合を除きます)。
SPARC: さらに、-fnonstd は SPARC 非標準浮動小数点を選択します。
-fnonstd を指定しないと、IEEE 754 浮動小数点演算例外が起きても、プログラムは異常終了しません。アンダーフローは段階的です。
x86: -fnonstd は -ftrap=common に拡張されます。
SPARC: -fnonstd は -fns -ftrap=common に拡張されます。
-fns、-ftrap=common、『数値計算ガイド』
SPARC: SPARC 非標準浮動小数点モードを有効または無効にします。
-fns=yes (または-fns) を指定すると、プログラムが実行を開始するときに、非標準浮動小数点モードが有効になります。
このオプションを使うと、-fns を含むほかのマクロオプション (-fast など) のあとで非標準と標準の浮動小数点モードを切り替えることができます。
一部の SPARC デバイスでは、非標準浮動小数点モードで「段階的アンダーフロー」が無効にされ、非正規の数値を生成する代わりに、小さい値がゼロにフラッシュされます。さらに、このモードでは、非正規のオペランドが報告なしにゼロに置き換えられます。
段階的アンダーフローや、非正規の数値をハードウェアでサポートしない SPARC デバイスでは、-fns=yes (または -fns) を使用すると、プログラムによってはパフォーマンスが著しく向上することがあります。
(x86) SSE flush-to-zero モードを選択します。利用可能な場合には、denormals-are-zero モードが選択されます。
このオプションは、非正規数の結果をゼロにフラッシュします。また利用可能な場合には、非正規数オペランドもゼロとして扱われます。
このオプションは、SSE や SSE2 命令セットを利用しない従来の x86 浮動小数点演算には影響しません。
-fns オプションには次の値を指定できます。
表 A–9 -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 オプションでコンパイルする必要があります。コンパイルしない場合、予期しない結果が生じることがあります。
このオプションは、SPARC プラットフォームでメインプログラムをコンパイルするときしか有効ではありません。x86 プラットフォームでは、このオプションは無視されます。
-fns=yes (または -fns) オプションを使用したときに、通常は IEEE 浮動小数点トラップハンドラによって管理される浮動小数点エラーが発生すると、次のメッセージが返されることがあります。
『数値計算ガイド』、ieee_sun(3M)
x86: デフォルト以外の浮動小数点精度モードを設定します。
-fprecision オプションを指定すると、FPU (Floating Point Unit) 制御ワードの丸め精度モードのビットが設定されます。これらのビットは、基本演算 (加算、減算、乗算、除算、平方根) の結果をどの精度に丸めるかを制御します。
p は次のいずれかでなければいけません。
表 A–10 -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 システムでも無視されます。
起動時に IEEE 丸めモードを有効にします。
このオプションは、次に示す IEEE 754 丸めモードを設定します。
定数式を評価する時にコンパイラが使用できる。
プログラム初期化中の実行時に設定される。
内容は、ieee_flags サブルーチンと同じです。これは実行時のモードを変更するために使用します。
r には次の値のいずれかを指定します。
表 A–11 -fround の値
値 |
意味 |
---|---|
nearest |
もっとも近い数値に丸め、中間値の場合は偶数にします。 |
tozero |
ゼロに丸めます。 |
negative |
負の無限大に丸めます。 |
positive |
正の無限大に丸めます。 |
-fround オプションを指定しないと、丸めモードは -fround=nearest になります。
1 つのルーチンを -fround=r でコンパイルした場合は、そのプログラムのすべてのルーチンを同じ -fround=r オプションでコンパイルする必要があります。コンパイルしない場合、予期しない結果が生じることがあります。
このオプションは、メインプログラムをコンパイルするときにだけ有効です。
このオプションで浮動小数点演算に影響する前提を設けることにより、オプティマイザで行う浮動小数点演算が簡略化されます。
n を指定する場合、0、1、2 のいずれかにしなければいけません。
表 A–12 -fsimple の値
-fsimple を指定しないと、コンパイラーは -fsimple=0 を使用します。
-fsimple を指定しても n の値を指定しないと、-fsimple=1 が使用されます。
-fast は -fsimple=2 を意味します。
このオプションによって、IEEE 754 に対する適合性が損なわれることがあります。
-fast
最適化が精度に与える影響の詳細は、『Techniques for Optimizing Applications: High Performance Computing』(Rajat Garg、Ilya Sharapov 共著) をお読みください。
このオプションを指定すると、コンパイラは、次の場合に浮動小数点の式や関数の値を代入式の左辺の型に変換します。つまり、その値はレジスタにそのままの型で残りません。
式や関数を変数に代入する。
式をそれより短い浮動小数点型にキャストする。
このオプションを解除するには、オプション -nofstore を使用してください。
丸めや切り捨てによって、結果がレジスタの値から生成される値と異なることがあります。
-nofstore
起動時の IEEE トラップ モードを設定します。ただし、SIGFPE ハンドラは組み込まれません。トラップの設定と SIGFPE ハンドラの組み込みを同時に行うには、ieee_handler(3M) か fex_set_handling(3M) を使用します。複数の値を指定すると、それらの値は左から右に処理されます。
t には次の値のいずれかを指定できます。
表 A–13 -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 を使用してください。
ieee_handler(3M) および fex_set_handling(3M) のマニュアルページ
コマンド行で指定したソースファイルはすべて、デフォルトで -xcode=pic13 オプションでコンパイルされます。
テンプレートが含まれていて、-instances=extern オプションを使用してコンパイルされたファイルから共有ライブラリを構築すると、.o ファイルにより参照されているテンプレートインスタンスがすべてテンプレートキャッシュから自動的に含められます。
コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションと -G オプションを組み合わせて共有ライブラリを作成した場合は、生成された共有オブジェクトとのリンクでも、必ず同じオプションを指定してください。
「A.2.118 -xcode=a」で推奨しているように、共有オブジェクトの作成では、-xarch=v9 を付けてコンパイルしたすべてのオブジェクトファイルもまた、明示的な -xcode 値を付けてコンパイルする必要があります。
-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 動的 (共有) ライブラリの構築」
dbx(1) または Debugger によるデバッグおよびパフォーマンスアナライザ analyzer(1) による解析用のシンボルテーブル情報を追加生成します。
コンパイラとリンカーに、デバッグとパフォーマンス解析に備えてファイルとプログラムを用意するように指示します。
これには、次の処理が含まれています。
オブジェクトファイルと実行可能ファイルのシンボルテーブル内に、詳細情報 (スタブ) を生成する。
「補助関数」を生成する。デバッガはこれを呼び出して、その一部の機能を実現する。
最適化レベルが指定されていない場合は、関数のインライン生成を無効にします。つまり、最適化レベルも指定されていない場合、このオプションを使用すると +d オプションが指定されていることになります。-O レベルまたは -xO レベルが指定された -g では、インラインは無効になりません。
特定のレベルの最適化を無効にする。
このオプションと -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 コマンドによるデバッグ』(スタブの詳細について)『プログラムのパフォーマンス解析』
デバッグ用のコンパイルとリンクを行いますが、インライン展開は行いません。
このオプションは、+d が無効になり、インライン化された関数に dbx がステップインできなくなることを除けば、-g と同じです。
-xO3 以下の最適化レベルで -g0 を指定すると、ほとんど完全な最適化と可能なかぎりのシンボル情報を取得することができます末尾呼び出しの最適化とバックエンドのインライン化は無効です。
+d、-g、『dbx コマンドによるデバッグ』
現在のコンパイルに含まれている #include ファイルのパス名を標準エラー出力 (stderr) に 1 行に 1 つずつ出力します。
生成する動的共有ライブラリに名前 name を割り当てます。動的共有ライブラリ
これはリンカー用のオプションで、ld に渡されます。通常、-h のあとに指定する name (名前) は、-o のあとに指定する名前と同じでなければいけません。-h と name の間には、空白文字を入れても入れなくてもかまいません。
コンパイルの時ローダーは、作成対象の共有動的ライブラリに、指定の名前を割り当てます。この名前は、ライブラリのイントリンシック名として、ライブラリファイルに記録されます。-hname (名前) オプションを指定しないと、イントリンシック名はライブラリファイルに記録されません。
実行可能ファイルはすべて、必要な共有ライブラリファイルのリストを持っています。実行時のリンカーは、ライブラリを実行可能ファイルにリンクするとき、ライブラリのイントリンシック名をこの共有ライブラリファイルのリストの中にコピーします。共有ライブラリにイントリンシック名がないと、リンカーは代わりにその共有ライブラリファイルのパス名を使用します。
-h オプションを指定せずに共有ライブラリを構築する場合は、実行時のローダーはライブラリのファイル名のみを検索します。ライブラリを、同じファイル名を持つほかのライブラリに置換することもできます。共有ライブラリにイントリンシック名がある場合は、ローダーはファイルを読み込むときにイントリンシック名を確認します。イントリンシック名が一致しない場合は、ローダーは置換ファイルを使用しません。
example% CC -G -o libx.so.1 -h libx.so.1 a.o b.o c.o |
#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 標準ヘッダーの実装」も参照してください。
-I- オプションを指定すると、デフォルトの検索規則が無効になります。
-library=no%Cstd を指定すると、その検索パスに C++ 標準ライブラリに関連付けられたコンパイラで提供されるヘッダーファイルがコンパイラでインクルードされません。「11.7 C++ 標準ライブラリの置き換え」を参照してください。
-ptipath が使用されていないと、コンパイラは -Ipathname でテンプレートファイルを検索します。
-ptipathの代わりに -Ipathname を使用します。
このオプションは、置き換えられる代わりに蓄積されます。
コンパイラがインストールされている位置の /usr/include、 /lib、/usr/lib を検索ディレクトリに指定しないでください。
-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 標準ヘッダーの実装」も参照してください。
次の例は、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 を検索ディレクトリに指定しないでください。
リンカー ld は LD_LIBRARY_PATH の設定を無視します。
このオプションを指定すると、コンパイラは 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 には次のいずれかを指定します。
表 A–14 -instances の値
値 |
意味 |
---|---|
extern |
必要なすべてのインスタンスをテンプレートリポジトリの comdat セクション内に置き、それらに対して大域リンケージを行います。リポジトリのインスタンスが古い場合は、再びインスタンス化されます。 注: コンパイルとリンクを別々に行うとき、コンパイル処理で -instance=extern を指定した場合には、リンク処理でも -instance=extern を指定する必要があります。 |
explicit |
明示的にインスタンス化されたインスタンスを現在のオブジェクトファイルに置き、それらに対して大域リンケージを行います。必要なインスタンスがほかにあっても生成しません。 |
global |
必要なすべてのインスタンスを現在のオブジェクトファイルに置き、それらに対して大域リンケージを行います。 |
semiexplicit |
明示的にインスタンス化されたインスタンスを現在のオブジェクトファイルに置き、それらに対して大域リンケージを行います。明示的なインスタンスにとって必要なすべてのインスタンスを現在のオブジェクトファイルに置き、それらに対して大域リンケージを行います。必要なインスタンスがほかにあっても生成しません。 |
static |
注: -instances=static は非推奨です。-instances=global が static の利点をすべて備えており、かつ欠点を備えていないので、-instances=static を使用する理由はなくなっています。このオプションは、このバージョンのコンパイラには存在しない、旧リリースのコンパイラにあった問題を克服するために用意されていました。 必要なすべてのインスタンスを現在のオブジェクトファイルに置き、それらに対して静的リンケージを行います。 |
-instances を指定しないと、-instances=global が想定されます。
このオプションを使用すると、ライブラリ (共有、静的) と現在のオブジェクトで重複するテンプレートインスタンスの生成が禁止されます。一般に、ライブラリを使用するプログラムが多数のインスタンスを共有する場合、-instlib=filename を指定して、コンパイル時間の短縮を試みることができます。
既存のテンプレートインスタンスが入っていることがわかっているライブラリを指定するには、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
x86: -Kpic と同じです。
このオプションは、共有ライブラリを構築するためにソースファイルをコンパイルするときに使用します。大域データへの各参照は、大域オフセットテーブルにおけるポインタの間接参照として生成されます。各関数呼び出しは、手続きリンケージテーブルを通して PC 相対アドレス指定モードで生成されます。
x86: 位置に依存しないコードを使ってコンパイルします。
このオプションは、共有ライブラリを構築するためにソースファイルをコンパイルするときに使用します。大域データへの各参照は、大域オフセットテーブルにおけるポインタの間接参照として生成されます。各関数呼び出しは、手続きリンケージテーブルを通して PC 相対アドレス指定モードで生成されます。
コンパイル中に作成されたすべての一時ファイルを残します。
このオプションを -verbose=diags と一緒に使用すると、デバッグに便利です。
–v、–verbose
ライブラリを検索するディレクトリに、path ディレクトリを追加します。
このオプションは ld に渡されます。コンパイラが提供するディレクトリよりも path が先に検索されます。
このオプションは、置き換えられる代わりに蓄積されます。
コンパイラがインストールされている位置の /usr/include、 /lib、/usr/lib を検索ディレクトリに指定しないでください。
ライブラリ liblib.a または liblib.so をリンカーの検索ライブラリに追加します。
このオプションは ld に渡されます。通常のライブラリは、名前が liblib.a か liblib.so の形式です (lib と .a または .so の部分は必須です)。このオプションでは lib の部分を指定できます。コマンド行には、ライブラリをいくつでも指定できます。指定したライブラリは、-Ldir で指定された順に検索されます。
このオプションはファイル名のあとに使用してください。
このオプションは、置き換えられる代わりに蓄積されます。
正しい順序でライブラリが検索されるようにするには、安全のため、必ずソースとオブジェクトのあとに -lx を使用してください。
libthread とリンクする場合は、ライブラリを正しい順序でリンクするために -lthread ではなく -mt を使用してください。
-Ldir、-mt、「10.4.8 アプリケーションの例」、『 Tools.h++ クラスライブラリリファレンスマニュアル』
l に指定した、CC が提供するライブラリを、コンパイルとリンクに組み込みます。
互換モード (-compat[-4]]) の場合、l には次のいずれかを指定します。
表 A–15 互換モードに使用できる -library オプション
値 |
意味 |
---|---|
[no%]f77 |
非推奨。-xlang=f77 を使用してください。 |
[no%]f90 |
非推奨。-xlang=f90 を使用してください。 |
[no%]f95 |
非推奨。-xlang=f95 を使用してください。 |
[no%]rwtools7 |
古い iostream Tools.h++ Version 7 を使用します [しません]。 |
[no%]rwtools7_dbg |
デバッグ可能な Tools.h++ Version 7 を使用します [しません]。 |
[no%]complex |
複素数の演算に libcomplex を使用します [しません]。 |
[no%]interval |
非推奨。使用しないでください。-xia を使用してください。 |
[no%]libC |
C++ サポートライブラリ libC を使用します [しません]。 |
[no%]gc |
ガベージコレクション libgc を使用します [しません]。 |
Sun Performance Library を使用します [しません]。 |
|
%none |
libC の場合を除いて C++ ライブラリを一切使用しません。 |
標準モード (デフォルトモード) の場合、l には次のいずれかを指定します。
表 A–16 標準モードに使用できる -library オプション
値 |
意味 |
---|---|
[no%]f77 |
非推奨。-xlang=f77 を使用してください。 |
[no%]f90 |
非推奨。-xlang=f90 を使用してください。 |
[no%]f95 |
非推奨。-xlang=f95 を使用してください。 |
[no%]rwtools7 |
古い iostream Tools.h++ Version 7 を使用します [しません]。 |
[no%]rwtools7_dbg |
デバッグ可能な 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.3 STLport」を参照してください。 |
[no%]stlport4_dbg |
STLport のデバッグ可能なライブラリを使用します [しません]。 |
[no%]sunperf |
Sun Performance Library を使用します [しません]。 |
デフォルトの libCstd の代わりに Apache stdcxx バージョン 4 C++ 標準ライブラリを Solaris で使用します [しません]。このオプションにより、-mt オプションも暗黙的に設定されます。stdcxx ライブラリには、マルチスレッドモードが必要です。このオプションは、コンパイルのたびに、およびアプリケーション全体のリンクコマンドで一貫して使用する必要があります。-library=stdcxx4 を使用してコンパイルされたコードは、デフォルトの -library=Cstd または省略可能な -library=stlport4 を使用してコンパイルされたコードと同じプログラムでは使用できません。 |
|
%none |
libCrun の場合を除いて C++ ライブラリを使用しません。 |
互換モード (-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++ 標準ライブラリの置き換え」を参照してください。
コンパイルされたバイナリオブジェクトのメモリーモデルを指定します。
-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 も参照してください。
オブジェクトファイルの .comment セクションから重複文字列を削除します。-mc オプションを使用すると、mcs -c コマンドが呼び出されます。詳細は、mcs(1) のマニュアルページを参照してください。
以前のバージョンのコンパイラ用に作成されたソースコードの移行に関する情報の参照先を表示します。
このオプションは次のリリースでは存在しなくなる可能性があります。
SPARC: 通常はエラーになる、メモリー中の境界整列の誤ったデータを許可します。次に例を示します。
char b[100]; int f(int * ar) { return *(int *) (b +2) + *ar; } |
このオプションは、プログラムの中に正しく境界整列されていないデータがあることをコンパイラに知らせます。したがって、境界整列が正しくない可能性があるデータに対しては、ロードやストアを非常に慎重に、つまり 1 度に 1 バイトずつ行う必要があります。このオプションを使用すると、実行速度が大幅に低下することがあります。低下する程度はアプリケーションによって異なります。
SPARC プラットフォーム上で #pragma pack を使用して、型のデフォルトの境界整列よりも密に配置するには、アプリケーションのコンパイルとリンクの両方で -misalign オプションを指定する必要があります。
境界整列が正しくないデータは、実行時に ld のトラップ機構によって処理されます。misalign オプションとともに最適化フラグ (-xO{1|2|3|4|5} またはそれと同等のフラグ) を使用すると、ファイル境界整列の正しくないデータを正しい境界に整列に合わせるための命令がオブジェクトに挿入されます。この場合には、実行時不正境界整列トラップは生成されません。
できれば、プログラムの境界整列が正しい部分と境界整列が誤った部分をリンクしないでください。
コンパイルとリンクを別々に行う場合は、-misalign オプションをコンパイルコマンドとリンクコマンドの両方で指定する必要があります。
オブジェクトファイルの .comment セクションからすべての文字列を削除します。string が与えられた場合、そのセクションに string を埋め込みます。文字列に空白が含まれている場合は、文字列を引用符で囲む必要があります。このオプションを使用すると、mcs -d [-a string] が呼び出されます。
このオプションを使用して、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 と同じです。
–xnolib、Solaris 『Multithreaded Programming Guide』、および『Linker and Libraries Guide』
-xtarget=native と同じです。
このオプションを指定すると、次のどちらの場合でも、コンパイラは浮動小数点の式や関数の値を代入式の左辺の型に変換しません。つまり、レジスタの値はそのままです。
式や関数を変数に割り当てる
または
式や関数をそれより短い浮動小数点型にキャストする
-fstore
ライセンスを確保できない場合、コンパイラはコンパイル要求を待ち行列に入れず、コンパイルもしないで終了します。メイクファイルのテストには、ゼロ以外の状態が返されます。このオプションは廃止されたので無視します。
実行可能ファイルに共有ライブラリへの実行時検索パスを組み込みません。
実行可能ファイルが共有ライブラリを使用する場合、コンパイラは通常、実行時のリンカーに対して共有ライブラリの場所を伝えるために構築を行なったパス名を知らせます。これは、ld に対して -R オプションを渡すことによって行われます。このパスはコンパイラのインストール先によって決まります。
このオプションは、プログラムで使用される共有ライブラリへのパスが異なる顧客に出荷される実行可能ファイルの構築にお勧めします。「11.6 共有ライブラリの使用」 を参照してください。
共有ライブラリをコンパイラのインストールされている位置で使用し、かつ -norunpath を使用する場合は、リンク時に -R オプションを使うか、または実行時に環境変数 LD_LIBRARY_PATH を設定して共有ライブラリの位置を明示しなければいけません。そうすることにより、実行時リンカーはその共有ライブラリを見つけることができます。
このリリースから、-O マクロは、-xO2 でなく、-xO3 に展開されます。
このデフォルトの変更によって、実行時のパフォーマンスが向上します。ただし、あらゆる変数を自動的に volatile と見なすことを前提にするプログラムの場合、 -xO3 は不適切なことがあります。このことを前提とする代表的なプログラムとしては、専用の同期方式を実装するデバイスドライバや古いマルチスレッドアプリケーションがあります。回避策は、-O ではなく、-xO2 を使ってコンパイルすることです。
出力ファイルまたは実行可能ファイルの名前を filename (ファイル名) に指定します。
コンパイラは、テンプレートインスタンスを格納する必要がある場合には、出力ファイルのディレクトリにあるテンプレートリポジトリに格納します。たとえば、次のコマンドでは、コンパイラはオブジェクトファイルを ../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 ドライバはソースファイルには上書きしないため、ソースファイルとは異なるファイルを指定する必要があります。
+p を指定しないと、コンパイラは非標準のプリプロセッサの表明を認識します。
+p を指定している場合は、次のマクロは定義されません。
sun
unix
sparc
i386
ソースの前処理だけでコンパイルはしません (接尾辞 .i のファイルを出力します)。
このオプションを指定すると、プリプロセッサが出力するような行番号情報はファイルに出力されません。
-E
廃止。「A.2.165 -xpg」を参照してください。
x86: -xtarget=pentium と置き換えられています。
x86: -Kpic と同じです。
SPARC: -xcode=pic13 と同じです。
x86: -Kpic と同じです。
-template=wholeclass と同じです。
テンプレートソース用の検索ディレクトリを追加指定します。
このオプションは -Ipathname (パス名) によって設定された通常の検索パスに代わるものです。-ptipath (パス) フラグを使用した場合、コンパイラはこのパス上にあるテンプレート定義ファイルを検索し、-Ipathname フラグを無視します。
-ptipath よりも -Ipathname を使用すると混乱が起きにくくなります。
このオプションは、置き換えられる代わりに蓄積されます。
–Ipathname および「7.5.2 定義検索パス」
-instances=static と同じです。
このオプションは廃止されたため、コンパイル時には無視されます。
-ptr オプションは存在しても無視されますが、すべてのコンパイルコマンドから削除するようにしてください。これは将来のリリースで、-ptr が以前とは異なる動作のオプションとして再実装される可能性があるためです。
リポジトリのディレクトリについては、「7.4 テンプレートリポジトリ」を参照してください。
-verbose=template と同じです。
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 オプションの順序が変わり、不正な結果が生じる可能性があります。
phase には、次の値のいずれか 1 つを指定します。
表 A–17 -Qoption の値
SPARC |
x86 |
---|---|
ccfe |
ccfe |
iropt |
iropt |
cg |
ube |
CClink |
CClink |
ld |
ld |
— |
ir2hf |
fbe |
fbe |
次に示すコマンド行では、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 |
-Qoption と同じです。
CC ドライバに sourcetype (ソースタイプ) 型のソースコードを生成するよう指示します。
sourcetype に指定する接尾辞の定義は次のとおりです。
表 A–18 -Qproduce の値
接尾辞 |
意味 |
---|---|
.i |
ccfe が作成する前処理済みの C++ のソースコード |
.o |
コードジェネレータが作成するオブジェクトファイル |
.s |
cg が作成するアセンブラソース |
-Qproduce と同じです。
動的ライブラリの検索パスを実行可能ファイルに組み込みます。
このオプションは ld に渡されます。
-R オプションを指定しないと、出力オブジェクトに記録され、実行時リンカーに渡されるライブラリ検索パスは、-xarch オプションで指定されたターゲットアーキテクチャー命令によって異なります (-xarch を指定しないと、-xarch=generic が想定されます)。
コンパイラが想定するデフォルトのパスを表示するには、—dryrun と —R の各オプションをリンカー ld に渡して出力を検査します。
このオプションは、置き換えられる代わりに蓄積されます。
LD_RUN_PATH 環境変数が設定されている場合に、-R オプションを指定すると、-R に指定したパスが検索され、LD_RUN_PATH のパスは無視されます。
-norunpath、『リンカーとライブラリ』
コンパイルしてアセンブリコードだけを生成します。
CC ドライバはプログラムをコンパイルして、アセンブリソースファイルを作成します。しかし、プログラムのアセンブルは行いません。このアセンブリソースファイル名には、.s という接尾辞が付きます。
出力する実行可能ファイルからシンボリック情報をすべて削除します。このオプションは ld に渡されます。
-library オプションで指定されている C++ ライブラリ (そのデフォルトも含む)、-xlang オプションで指定されているライブラリ、-xia オプションで指定されているライブラリのうち、どのライブラリが静的にリンクされるかを指定します。
l には、次の値のいずれか 1 つを指定します。
表 A–19 -staticlib の値
値 |
意味 |
---|---|
[no%]library |
library を静的にリンクします [しません]。library に有効な値は、-library で有効なすべての値 (%all と %none を除く)、-xlang で有効なすべての値、および (-xia に関連して使用される) interval です。 |
%all |
-library オプション で指定されているすべてのライブラリと、-xlang オプションで指定されているすべてのライブラリ、-xia をコマンド行で指定している場合は区間ライブラリを静的にリンクします。 |
%none |
-library オプションと -xlang オプションに静的に指定されているライブラリをリンクしません。-xia をコマンド行に指定した場合は、区間ライブラリを静的にリンクしません。 |
-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 標準ライブラリの静的リンク」
C++ の iostream と C の stdio の同期が原因で実行時のパフォーマンスが低下する場合は、このオプションを使用してください。同期が必要なのは、同じプログラム内で iostream を使って cout に書き込み、stdio を使って stdout に書き込みを行う場合だけです。C++ 規格では同期が求められており、このため C++ コンパイラはデフォルトで同期を有効にします。ただし、しばしば、アプリケーションのパフォーマンスは同期なしの方が良くなることがあります。cout と stdout の一方にしか書き込みを行わない場合は、-sync_stdio=no オプションを使って同期を無効にすることができます。
-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! : |
同期なしの場合、出力が混乱します。
このオプションは、ライブラリではなく実行可能ファイルのリンクでのみ有効です。
一時ファイルのディレクトリを定義します。
このオプションは、コンパイル中に生成される一時ファイルを格納するディレクトリのパス名を指定します。コンパイラは -temp によって設定された値を、TMPDIR の値より優先します。
-keeptmp
opt は次のいずれかの値である必要があります。
表 A–20 -template の値
値 |
意味 |
---|---|
[no%]extdef |
別のソースファイルからテンプレート定義を検索します [しません]。no%extdef を使用すると、コンパイラは _TEMPLATE_NO_EXTDEF を事前定義します。 |
[no%]geninlinefuncs |
明示的にインスタンス化されたクラステンプレートのための非参照インラインメンバー関数を生成します [しません]。 |
[no%]wholeclass |
コンパイラに対し、使用されている関数だけインスタンス化するのではなく、テンプレートクラス全体をインスタンス化する [しない] ように指示します。クラスの少なくとも 1 つのメンバーを参照しなければいけません。そうでない場合は、コンパイラはそのクラスのどのメンバーもインスタンス化しません。 |
-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 テンプレート定義の検索」
実行時に重大エラーが発生した場合にスタックトレースを発行します。
-traceback オプションを指定すると、プログラムによって特定のシグナルが生成された場合に、実行可能ファイルで stderr へのスタックトレースが発行されて、コアダンプが実行され、終了します。複数のスレッドが 1 つのシグナルを生成すると、スタックトレースは最初のスレッドに対してのみ生成されます。
追跡表示を使用するには、リンク時に -traceback オプションをコンパイラコマンド行に追加します。このオプションはコンパイル時にも使用できますが、実行可能バイナリが生成されない場合無視されます。-traceback を -G とともに使用して共有ライブラリを作成すると、エラーが発生します。
表 A–21 -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 と同義になります。
注: コアダンプが不要な場合は、次を使用して coredumpsize 制限を 0 に設定できます。
% limit coredumpsize 0 |
-traceback オプションは、実行時のパフォーマンスに影響しません。
このオプションは、コマンド行に指定された (CC ドライバによって暗黙的に挿入され るものも含む) -D オプションによって作成されるマクロシンボル name の初期定義を削除します。ほかの定義済みマクロや、ソースファイル内のマクロ定義が影響を受けることはありません。
CC ドライバにより定義される -D オプションを表示するには、コマンド行に -dryrun オプションを追加します。
次のコマンドでは、事前に定義されているシンボル __sun を未定義にします。#ifdef (__sun) のような foo.cc 中のプリプロセッサ文では、シンボルが未定義であると検出されます。
example% CC -U__sun foo.cc |
コマンド行には複数の -U オプションを指定できます。
すべての -U オプションは、存在している任意の -D オプションのあとに処理されます。つまり、同じ name がコマンド行上の -D と -U の両方に指定されている場合は、オプションが表示される順序にかかわらず name は未定義になります。
-D
-verbose=version と同じです。
非推奨。使用しないでください。
delete[] を使用する式に対し、実行時ライブラリ関数 _vector_delete_ の呼び出しを生成する代わりに _vector_deletex_ の呼び出しを生成します。関数 _vector_delete_ は、削除するポインタおよび各配列要素のサイズという 2 つの引数をとります。
関数 _vector_deletex_ は _vector_delete_ と同じように動作しますが、3 つ目の引数として そのクラスのデストラクタのアドレスをとります。この引数は Sun 以外のベンダーが使用するためのもので、関数では使用しません。
コンパイラは、delete[] を使用する式に対して _vector_delete_ の呼び出しを生成します。
これは旧式フラグであり、将来のリリースでは削除されます。Sun 以外のベンダーからソフトウェアを購入し、ベンダーがこのフラグの使用を推奨していないかぎり、このオプションは使用しないでください。
v には、次に示す値の 1 つを指定します。
表 A–22 -verbose の値
値 |
意味 |
---|---|
[no%]diags |
各コンパイル段階が渡すコマンド行を表示します [しません]。 |
[no%]template |
テンプレートインスタンス化 verbose モード (「検証モード」ともいう) を起動します [しません]。verboseモードはコンパイル中にインスタンス化の各段階の進行を表示します。 |
[no%]version |
CC ドライバに対し、呼び出したプログラムの名前とバージョン番号を表示するよう指示します [しません]。 |
%all |
前述のすべてを呼び出します。 |
%none |
-verbose=%none は -verbose=no%template,no%diags,no%version を指定することと同じです。 |
-verbose を指定されない場合、-verbose=%none が想定されます。
このオプションは、置き換えられる代わりに蓄積されます。
意図しない結果が生じる可能性のあるコードを特定します。+w オプションは、関数が大きすぎてインライン化できない場合、および宣言されたプログラム要素が未使用の場合に警告を生成しません。これらの警告は、ソース中の実際の問題を特定するものではないため、開発環境によっては不適切です。そのような環境では、+w でこれらの警告を生成しないようにすることで、+w をより効果的に使用することができます。これらの警告は、+w2 オプションの場合は生成されます。
次のような問題のありそうな構造について、追加の警告を生成します。
移植性がない
間違っていると考えられる
効率が悪い
+w オプションを指定しない場合、コンパイラは必ず問題となる構造についてのみ警告を出力します。
–w、+w2
+w で発行される警告に加えて、技術的な違反についての警告を発行します。これは、危険性はないが、プログラムの移植性を損なう可能性がある違反に対するものです。
+w2 オプションは、システムのヘッダーファイル中で実装に依存する構造が使用されている場合をレポートしなくなりました。システムヘッダーファイルが実装であるため、これらの警告は不適切でした。+w2 でこれらの警告を生成しないようにすることで、+w2 をより効果的に使用することができます。
+w
このオプションは、コンパイラが警告を出力しない原因となります。ただし、一部の警告、特に旧式の構文に関する重要な警告は抑制できません。
+w
-features=iddollar と同じです。
(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 ソフトウェア機能の定義を参照してください。
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 構造体オブジェクトへのポインタは、その最初のメンバーを示します。そのメンバーがビットフィールドの場合は、そのビットフィールドのあるユニットを示します。
-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; } |
(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 プラットフォームでは、このオプションはありません。
テンプレートを使用する C++ のアーカイブを構築するときには、テンプレートリポジトリ中でインスタンス化されたテンプレート関数をそのアーカイブの中に入れておく必要があります。テンプレートリポジトリは、少なくとも 1 つのオブジェクトファイルを -instances=extern オプションでコンパイルしたときにのみ使用されます。このオプションはそれらのテンプレートを必要に応じてアーカイブに自動的に追加します。
-xar を指定すると、ar -c -r が起動され、アーカイブがゼロから作成されます。
次のコマンド行は、ライブラリファイルとオブジェクトファイルに含まれるテンプレート関数をアーカイブします。
example% CC -xar -o libmain.a a.o b.o c.o |
テンプレートデータベースの .o ファイルをコマンド行に追加しないでください。
アーカイブを構築するときは、ar コマンドを使用しないでください。CC -xar を使用して、テンプレートのインスタンス化情報が自動的にアーカイブに含まれるようにしてください。
ar(1)、表 14–3
対象となる命令セットアーキテクチャー (ISA) を指定します。
このオプションは、コンパイラが生成するコードを、指定した命令セットアーキテクチャーの命令だけに制限します。このオプションは、すべてのターゲットを対象とするような命令としての使用は保証しません。ただし、このオプションを使用するとバイナリプログラムの移植性に影響を与える可能性があります。
意図するメモリーモデルとして LP64 (64 ビット) または ILP32 (32 ビット) を指定するには、それぞれ -m64 または -m32 オプションを使用してください。次に示すように以前のリリースとの互換性を保つ場合を除いて、-xarch オプションでメモリーモデルを指定できなくなりました。
別々の手順でコンパイルしてリンクする場合は、両方の手順に同じ -xarch の値を指定してください。コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧については、「3.3.3 コンパイル時とリンク時のオプション」を参照してください。
次の表に、SPARC プラットフォームでの各 -xarch キーワードの詳細を示します。
表 A–23 SPARC プラットフォームでの -xarch のフラグ
フラグ |
意味 |
---|---|
generic |
ほとんどのプロセッサに共通の命令セットを使用します。これはデフォルト値です。 |
generic64 |
多くのシステムで良好な 64 ビットパフォーマンスを得るためのコンパイルをします(Solaris のみ)。 このオプションは -m64 -xarch=generic に相当し、以前のリリースとの互換性のために用意されています。64 ビットでのコンパイルを指定するには、次のものではなく -m64 を使用してください。 - xarch=generic64 |
native |
このシステムで良好なパフォーマンスを得られるようにコンパイルします。現在コンパイルしているシステムプロセッサにもっとも適した設定を選択します。 |
native64 |
このシステムで良好なパフォーマンスを得られるようにコンパイルします (Solaris のみ)。このオプションは -m64 -xarch=native に相当し、以前のリリースとの互換性のために用意されています。 |
sparc |
SPARC-V9 ISA 用のコンパイルを実行しますが、VIS (Visual Instruction Set) は使用せず、その他の実装に固有の 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 |
sparcima 版の 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 拡張機能からの命令を使用できるようにします。 |
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) 浮動小数点命令は、これらの命令セットアーキテクチャーのいずれにも実装されないため、コンパイラは、そのコンパイラが生成したコードではそれらの命令を使用しません。
次の表に、x86 プラットフォームでの -xarch フラグを示します。
表 A–24 x86 での -xarch のフラグ
フラグ |
意味 |
---|---|
amd64 |
-m64 -xarch=sse2 に相当します (Solaris のみ)。64 ビットメモリーモデルを得るために -xarch=amd64 を使用する古いメイクファイルとスクリプトでは、-m64 だけを使用すれば十分です。 |
amd64a |
-m64 -xarch=sse2a に相当します (Solaris のみ)。 |
generic |
ほとんどのプロセッサに共通の命令セットを使用します。これはデフォルトであり、—m32 でコンパイルする場合の pentium_pro、および —m64 でコンパイルする場合の sse2 に相当します。 |
generic64 |
多くのシステムで良好な 64 ビットパフォーマンスを得るためのコンパイルをします(Solaris のみ)。このオプションは -m64 -xarch=generic に相当し、以前のリリースとの互換性のために用意されています。64 ビットでのコンパイルを指定するには、次のものではなく -m64 を使用してください。 - xarch=generic64 |
native |
このシステムで良好なパフォーマンスを得られるようにコンパイルします。現在コンパイルしているシステムプロセッサにもっとも適した設定を選択します。 |
native64 |
このシステムで良好なパフォーマンスを得られるようにコンパイルします (Solaris のみ)。このオプションは -m64 -xarch=native に相当し、以前のリリースとの互換性のために用意されています。 |
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 命令セットに追加します。 |
ssse3 |
SSSE3 命令セットで、pentium_pro、SSE、SSE2、および SSE3 の各命令セットを補足します。 |
sse4_1 |
SSSE4.1 命令セットで、pentium_pro、SSE、SSE2、SSE3、および SSSE3 の各命令セットを補足します。 |
sse4_2 |
SSSE4.2 命令セットで、pentium_pro、SSE、SSE2、SSE3、SSSE3、および SSSE4.1 の各命令セットを補足します。 |
amdsse4a |
AMD SSE4a 命令セットを使用します。 |
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)) が同じではないため、演算結果が異なることがあります。
Solaris Studio 11 と Solaris 10 OS から、これらの特殊化された -xarch ハードウェアフラグを使用してコンパイルし、構築されたプログラムバイナリは、適切なプラットフォームで実行されることが確認されます。
Solaris 10 以前のシステムでは妥当性検査が行われないため、これらのフラグを使用して構築したオブジェクトが適切なハードウェアに配備されることをユーザが確認する必要があります。
これらの -xarch オプションでコンパイルしたプログラムを、適切な機能または命令セット拡張に対応していないプラットフォームで実行すると、セグメント例外や明示的な警告メッセージなしの不正な結果が発生することがあります。
このことは、.il インラインアセンブリ言語関数を使用しているプログラムや、SSE、SSE2、SSE2a、および SSE3 の命令と拡張機能を利用している __asm() アセンブラコードにも当てはまります。
このオプションは単体でも使用できますが、-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] の使用はサポートされていません。
このオプションを最適化と併せて使用する場合、適切なアーキテクチャーを選択すると、そのアーキテクチャー上での実行パフォーマンスを向上させることができます。ただし、適切な選択をしなかった場合、パフォーマンスが著しく低下するか、あるいは、作成されたバイナリプログラムが目的のターゲットプラットフォーム上で実行できない可能性があります。
別々の手順でコンパイルしてリンクする場合は、両方の手順に同じ -xarch の値を指定してください。
このオプションは OpenMP の並列化命令を受け付けません。Sun 固有の MP プラグマは推奨されず、サポートされません。標準命令への移植情報については、『Solaris Studio OpenMP API ユーザーズガイド』を参照してください。
(SPARC) 複数プロセッサの自動並列化を有効にします。依存性の解析 (ループの繰り返し内部でのデータ依存性の解析) およびループ再構成を実行します。最適化が -xO3 以上でない場合、最適化は -xO3 に引き上げられ、警告が出されます。
独自のスレッド管理を行なっている場合には、-xautopar を使用しないでください。
実行速度を上げるには、マルチプロセッサシステムが必要です。シングルプロセッサシステムでは、通常、生成されたバイナリの実行速度は低下します。
並列化されたプログラムをマルチスレッド環境で実行するには、実行前に OMP_NUM_THREADS 環境変数を設定しておく必要があります。詳細は、『Solaris Studio OpenMP API ユーザーズガイド』を参照してください。
-xautopar を使用してコンパイルとリンクを 1 度に実行する場合、リンクには自動的にマイクロタスキング・ライブラリおよびスレッドに対して安全な C 実行時ライブラリが含まれます。-xautopar を使用して別々にコンパイルし、リンクする場合、-xautopar でリンクする必要があります。
(SPARC) あとでコンパイラ最適化、変換、分析を行うために、バイナリを準備するようコンパイラに命令します。binopt(1) を参照してください。このオプションは、実行可能ファイルまたは共有オブジェクトの構築に使用できます。コンパイルとリンクを別々に行う場合は、両方の手順に -xbinopt を指定する必要があります。
example% cc -c -xO1 -xbinopt=prepare a.c b.c example% cc -o myprog -xbinopt=prepare a.o |
一部のソースコードがコンパイルに使用できない場合も、このオプションを使用してそのほかのコードがコンパイルされます。このとき、最終的なバイナリを作成するリンク手順で、このオプションを使用する必要があります。この場合、このオプションでコンパイルされたコードだけが最適化、変換、分析できます。
デフォルトは -xbinopt=off です。
このオプションを有効にするには、最適化レベル -xO1 以上で使用する必要があります。このオプションを使用すると、構築したバイナリのサイズが少し増えます。
-xbinopt=prepare と -g を指定してコンパイルすると、デバッグ情報が取り込まれるので、実行可能ファイルのサイズが増えます。
デフォルトでは、標準ライブラリヘッダで宣言された関数は、コンパイラによって通常の関数として処理されます。ただし、これらの関数の一部は、「組み込み」として認識されます。組み込み関数として処理されるときは、コンパイラでより効果的なコードを生成できます。たとえば、一部の関数は副作用がないことをコンパイラで認識でき、同じ入力が与えられると常に同じ出力が戻されます。一部の関数はコンパイラによって直接インラインで生成できます。オブジェクトファイル内のコンパイラのコメントからコンパイラが実際に置換を行う関数を特定する方法については、er_src(1) のマニュアルページを参照してください。
-xbuiltin=%all オプションは、コンパイラにできるだけ多数の組み込み標準関数を認識するように指示します。認識される関数の正確なリストは、コンパイラコードジェネレータのバージョンによって異なります。
-xbuiltin=%none オプションはデフォルトのコンパイラの動作に影響を与え、コンパイラは組み込み関数に対して特別な最適化は行いません。
-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 |
オプティマイザ用のキャッシュ特性を定義します。この定義によって、特定のキャッシュが使用されるわけではありません。
このオプションは単独で指定できますが、-xtarget オプションの拡張機能の一部です。-xtarget オプションによって供給された値をオーバーライドするために使用されます。
このリリースで、キャッシュを共有できるスレッド数を指定するオプションの特性 [/ti] が導入されました。
c には次の値のいずれかを指定します。
表 A–25 -xcache の値
値 |
意味 |
---|---|
generic |
これはデフォルトです。ほとんどの SPARC プロセッサに良好なパフォーマンスを提供し、どの x86、SPARC の各プロセッサでも著しいパフォーマンス低下が生じないようなキャッシュ特性を使用するように、コンパイラに指示します。 これらの最高のタイミング特性は、新しいリリースごとに、必要に応じて調整されます。 |
native |
ホスト環境に対して最適化されたパラメータを設定します。 |
s1/l1/a 1[/t1] |
レベル 1 のキャッシュ属性を定義します。 |
s1/l1/a 1[/t1]:s2/l 2/a2[ /t2] |
レベル 1 とレベル 2 のキャッシュ属性を定義します。 |
s1/l1/a 1[/t1]:s2/l 2/a2[ /t2]:s3/l 3/a3[ /t3] |
レベル 1、レベル 2、レベル 3 のキャッシュ属性を定義します。 |
キャッシュ属性 si/li/ai/ti の定義は、次のとおりです。
属性 |
定義 |
---|---|
si |
レベル i のデータキャッシュのサイズ (K バイト単位) |
li |
レベル i のデータキャッシュのラインサイズ (バイト単位) |
ai |
レベル i のデータキャッシュの結合規則 |
たとえば、i=1 は、レベル 1 のキャッシュ属性の s1/l1/a1 を意味します。
-xcache が指定されない場合、デフォルト -xcache=generic が想定されます。この値を指定すると、ほとんどの SPARC プロセッサで良好なパフォーマンスが得られ、どのプロセッサでも顕著なパフォーマンスの低下がないキャッシュ属性がコンパイラで使用されます。
t の値を指定しない場合のデフォルトは 1 です。
-xcache=16/32/4:1024/32/1 の設定内容は、次のとおりです。
レベル 1 のキャッシュ |
レベル 2 のキャッシュ |
---|---|
16K バイト |
1024K バイト |
ラインサイズ 32 バイト |
ラインサイズ 32 バイト |
4 ウェイアソシアティブ |
直接マップ結合 |
-xtarget=t
(SPARC) 非推奨、使用しないでください。現在の Solaris オペレーティングシステムのソフトウェアは、SPARC V7 アーキテクチャーをサポートしません。このオプションでコンパイルすると、現在の SPARC プラットフォームでの実行速度が遅いコードが生成されます。-xO を使用して、-xarch、-xchip、および -xcache のコンパイラのデフォルトを利用します。
この オプションは、 char 型が符号なしで定義されているシステムからのコード移植を簡単にするためのものです。そのようなシステムからの移植以外では、このオプションは使用しないでください。符号付きまたは符号なしであると明示的に示すように書き直す必要があるのは、符号に依存するコードだけです。
o には、次のいずれかを指定します。
表 A–26 -xchar の値
値 |
意味 |
---|---|
signed |
char 型で定義された文字定数および変数を符号付きとして処理します。コンパイル済みコードの動作に影響しますが、ライブラリルーチンの動作には影響しません。 |
s |
signed と同義です。 |
unsigned |
char 型で定義された文字定数および変数を符号なしとして処理します。コンパイル済みコードの動作に影響しますが、ライブラリルーチンの動作には影響しません。 |
u |
unsigned と同義です。 |
-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 型の符号は、コンパイラやオペレーティングシステムによって異なります。
SPARC: -xcheck=stkovfを指定してコンパイルすると、シングルスレッドのプログラム内のメインスレッドのスタックオーバーフローおよびマルチスレッドプログラム内のスレーブスレッドのスタックが実行時にチェックされます。スタックオーバーフローが検出された場合は、SIGSEGV が生成されます。アプリケーションで、スタックオーバーフローで生成される SIGSEGV をほかのアドレス空間違反と異なる方法で処理する必要がある場合は、sigaltstack(2) を参照してください。
i には、次のいずれかを指定します。
表 A–27 -xcheck の値
値 |
意味 |
---|---|
%all |
チェックをすべて実行します。 |
%none |
チェックを実行しません。 |
stkovf |
スタックオーバーフローのチェックをオンにします。 |
no%stkovf |
スタックオーバーフローのチェックをオフにします。 |
init_local |
ローカル変数を初期化します。詳細は、『C ユーザーズガイド』を参照してください。 |
no%init_local |
ローカル変数を初期化しません。(デフォルト) |
-xcheck を指定しない場合は、コンパイラではデフォルトで -xcheck=%none が指定されます。
引数を指定せずに -xcheck を使用した場合は、コンパイラではデフォルトで -xcheck=%none が指定されます。
-xcheck オプションは、コマンド行で累積されません。コンパイラは、コマンドで最後に指定したものに従ってフラグを設定します。
オプティマイザが使用するターゲットとなるプロセッサを指定します。
–xchip オプションは、ターゲットとなるプロセッサを指定してタイミング属性を指定します。このオプションは次のものに影響を与えます。
命令の順序 (スケジューリング)
コンパイラが分岐を使用する方法
意味が同じもので代用できる場合に使用する命令
このオプションは単独で指定できますが、-xtarget オプションの拡張機能の一部です。-xtarget オプションによって供給された値をオーバーライドするために使用されます。
c には次の値のいずれかを指定します。
表 A–28 -xchip の値
プラットフォーム |
値 |
次の目的のタイミング属性を使用して最適化 |
---|---|---|
SPARC |
generic |
SPARC プロセッサ上で良好なパフォーマンスを得るため |
native |
コンパイルを実行しているシステム上で良好なパフォーマンスを得るため |
|
old |
SuperSPARC プロセッサ より古いプロセッサ |
|
sparc64vi |
SPARC64 VI プロセッサ |
|
sparc64vii |
SPARC64 VII プロセッサ |
|
super |
より古いプロセッサ |
|
super2 |
SuperSPARC II プロセッサ |
|
micro |
microSPARC プロセッサ |
|
micro2 |
microSPARC II プロセッサ |
|
hyper |
hyperSPARC プロセッサ |
|
hyper2 |
hyperSPARC II プロセッサ |
|
powerup |
Weitek PowerUp プロセッサ |
|
ultra |
UltraSPARC プロセッサ |
|
ultra2 |
UltraSPARC II プロセッサ |
|
ultra2e |
UltraSPARC IIe プロセッサ |
|
ultra2i |
UltraSPARC IIi プロセッサ |
|
ultra3 |
UltraSPARC III プロセッサ |
|
ultra3cu |
UltraSPARC III Cu プロセッサ |
|
ultra3i |
UltraSparc IIIi プロセッサ |
|
ultra4 |
UltraSPARC IV プロセッサ |
|
ultra4plus |
UltraSPARC IVplus プロセッサ |
|
ultraT1 |
UltraSPARC T1 プロセッサ. |
|
ultraT2 |
UltraSPARC T2 プロセッサ. |
|
ultraT2plus |
UltraSPARC T2+ プロセッサ |
|
ultraT3 |
UltraSPARC T3 プロセッサ |
|
x86 |
generic |
大部分の 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 プロセッサ |
ほとんどのプロセッサ上で、generic は、どのプロセッサでもパフォーマンスの著しい低下がなく、良好なパフォーマンスが得られる最良のタイミング属性を使用するようコンパイラに命令するデフォルト値です。
SPARC: コードのアドレス空間を指定します。
共有オブジェクトの構築では、-xcode=pic13 または -xcode=pic32 を指定することをお勧めします。pic13 または pic32 なしに構築された共有オブジェクトは、正しく機能せず、構築できない可能性があります。
a には次のいずれかを指定します。
表 A–29 -xcode の値
値 |
意味 |
---|---|
abs32 |
32 ビット絶対アドレスを生成します。高速ですが範囲が限定されます。コード、データ、および bss を合計したサイズは 2**32 バイトに制限されます。 |
abs44 |
SPARC: 44 ビット絶対アドレスを生成します。中程度の速さで中程度の範囲を使用できます。コード、データ、および bss を合計したサイズは 2**44 バイトに制限されます。64 ビットのアーキテクチャーでのみ利用できます。動的 (共有) ライブラリで使用しないでください。 |
abs64 |
SPARC: 64 ビット絶対アドレスを生成します。低速ですが範囲は制限されません。64 ビットのアーキテクチャーでのみ利用できます。 |
pic13 |
位置に依存しないコード (小規模モデル) を生成します。高速ですが範囲が限定されます。-Kpic と同義です。32 ビットアーキテクチャーでは最大 2**11 個の固有の外部シンボルを、64 ビットでは 2**10 個の固有の外部シンボルをそれぞれ参照できます。 |
pic32 |
位置独立コード (ラージモデル) を生成します。pic13 ほど高速でない可能性がありますが、フルレンジ対応です。-KPIC と同義です。32 ビットアーキテクチャーでは最大 2**30 個の固有の外部シンボルを、64 ビットでは 2**29 個の固有の外部シンボルをそれぞれ参照できます。 |
-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 を使用する必要があります。
廃止。使用しないでください。代わりに -xipo を使用してください。
コンパイラは、 デバッグ情報の形式をスタブ形式から「DWARF Debugging Information Format」で規定されている dwarf 形式に変換します。デフォルト設定は -xdebugformat=dwarf です。
デバッグ情報を読み取るソフトウェアを保守している場合は、今回からそのようなツールを stab 形式から dwarf 形式へ移行するためのオプションが加わりました。
このオプションは、ツールを移植する場合に新しい形式を使用する方法として使用してください。デバッガ情報を読み取るソフトウェアを保守していないか、ツールでこれらの内のいずれかの形式のデバッガ情報が必要でなければ、このオプションを使用する必要はありません。
表 A–30 -xdebugformat のフラグ
値 |
意味 |
---|---|
stabs |
-xdebugformat=stabs は、stab 標準形式を使用してデバッグ情報を生成します。 |
dwarf |
-xdebugformat=dwarf は、dwarf 標準形式を使用してデバッグ情報を生成します。 |
-xdebugformat を指定しない場合は、コンパイラでは -xdebugformat=stabs が指定されます。このオプションには引数が必要です。
このオプションは、-g オプションによって記録されるデータの形式に影響します。-g を指定しなくても、一部のデバッグ情報が記録されますが、その情報の形式もこのオプションによって制御されます。したがって、-g を使用しなくても、-xdebugformat は有効です。
dbx とパフォーマンスアナライザソフトウェアは、stab 形式と dwarf 形式を両方とも認識するので、このオプションを使用しても、ツールの機能にはまったく影響を与えません。
これは過渡的なインタフェースなので、今後のリリースでは、マイナーリリースであっても互換性なく変更されることがあります。stab と dwarf のどちらであっても、特定のフィールドまたは値の詳細は、今後とも変更される可能性があります。
詳細は、dumpstabs(1) および dwarfdump(1) のマニュアルページも参照してください。
(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
マクロがプログラム内でどのように動作しているかを調べたいときに、このオプションを使用します。このオプションは、定義済みマクロ、解除済みマクロ、実際の使用状況といった情報を提供します。マクロの処理順序に従って、標準エラー (stderr) に出力されます。-xdumpmacros オプションは、ファイルの終わりまで、または dumpmacros プラグマまたは end_dumpmacros プラグマによって上書きされるまで有効です。「B.2.5 #pragma dumpmacro s」を参照してください。
value の代わりに次の引数を使用できます。
表 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 |
dumpmacros プラグマと end_dumpmacros プラグマを使用すれば、-xdumpmacros のスコープを変更できます。
構文エラーと意味エラーの有無チェックのみ行います。-xe を指定すると、オブジェクトコードは出力されません。-xe の出力は、stderr に送られます。
コンパイルによってオブジェクトファイルを生成する必要がない場合には、-xe オプションを使用してください。たとえば、コードの一部を削除することによってエラーメッセージの原因を切り分ける場合には、-xe を使用することによって編集とコンパイルを高速化できます。
-c
リンカーによる関数と変数の最適な順序の並べ替えを有効にします。
このオプションは、関数とデータ変数を細分化された別々のセクションに配置するようコンパイラに指示します。それによってリンカーは、リンカーの -M オプションで指定されたマップファイル内の指示に従ってこれらのセクションの順序を並べ替えて、プログラムのパフォーマンスを最適化することができます。通常は、この最適化によって効果が上がるのは、プログラムの実行時間の多くがページフォルト時間に費やされている場合だけです。
変数を並べ替えることによって、実行時間のパフォーマンスにマイナスの影響を与える次のような問題を解決できます。
メモリー内で関係ない変数どうしが近接しているために生じる、キャッシュやページの競合
関係のある変数がメモリー内で離れた位置にあるために生じる、不必要に大きな作業セットサイズ
使用していない weak 変数のコピーが有効なデータ密度を低下させた結果生じる、不必要に大きな作業セットサイズ
最適なパフォーマンスを得るために変数と関数の順序を並べ替えるには、次の処理が必要です。
-xF によるコンパイルとリンク
『プログラムのパフォーマンス解析』マニュアル内の、関数のマップファイルを生成する方法に関する指示に従うか、または、『リンカーとライブラリ』内の、データのマップファイルを生成する方法に関する指示に従います。
リンカーの -M オプションを使用して新しいマップファイルを再リンクします。
アナライザで再実行して、パフォーマンスが向上したかどうかを検証します。
v には、次のいずれかを指定します。
表 A–32 -xF の値
値 |
意味 |
---|---|
[no%]func |
関数を個々のセクションに細分化します [しません]。 |
[no%]gbldata |
大域データ (外部リンケージのある変数) を個々のセクションに細分化します [しません]。 |
[no%]lcldata |
大域データ (外部リンケージのある変数) を個々のセクションに細分化します [しません]。 |
%all |
関数、大域データ、局所データを細分化します。 |
%none |
何も細分化しません。 |
-xF を指定しない場合のデフォルトは、-xF=%none です。引数を指定しないで -xF を指定した場合のデフォルトは、-xF=%none,func です。
-xF=lcldata を指定するとアドレス計算最適化が一部禁止されるので、このフラグは実験として意味があるときにだけ使用するとよいでしょう。
analyzer(1)、ld(1) のマニュアルページも参照してください。
各コンパイラオプションの簡単な説明を表示します。
README (最新情報) ファイルの内容を表示します。
README ファイルのページングには、環境変数 PAGER で指定されているコマンドが使用されます。PAGER が設定されていない場合、デフォルトのページングコマンド more が使用されます。
(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 |
ハードウェアカウンタによるプロファイリングの詳細については、『プログラムのパフォーマンス解析』を参照してください。
区間演算ライブラリをリンクし、適切な浮動小数点環境を設定します。
C++ 区間演算ライブラリは、Fortran コンパイラで実装されているとおり、区間演算と互換性があります。
x86 プラットフォームでは、SSE2 命令セットのサポートが必要です。
-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
どのユーザー作成ルーチンをオプティマイザによって -xO3 レベル以上でインライン化するかを指定します。
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] を使用しないかぎり、コンパイルされているファイルのルーチンだけがインライン化の対象とみなされます。オプティマイザでは、どのルーチンがインライン化に適しているかを判断します。
-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 を指定して関数のインライン化を強制すると、実際にパフォーマンスを低下させる可能性があります。
スレッドアナライザで分析するためにプログラムをコンパイルして計測するには、このオプションを指定します。スレッドアナライザの詳細については、tha(1) を参照してください。
そうすることで、パフォーマンスアナライザを使用して計測されたプログラムを collect -r races で実行し、データ競合の検出実験を行うことができます。計測されたコードをスタンドアロンで実行できますが、低速で実行されます。
-xinstrument=no%datarace を指定して、スレッドアナライザ用のソースコードの準備をオフにすることができます。これはデフォルト値です。
-xinstrument を引数なしで指定することはできません。
コンパイルとリンクを別々に行う場合は、コンパイル時とリンク時の両方で -xinstrument=datarace を指定する必要があります。
このオプションは、プリプロセッサトークン __THA_NOTIFY を定義します。#ifdef __THA_NOTIFY を指定して、libtha(3) ルーチンへの呼び出しを保護できます。
このオプションにも、-g を設定します。
-xipo オプションが内部手続き解析パスを呼び出すことでプログラムの一部の最適化を実行します。このオプションを指定すると、リンク手順でのすべてのオブジェクトファイル間の最適化を行い、しかもこれらの最適化は単にコンパイルコマンドのソースファイルにとどまりません。ただし、-xipo によるプログラム全体の最適化には、アセンブリ (.s) ソースファイルは含まれません。
-xipo オプションは、大量のファイルを使用してアプリケーションをコンパイルしてリンクするときに特に便利です。このフラグを指定してコンパイルされたオブジェクトファイルには、ソースプログラムファイルとコンパイル済みプログラムファイル間で内部手続き解析を有効にする解析情報が含まれています。ただし、解析と最適化は、-xipo を指定してコンパイルされたオブジェクトファイルに限定され、オブジェクトファイルまたはライブラリは対象外です。
-xipo オプションには次の値があります。
表 A–34 -xipo の値
値 |
意味 |
---|---|
0 |
内部手続きの最適化を実行しません |
1 |
内部手続きの最適化を実行します |
2 |
内部手続きの別名解析と、メモリーの割り当ておよび配置の最適化を実行し、キャッシュ性能を向上します |
-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 オプションは、ファイルを介して最適化を実行する際に必要な情報を追加するため、非常に大きなオブジェクトファイルを生成します。ただし、この補足情報は最終的な実行可能バイナリファイルの一部にはなりません。実行可能プログラムのサイズの増加は、そのほかに最適化を実行したことに起因します。
内部手続き解析では、コンパイラは、リンクステップでオブジェクトファイル群を操作しながら、プログラム全体の解析と最適化を試みます。このとき、コンパイラは、このオブジェクトファイル群に定義されているすべての 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
新しい -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 をフラグなしで指定することはできません。
コンパイラが処理を行うために生成するプロセスの数を設定するには、-xjobs オプションを指定します。このオプションを使用すると、マルチ CPU マシン上での構築時間を短縮できます。現時点では、-xjobs とともに使用できるのは -xipo オプションだけです。-xjobs=n を指定すると、内部手続きオプティマイザは、さまざまなファイルをコンパイルするために呼び出すことができるコードジェネレータインスタンスの最大数として、n を使用します。
-xjobs には必ず値を指定する必要があります。値を指定しないと、エラー診断が表示され、コンパイルは中止します。
一般に、n に指定する確実な値は、使用できるプロセッサ数に 1.5 を掛けた数です。生成されたジョブ間のコンテキスト切り替えにより生じるオーバーヘッドのため、使用できるプロセッサ数の何倍もの値を指定すると、パフォーマンスが低下することがあります。また、あまり大きな数を使用すると、スワップ領域などシステムリソースの限界を超える場合があります。
コマンド行に複数の -xjobs のインスタンスがある場合、一番右にあるインスタンスが実行されるまで相互に上書きします。
次の例に示すコマンドは 2 つのプロセッサを持つシステム上で、-xjobs オプションを指定しないで実行された同じコマンドよりも高速にコンパイルを実行します。
example% CC -xipo -xO4 -xjobs=3 t1.cc t2.cc t3.cc |
指定した機能 (name) のスタック関連の最適化を禁止します。
%all - すべてのコードのスタック関連の最適化を禁止します。
%none - すべてのコードのスタック関連の最適化を許可します。
このオプションがコマンド行で指定されていないと、コンパイラはデフォルトの -xkeepframe=%none を使用します。このオプションが値なしで指定されると、コンパイラは -xkeepframe=%all を使用します。
該当する実行時ライブラリをインクルードし、指定された言語に適切な実行時環境を用意します。
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 オプションしか正しい実行時環境を保証しないので、言語が混合したリンクには不十分です。
言語が混合したリンクの場合、ドライバは次の順序で言語階層を使用してください。
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 を使用してください。
-xlang と一緒に -xnolib を使用しないでください。
Fortran 並列オブジェクトを C++ オブジェクトと混合している場合は、リンク行に -mt フラグを指定する必要があります。
-library、-staticlib
extern シンボルの定義に対するデフォルトのリンカースコープを変更するには、-xldscope オプションを指定します。デフォルトを変更すると、実装がよりうまく隠蔽されるため、共有ライブラリと実行可能ファイルをより高速かつ安全に使用できるようになります。
v には、次のいずれかを指定します。
表 A–36 -xldscope の値
値 |
意味 |
---|---|
global |
大域リンカースコープは、もっとも制限の少ないリンカースコープです。シンボル参照はすべて、そのシンボルが定義されている最初の動的ロードモジュール内の定義と結合します。このリンカースコープは、extern シンボルの現在のリンカースコープです。 |
symbolic |
シンボリックリンカースコープは、大域リンカースコープよりも制限されたスコープです。リンク対象の動的ロードモジュール内からのシンボルへの参照はすべて、そのモジュール内に定義されているシンボルと結合します。モジュール外については、シンボルは大域なものとなります。このリンカースコープはリンカーオプション -Bsymbolic に対応します。C++ ライブラリでは -Bsymbolic を使用できませんが、-xldscope=symbolic 指定子は問題なく使用できます。リンカーの詳細については、ld(1) を参照してください。 |
hidden |
隠蔽リンカースコープは、シンボリックリンカースコープや大域リンカースコープよりも制限されたリンカースコープです。動的ロードモジュール内の参照はすべて、そのモジュール内の定義に結合します。シンボルはモジュールの外側では認識されません。 |
-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
例外時に libm が数学ルーチンに対し IEEE 754 値を返します。
libm のデフォルト動作は XPG に準拠します。
数値計算ガイド
選択された libm ライブラリルーチンを最適化のためにインライン展開します。
このオプションは C++ インライン関数には影響しません。
一部の libm ライブラリルーチンにはインラインテンプレートがあります。このオプションを指定すると、これらのテンプレートが選択され、現在選択されている浮動小数点オプションとプラットフォームに対してもっとも高速な実行可能コードが生成されます。
このオプションの機能は、-fast オプションを指定した場合にも含まれます。
-fast、『数値計算ガイド』
最適化された数学ルーチンのライブラリを使用します 。このオプションを使用するときは -fround=nearest を指定することによって、デフォルトの丸めモードを使用する必要があります。
パフォーマンスが最適化された数学ルーチンのライブラリを使用し、より高速で実行できるコードを生成します。通常の数学ライブラリを使用した場合とは、結果が少し異なることがあります。このような場合、異なる部分は通常は最後のビットです。
このライブラリオプションをコマンド行に指定する順序は重要ではありません。
このオプションの機能は、-fast オプションを指定した場合にも含まれます。
-fast、-xnolibmopt、-fround
非推奨。使用しないでください。代わりに、-library=sunperf を指定します。詳細は、「A.2.49 -library=l[ ,l...]」を参照してください。
このオプションは、コンパイル時には暗黙的に無視されます。
オブジェクトファイル内のあらゆる最適化のほかに、 結果として出力される実行可能ファイルや動的ライブラリに対してリンク時の最適化も行うようコンパイラに指示します。このような最適化は、リンク時にオブジェクトのバイナリコードを解析することによって実行されます。オブジェクトファイルは書き換えられませんが、最適化された実行可能コードは元のオブジェクトコードとは異なる場合があります。
-xlinkopt をリンク時に有効にするには、少なくともコンパイルコマンドで -xlinkopt を使用する必要があります。-xlinkopt を指定しないでコンパイルされたオブジェクトバイナリについても、オプティマイザは限定的な最適化を実行できます。
-xlinkopt は、コンパイラのコマンド行にある静的ライブラリのコードは最適化しますが、コマンド行にある共有 (動的) ライブラリのコードは最適化しません。共有ラ イブラリを構築する場合 (-G でコンパイルする場合) にも、-xlinkopt を使用できます。
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 です。
レベルパラメータなしで -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 を指定してコンパイルすると、デバッグ情報が取り込まれるので、実行可能ファイルのサイズが増えます。
このオプションは、並列化されているループとされていないループを示します。通常は、-xautopar オプションとともに使用します。
指定した C++ プログラムに対してプリプロセッサだけを実行します。その際、メイクファイル用の依存関係を生成してその結果を標準出力に出力します (make ファイルと依存関係についての詳細は make(1) のマニュアルページを参照してください)。
ただし、-xM を指定すると、インクルードされているヘッダーの依存関係のみを報告し、関連付けられているテンプレート定義ファイルの依存関係を報告しません。メイクファイルの中で .KEEP_STATE 機能を使用して、make ユーティリティが使用する .make.state ファイルの中にあるすべての依存関係を使用することもできます。
次に例を示します。
#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) のマニュアルページを参照してください。
/usr/include ヘッダーファイルの依存関係とコンパイラで提供されるヘッダーファイルの依存関係を報告しないという点を除くと、-xM と同様にメイクファイルの依存関係を生成します。
-xM1 と -xMF を指定する場合、-xMF で指定したファイルに、コンパイラはすべてのメイクファイルの依存関係情報を書き込みます。プリプロセッサがこのファイルへの書き込みを行うたびに、このファイルは上書きされます。
-xM と同様にメイクファイルの依存関係を生成しますが、コンパイルを続行します。-xMD は、指定されている場合は -o 出力ファイル名から派生したメイクファイルの依存関係情報の出力ファイルを生成します。または、ファイル名接尾辞を .d に置換 (または追加) して、入力元ファイル名を生成します。-xMD と -xMF を指定する場合、-xMF で指定したファイルに、プリプロセッサはすべてのメイクファイルの依存関係情報を書き込みます。複数のソースファイルで -xMD -xMF または -xMD -o filename を使用してコンパイルすることはできず、エラーが生成されます。依存関係ファイルがすでに存在する場合は上書きされます。
メイクファイルの依存関係の出力先ファイルを指定するには、このオプションを使用します。コマンド行で -xMF を使用して、複数の入力ファイルのファイル名を個別に指定することはできません。複数のソースファイルで -xMD -xMF または -xMMD -xMF を使用してコンパイルすることはできず、エラーが生成されます。依存関係ファイルがすでに存在する場合は上書きされます。
システムヘッダーファイルを除き、メイクファイルの依存関係を生成するには、このオプションを使用します。これは、-xM1 と同様の機能ですが、コンパイルが続行されます。-xMMD は、指定されている場合は -o 出力ファイル名から派生したメイクファイルの依存関係情報の出力ファイルを生成します。または、ファイル名接尾辞を .d に置換 (または追加) して、入力元ファイル名を生成します。-xMF を指定する場合、コンパイラは代わりに、ユーザーが指定したファイル名を使用します。複数のソースファイルで -xMMD -xMF または -xMMD -o filename を使用してコンパイルすることはできず、エラーが生成されます。依存関係ファイルがすでに存在する場合は上書きされます。
SPARC: データセグメントとテキストセグメントをマージします。
オブジェクトファイルのデータは読み取り専用です。また、このデータは ld -N を指定してリンクしないかぎりプロセス間で共有されます。
3 つのオプション -xMerge -ztext -xprofile=collect を一緒に使用するべきではありません。-xMerge を指定すると、静的に初期化されたデータを読み取り専用記憶領域に強制的に配置します。 -ztext を指定すると、位置に依存するシンボルを読み取り専用記憶領域内で再配置することを禁止します。-xprofile=collect を指定すると、書き込み可能記憶領域内で、静的に初期化された、位置に依存するシンボルの再配置を生成します。
ld(1) のマニュアルページ
このコマンドは、コマンド pragma opt のレベルを指定されたレベルに制限します。v は、off、1、2、3、4、5 のいずれかです。デフォルト値は -xmaxopt=off であり、pragma opt は無視されます。引数を指定せずに -xmaxopt を指定すると、-xmaxopt=5 を指定したことになります。
-xO と -xmaxopt の両方を指定する場合、-xO で設定する最適化レベルが -xmaxopt 値を超えてはいけません。
(SPARC) データの境界整列についてコンパイラが使用する想定を制御するには、-xmemalign オプションを使用します。境界整列が潜在的に正しくないメモリーアクセスにつながる生成コードを制御し、境界整列が正しくないアクセスが発生したときのプログラム動作を制御すれば、より簡単に SPARC にコードを移植できます。
想定するメモリー境界整列の最大値と、境界整列に失敗したデータがアクセスされた際の動作を指定します。a (境界整列) と b (動作) の両方の値が必要です。a は、想定する最大メモリー境界整列です。b は、境界整列に失敗したメモリーへのアクセスに対する動作です。
コンパイル時に境界整列が判別できるメモリーへのアクセスの場合、コンパイラはそのデータの境界整列に適したロードおよびストア命令を生成します。
境界整列がコンパイル時に決定できないメモリーアクセスの場合、コンパイラは、境界整列を想定して、必要なロード/ストア命令のシーケンスを生成します。
実行時の実際のデータ境界整列が指定された整列に達しない場合、境界整列に失敗したアクセス (メモリー読み取りまたは書き込み) が行われると、トラップが発生します。このトラップに対して可能な応答は 2 つあります。
OS がトラップを SIGBUS シグナルに変換します。プログラムがこのシグナルを捕捉しなかった場合、プログラムは異常終了します。プログラムがシグナルを捕捉しても、境界整列に失敗したアクセスが成功するわけではありません。
境界整列に失敗したアクセスが正常に成功したかのように OS がアクセスを解釈し、プログラムに制御を戻すことによってトラップを処理します。
次に、-memalign の境界整列と動作の値を示します。
表 A–38 -xmemalign の境界整列と動作の値
a |
b | ||
---|---|---|---|
1 |
最大 1 バイトの境界整列 |
i |
アクセスを解釈し、実行を継続する |
2 |
最大 2 バイトの境界整列 |
-s |
シグナル SIGBUS を発生させる |
4 |
最大 4 バイトの境界整列 |
f |
-xarch=v9 の不変式の場合にのみ、 4 バイト以下の境界整列に対してシグナル SIGBUS を発生させ、それ以外ではアクセスを解釈して実行を継続する。そのほかすべての -xarch 値では、f フラグは i と同じです。 |
8 |
最大 8 バイトの境界整列 | ||
16 |
最大 16 バイトの境界整列 |
b を i か f のいずれかに設定してコンパイルしたオブジェクトファイルにリンクする場合は、必ず、-xmemalign を指定する必要があります。「3.3.3 コンパイル時とリンク時のオプション」に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。
次のデフォルトの値は、-xmemalign オプションがまったく指定されていない場合にのみ適用されます。
-xmemalign=8i すべての v8 アーキテクチャーに適用される。
-xmemalign=8s すべての v9 アーキテクチャーに適用される。
次に、-xmemalign オプションが指定されているが値を持たない場合のデフォルト値を示します。
-xmemalign=1i すべての -xarch 値に適用される。
次の表は、-xmemalign で処理できるさまざまな境界整列の状況とそれに適した -xmemalign 指定を示しています。
表 A–39 -xmemalign の例
コマンド |
状況 |
---|---|
-xmemalign=1s |
すべてのメモリーアクセスの整列が正しくないため、トラップ処理が遅すぎる。 |
-xmemalign=8i |
コード内に境界整列されていないデータへのアクセスが意図的にいくつか含まれているが、それ以外は正しい |
-xmemalign=8s |
プログラム内に境界整列されていないデータへのアクセスは存在しないと思われる |
-xmemalign=2s |
奇数バイトへのアクセスが存在しないか検査したい |
-xmemalign=2i |
奇数バイトへのアクセスが存在しないか検査し、プログラムを実行したい |
(x86) -xmodel オプションを使用すると、コンパイラで 64 ビットオブジェクトの形式を Solaris x86 プラットフォーム用に変更できます。このオプションは、そのようなオブジェクトのコンパイル時にのみ指定してください。
このオプションは、64 ビット対応の x64 プロセッサで -m64 も指定した場合にのみ有効です。
a には次のいずれかを指定します。
表 A–40 -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 システムが、ミディアムモデルをサポートしているわけではありません。
通常 (このオプションを指定しない場合)、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 |
C アプリケーションのバイナリインタフェースを満たす最小限のコンパイルを行う場合、つまり、C サポートだけが必要な C++ プログラムの場合は、次のように指定します。
example% CC– xnolib test.cc –lc |
一般的なアーキテクチャー命令を持つシングルスレッドアプリケーションに libm を静的にリンクするには、次のように指定します。
-xnolib を指定する場合は、必要なすべてのシステムサポートライブラリを手動で一定の順序にリンクする必要があります。システムサポートライブラリは最後にリンクしなければいけません。
-xnolib を指定すると、-library は無視されます。
C++ 言語の多くの機能では、libC (互換モード) または libCrun (標準モード) を使用する必要があります。
このリリースのシステムサポートライブラリは安定していないため、リリースごとに変更される可能性があります。
-library、-staticlib、-l
コマンド行の -xlibmil を取り消します。
最適化された数学ライブラリとのリンクを変更するには、このオプションを -fast と一緒に使用してください。
数学ルーチンのライブラリを使用しません。
次の例のように、このオプションはコマンド行で -fast オプションを指定した場合は、そのあとに使用してください。
example% CC –fast –xnolibmopt |
最適化レベルを指定します。大文字 O のあとに数字の 1、2、3、4、5 のいずれかが続きます。一般的に、プログラムの実行速度は最適化のレベルに依存します。最適化レベルが高いほど、実行時のパフォーマンスは向上します。しかし、最適化レベルが高ければ、それだけコンパイル時間が増え、実行可能ファイルが大きくなる可能性があります。
ごくまれに、-xO2 の方がほかの値より実行速度が速くなることがあり、-xO3 の方が -xO4 より早くなることがあります。すべてのレベルでコンパイルを行なってみて、こうしたことが発生するかどうか試してみてください。
メモリー不足になった場合、オプティマイザは最適化レベルを落として現在の手続きをやり直すことによってメモリー不足を回復しようとします。ただし、以降の手続きについては、-xOlevel オプションで指定された最適化レベルを使用します。
-xO には 5 つのレベルがあります。以降では各レベルが SPARC および x86 プラットフォームでどのように動作するかを説明します。
SPARC プラットフォームの場合
-xO1 では、最小限の最適化 (ピープホール) が行われます。これはコンパイルの後処理におけるアセンブリレベルでの最適化です。-xO2 や -xO3 を使用するとコンパイル時間が著しく増加する場合や、スワップ領域が不足する場合だけ -xO1 を使用してください。
-xO2 では、次の基本的な局所的および大域的な最適化が行われます。
帰納的変数の削除
局所的および大域的な共通部分式の削除
計算の簡略化
コピーの伝播
定数の伝播
ループ不変式の最適化
レジスタ割り当て
基本ブロックのマージ
末尾再帰の削除
デッドコードの削除
末尾呼び出しの削除
複雑な式の展開
このレベルでは、外部変数や間接変数の参照や定義は最適化されません。
-xO3 では、-xO2 レベルで行う最適化に加えて、外部変数に対する参照と定義も最適化されます。このレベルでは、ポインタ代入の影響は追跡されません。volatile で適切に保護されていないデバイスドライバをコンパイルする場合か、シグナルハンドラの中から外部変数を修正するプログラムをコンパイルする場合は、-xO2 を使用してください。一般に、このレベルを使用すると、-xspace オプションと組み合わせないかぎり、コードサイズが大きくなります。
-xO4 では、-xO3 レベルで行う最適化レベルに加えて、同じファイルに含まれる関数のインライン化も自動的に行われます。インライン化を自動的に行なった場合、通常は実行速度が速くなりますが、遅くなることもあります。一般に、このレベルを使用すると、-xspace オプションと組み合わせないかぎり、コードサイズが大きくなります。
-xO5 では、最高レベルの最適化が行われます。これを使用するのは、コンピュータのもっとも多くの時間を小さなプログラムが使用している場合だけにしてください。このレベルで使用される最適化アルゴリズムでは、コンパイル時間が増えたり、実行時間が改善されないことがあります。このレベルの最適化によってパフォーマンスが改善される確率を高くするには、プロファイルのフィードバックを使用します。詳細は、「A.2.170 –xprofile=p」を参照してください。
x86 プラットフォームの場合
-xO1 では、基本的な最適化を行います。このレベルには、計算の簡略化、レジスタ割り当て、基本ブロックのマージ、デッドコードとストアの削除、およびピープホールの最適化が含まれます。
-xO2 では、局所的な共通部分の削除、局所的なコピーと定数の伝播、末尾再帰の削除、およびレベル 1 で行われる最適化を実行します。
-xO3 では、局所的な共通部分の削除、大域的なコピーと定数の伝播、ループ強度低下、帰納的変数の削除、およびループ不変式の最適化、およびレベル 2 で行われる最適化を実行します。
-xO4 では、レベル 3 で行う最適化レベルに加えて、同じファイルに含まれる関数の自動的なインライン化も行われます。インライン展開を自動的に行なった場合、通常は実行速度が速くなりますが、遅くなることもあります。このレベルでは一般用のフレームポインタ登録 (edp) も解放します。一般にこのレベルを使用するとコードサイズが大きくなります。
-xO5 では、最高レベルの最適化が行われます。このレベルで使用される最適化アルゴリズムでは、コンパイル時間が増えたり、実行時間が改善されないことがあります。
-g または -g0 を使用するとき、最適化レベルが -xO3 以下の場合、最大限のシンボリック情報とほぼ最高の最適化が得られます。
-g または -g0 を使用するとき、最適化レベルが -xO4 以上の場合、最大限のシンボリック情報と最高の最適化が得られます。
-g によるデバッグでは、-xOlevel が抑制されませんが、-xOlevel はいくつかの方法で -g を制限します。たとえば、-xOlevel オプションを使用すると、dbx から渡された変数を表示できないなど、デバッグの機能が一部制限されます。しかし、dbx where コマンドを使用して、シンボリックトレースバックを表示することは可能です。詳細は、『dbx コマンドによるデバッグ』を参照してください。
-xipo オプションは、-xO4 または -xO5 と一緒に使用した場合にのみ効果があります。
-xinline オプションは -xO3 未満の最適化レベルには影響を与えません。-xO4 では、-xinline オプションを指定したかどうかは関係なく、オプティマイザはどの関数をインライン化するかを判断します。-xO4 では、コンパイラはどの関数が、インライン化されたときにパフォーマンスを改善するかを判断しようとします。-xinline を指定して関数のインライン化を強制すると、実際にパフォーマンスを低下させる可能性があります。
デフォルトでは最適化は行われません。ただし、これは最適化レベルを指定しない場合にかぎり有効です。最適化レベルを指定すると、最適化を無効にするオプションはありません。
最適化レベルを設定しないようにする場合は、最適化レベルを示すようなオプションを指定しないようにしてください。たとえば、-fast は最適化を -xO5 に設定するマクロオプションです。それ以外で最適化レベルを指定するすべてのオプションでは、最適化レベルが設定されたという警告メッセージが表示されます。最適化を設定せずにコンパイルする唯一の方法は、コマンド行またはメイクファイルから最適化レ ベルを指定するオプションをすべて削除することです。
大規模な手続き (数千行のコードからなる手続き) に対して -xO3 または -xO4 を指定して最適化をすると、不合理な大きさのメモリーが必要になります。マシンのパフォーマンスが低下することがあります。
こうしたパフォーマンスの低下を防ぐには、limit コマンドを使用して、1 つのプロセスで使用できる仮想メモリーの大きさを制限します (csh(1) のマニュアルページを参照)。たとえば、仮想メモリーを 4G バイトに制限するには、次のコマンドを使用します。
example% limit datasize 4G |
このコマンドにより、データ領域が 4G バイトに達したときに、オプティマイザがメモリー不足を回復しようとします。
マシンが使用できるスワップ領域の合計容量を超える値は、制限値として指定することはできません。制限値は、大規模なコンパイル中でもマシンの通常の使用ができるぐらいの大きさにしてください。
最良のデータサイズ設定値は、要求する最適化のレベルと実メモリーの量、仮想メモリーの量によって異なります。
現在のスワップ領域を表示するには次のように入力します。swap -l
現在の実メモリーを表示するには次のように入力します。dmesg | grep mem
-xldscope -fast、-xcrossfile=n、-xprofile=p、csh(1) のマニュアルページ
OpenMP 指令による明示的並列化を使用するには、-xopenmp オプションを指定します。並列化されたプログラムをマルチスレッド環境で実行するには、実行前に OMP_NUM_THREADS 環境変数を設定しておく必要があります。
入れ子並列を有効にするには、OMP_NESTED 環境変数を TRUE に設定する必要があります。入れ子並列は、デフォルトでは無効です。
次の表に i の値を示します。
表 A–41 -xopenmp の値
値 |
意味 |
---|---|
parallel |
OpenMP プラグマの認識を有効にします。-xopenmp=parallel での最低最適化レベルは -x03 です。コンパイラは必要に応じて低い最適化レベルを -x03 に引き上げ、警告メッセージを表示します。 このフラグは、プロセッサのトークン _OPENMP も定義します。 |
noopt |
OpenMP プラグマの認識を有効にします。最適化レベルが -O3 より低い場合は、最適化レベルは上げられません。 CC -O2 -xopenmp=noopt のように、-O3 より低い最適化レベルを明示的に設定した場合、コンパイラはエラーを発生させます。-xopenmp=noopt で最適化レベルを指定しなかった場合、OpenMP プラグマが認識され、その結果プログラムが並列化されますが、最適化は行われません。 このフラグは、プロセッサのトークン _OPENMP も定義します。 |
none |
このフラグはデフォルトであり、OpenMP プラグマを認識せず、プログラムの最適化レベルを変更せず、プリプロセッサトークンを事前定義しません。 |
-xopenmp を指定しない場合は、コンパイラでは -xopenmp=none が指定されます。
-xopenmp は指定されているけれども引数は指定されていない場合、コンパイラはこのオプションを -xopenmp=parallel と設定します。
dbx を指定して OpenMP プログラムをデバッグする場合、-g と -xopenmp=noopt を指定してコンパイルすれば、並列化部分にブレークポイントを設定して変数の内容を表示することができます。
-xopenmp のデフォルトは、将来変更される可能性があります。警告メッセージを出力しないようにするには、適切な最適化を明示的に指定します。
コンパイルとリンクを別々に実行する場合は、コンパイル手順とリンク手順の両方に -xopenmp を指定してください。共有オブジェクトを作成する場合、このことは重要です。実行可能ファイルのコンパイルに使用されたコンパイラが、-xopenmp を指定して .so を作成するコンパイラよりも古いものであってはいけません。これは、OpenMP 指令を含むライブラリをコンパイルする場合に特に重要です。「3.3.3 コンパイル時とリンク時のオプション」に、コンパイル時とリンク時の両方に指定する必要があるオプションの全一覧をまとめています。
最良のパフォーマンスを得るには、OpenMP 実行時ライブラリ libmtsk.so の最新パッチが、システムにインストールされていることを確認してください。
多重処理アプリケーションを構築するために使用する OpenMP Fortran 95、C、および C++ アプリケーションプログラミングインタフェース (API) の概要については、『Solaris Studio OpenMP API ユーザーズガイド』を参照してください。
次の値は、SPARC で有効です。4k、8K、64K、512K、2M、4M、32M、256M、2G、16G、または default。
次の値は、x86/x64 で有効です。4K、2M、4M、1G、または default。
ターゲットプラットフォームに対して有効なページサイズを指定する必要があります。有効なページサイズを指定しないと、要求は実行時に暗黙的に無視されます。
Solaris オペレーティングシステムでページのバイト数を調べるには、getpagesize(3C) コマンドを使用します。Solaris オペレーティングシステムでは、ページサイズ要求に従うという保証はありません。ターゲットプラットフォームのページサイズを判断するには、pmap(1) または meminfo(2) を使用します。
-xpagesize=default を指定すると、Solaris オペレーティングシステムがページサイズを設定します。
このオプションは -xpagesize_heap と -xpagesize_stack のマクロです。これらの 2 つのオプションは -xpagesize と同じ次の引数を使用します。4k、8K、64K、512K、2M、4M、32M、256M、2G、16G、default のいずれか。両方に同じ値を設定するには -xpagesize を指定します。別々の値を指定するには個々に指定します。
-xpagesize オプションは、コンパイル時とリンク時に使用しないかぎり無効です。「3.3.3 コンパイル時とリンク時のオプション」に、コンパイル時とリンク時の両方に指定する必要があるオプションの全一覧をまとめています。
このオプションを指定してコンパイルするのは、LD_PRELOAD 環境変数を同等のオプションで mpss.so.1 に設定するか、またはプログラムを実行する前に同等のオプションを指定して Solaris コマンドの ppgsz(1) を実行するのと同じことです。詳細は Solaris のマニュアルページを参照してください。
n の値は、4k、8K、64K、512K、2M、4M、32M、256M、2G、16G、または default です。ターゲットプラットフォームに対して有効なページサイズを指定する必要があります。有効なページサイズを指定しないと、要求は実行時に暗黙的に無視されます。
Solaris オペレーティングシステムでページのバイト数を調べるには、getpagesize(3C) コマンドを使用します。Solaris オペレーティングシステムでは、ページサイズ要求に従うという保証はありません。ターゲットプラットフォームのページサイズを判断するには、pmap(1) または meminfo(2) を使用します。
-xpagesize_heap=default を指定すると、Solaris オペレーティングシステムはページサイズを設定します。
-xpagesize_heap オプションは、コンパイル時とリンク時に使用しないかぎり無効です。
このオプションを指定してコンパイルするのは、LD_PRELOAD 環境変数を同等のオプションで mpss.so.1 に設定するか、またはプログラムを実行する前に同等のオプションを指定して Solaris コマンドの ppgsz(1) を実行するのと同じことです。詳細は Solaris のマニュアルページを参照してください。
n の値は、4k、8K、64K、512K、2M、4M、32M、256M、2G、16G、または default です。ターゲットプラットフォームに対して有効なページサイズを指定する必要があります。有効なページサイズを指定しないと、要求は実行時に暗黙的に無視されます。
Solaris オペレーティングシステムでページのバイト数を調べるには、getpagesize(3C) コマンドを使用します。Solaris オペレーティングシステムでは、ページサイズ要求に従うという保証はありません。ターゲットプラットフォームのページサイズを判断するには、pmap(1) または meminfo(2) を使用します。
-xpagesize_stack=default を指定すると、Solaris オペレーティングシステムはページサイズを設定します。
-xpagesize_stack オプションは、コンパイル時とリンク時に使用しないかぎり無効 です。
このオプションを指定してコンパイルするのは、LD_PRELOAD 環境変数を同等のオプションで mpss.so.1 に設定するか、またはプログラムを実行する前に同等のオプションを指定して Solaris コマンドの ppgsz(1) を実行するのと同じことです。詳細は Solaris のマニュアルページを参照してください。
このコンパイラオプションは、プリコンパイル済みヘッダー機能を有効にします。プリコンパイル済みヘッダー機能は、ソースファイルが、大量のソースコードを含む一連の共通インクルードファイル群を共有しているようなアプリケーションのコンパイル時間を短縮させることができます。コンパイラは 1 つのソースファイルから一連のヘッダーファイルに関する情報を収集し、そのソースファイルを再コンパイルしたり、同じ一連のヘッダーファイルを持つほかのソースファイルをコンパイルしたりするときにその情報を使用します。コンパイラが収集する情報は、プリコンパイル済みヘッダーファイルに格納されます。この機能を利用するには、-xpch と -xpchstop オプションを、#pragma hdrstop 指令と組み合わせて使用できます。
関連項目
-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 |
-xpchstop=file オプションは、-xpch オプションを指定してプリコンパイル済みヘッダーファイルを作成する際の最後のインクルードファイルを指定します。コマンド行で -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 |
-xpch、pragma hdrstop
移植可能な実行可能コード (Portable Executable Code、PEC) バイナリを生成します。PEC バイナリは、自動チューニングシステム (Automatic Tuning System、ATS) と組み合わせて使用できます。ATS はチューニングとトラブルシューティングの目的で、コンパイル済み PEC バイナリを再構築する方法で動作し、下のソースコードは必要ありません。ATS についての詳細は、http://cooltools.sunsource.net/ats/ を参照してください。
-xpec で構築したバイナリは通常、-xpec なしで構築したバイナリより 5 ~ 10 倍の大きさになります。
-xpec を指定しない場合は、-xpec=no に設定されます。-xpec をフラグなしで指定した場合は、コンパイラでは -xpec=yes が指定されます。
gprof プロファイラによるプロファイル処理用にコンパイルします。
-xpg オプションでは、gprof でプロファイル処理するためのデータを収集する自動プロファイルコードをコンパイルします。このオプションを指定すると、プログラムが正常に終了したときに gmon.out を生成する実行時記録メカニズムが呼び出されます。
-xpg を指定した場合、-xprofile を使用する利点はありません。 これら 2 つは、他方で使用できるデータを生成せず、他方で生成されたデータを使用できません。
プロファイルは、64 ビット Solaris プラットフォームで prof(1) または gprof(1)、32 ビット Solaris プラットフォームで gprof を使用して生成され、おおよそのユーザー CPU 時間が含まれます。これらの時間は、メインの実行可能ファイルのルーチンと、実行可能ファイルをリンクするときにリンカー引数として指定した共有ライブラリのルーチンの PC サンプルデータ (pcsample(2) を参照) から導出されます。そのほかの共有ライブラリ (dlopen(3DL) を使用してプロセスの起動後に開かれたライブラリ) のプロファイルは作成されません。
32 ビット Solaris システムの場合、prof(1) を使用して生成されたプロファイルには、実行可能ファイルのルーチンだけが含まれます。32 ビット共有ライブラリのプロファイルは、-xpg で実行可能ファイルをリンクし、 gprof(1) を使用することで作成できます。
x86 システムでは、-xpg には -xregs=frameptr との互換性がないため、これらの 2 つのオプションは同時に使用できません。 -xregs=frameptr は -fast に含まれている点にも注意してください。
Solaris 10 ソフトウェアには、 -p でコンパイルされたシステムライブラリが含まれません。その結果、Solaris 10 プラットフォームで収集されたプロファイルには、システムライブラリルーチンの呼び出し回数が含まれません。
コンパイルとリンクを別々に行う場合は、-xpg でコンパイルしたときは -xpg でリンクする必要があります。「3.3.3 コンパイル時とリンク時のオプション」に、コンパイル時とリンク時の両方に指定する必要があるオプションの全一覧をまとめています。
-xprofile=p、analyzer(1) のマニュアルページ、パフォーマンスアナライザのマニュアル
このオプションを指定すると、64 ビット環境に移植するコードをデバッグできます。このオプションは、具体的には、V8 などの 32 ビットアーキテクチャーを V9 などの 64 ビットアーキテクチャーにコード移植する際によく見られる、型 (ポインタを含む) の切り捨て、符号の拡張、ビット配置の変更といった問題について警告します。
次に、v に指定できる値を示します。
表 A–42 -xport64 の値
値 |
意味 |
---|---|
no |
32 ビット環境から 64 ビット環境へのコード移植に関し、まったく警告を生成しない。 |
implicit |
暗黙の変換に関してのみ警告を生成する。明示的なキャストが存在する場合には警告を生成しない。 |
full |
32 ビット環境から 64 ビット環境へのコード移植に関し、あらゆる警告を生成する。具体的には、64 ビット値の切り捨て、ISO 値保護規則に基づく 64 ビットへの符号拡張、ビットフィールドの配置の変更などです。 |
-xport64 を指定しない場合のデフォルトは、-xport64=no です。-xport64 を値なしで指定した場合は、コンパイラでは -xport64=full が指定されます。
以降では、型の切り捨て、符号の拡張、ビット配置の変更を行うコード例を紹介します。
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 -xarch=v9 -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 -xarch=v9 -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 を指定した場合に V9 ではエラー診断となります。
example% cat test2.c char* p; int main() { p =(char*) (((unsigned int)p) & 0xFF); // -xarch=v9 error return 0; } example% CC -c -xarch=v9 -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 -xarch=v9 -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% |
V9 における出力
example% u.buf[0] = ffffffffff000000 u.buf[1] = 0 |
警告が生成されるのは、-m64 などのオプションを指定して 64 ビットモードでコンパイルしたときだけです。
先読みをサポートするアーキテクチャーで先読み命令を有効にします。
明示的な先読みは、測定値によってサポートされた特殊な環境でのみ使用すべきです。
a には次のいずれかを指定します。
表 A–43 -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 に近い係数の値から始め、アプリケーションに対してパフォーマンステストを実施します。そのあと、テストの結果に応じて係数を増減し、パフォーマンステストを再実行します。係数の調整を継続し、最適なパフォーマンスに到達するまでパフォーマンステストを実行します。係数を小刻みに増減すると、しばらくはパフォーマンスに変化がなく、突然変化し、再び平常に戻ります。
デフォルトは -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 が想定されます。
このオプションは、置き換えられる代わりに蓄積されます。
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 とともに使用しないかぎり無視されます。
明示的な先読みは、測定値によってサポートされた特殊な環境でのみ使用すべきです。
コンパイラは、広範囲なマシンやアプリケーション間で最適なパフォーマンスを得るために先読み機構を調整しますが、-xprefetch=latx:factor は、パフォーマンステストで明らかに利点があることが確認された場合にかぎり使用してください。使用先読み応答時間は、リリースごとに変わる可能性があります。したがって、別のリリースに切り替えたら、その都度応答時間係数の影響を再テストすることを推奨します。
ここで a は [no%]indirect_array_access です。
このオプションは、直接メモリーアクセスに対して先読み命令が生成されるのと同じ方法で、-xprefetch_level オプションが指示するループに対して間接先読み命令を生成するかどうかを制御します。
-xprefetch_auto_type の値が指定されていない場合、-xprefetch_auto_type=no%indirect_array_access に設定されます。
-xdepend、-xrestrict、および -xalias_level などのオプションは、メモリー別名を明確化する情報の生成に役立つため、間接先読み候補の計算の攻撃性に影響し、このため、自動的な間接先読みの挿入が促進されることがあります。
-xprefetch_level=i オプションを使用して、-xprefetch=auto で決定した先読み命令の自動挿入の攻撃性を調整することができます。-xprefetch_leve が高くなるほど、コンパイラはより攻撃的に、つまりより多くの先読みを挿入します。
-xprefetch_level に適した値は、アプリケーションでのキャッシュミス数によって異なります。-xprefetch_level の値を高くするほど、キャッシュミスが多いアプリケーションの性能が向上する可能性が高くなります。
i には 1、2、3 のいずれかを指定します。
表 A–44 -xprefetch_level の値
値 |
意味 |
---|---|
1 |
先読み命令の自動的な生成を有効にします。 |
2 |
-xprefetch_level=1 の対象以外にも、先読み挿入対象のループを追加します。-xprefetch_level=1 で挿入された先読み以外に、先読みが追加されることがあります。 |
3 |
-xprefetch_level=2 の対象以外にも、先読み挿入対象のループを追加します。-xprefetch_level=2 で挿入された先読み以外に、先読みが追加されることがあります。 |
デフォルトは、-xprefetch=auto を指定した場合は -xprefetch_level=1 になります。
このオプションは、-xprefetch=auto を指定し、最適化レベルを 3 (-xO3) 以上に設定して、先読みをサポートするプラットフォーム (v9、v9a、v9b、generic64、native64) でコンパイルした場合にだけ有効です。
プロファイルのデータを収集したり、プロファイルを使用して最適化したりします。
p には、collect[ :profdir]、use[ :profdir]、または tcov[ :profdir] を指定する必要があります。
このオプションを指定すると、実行頻度のデータが収集されて実行中に保存されます。このデータを以降の実行で使用すると、パフォーマンスを向上させることができます。プロファイルの収集は、マルチスレッド対応のアプリケーションにとって安全です。すなわち、独自のマルチタスク (-mt) を実行するプログラムをプロファイリングすることで、正確な結果が得られます。このオプションは、最適化レベルを -xO2 かそれ以上に指定するときにのみ有効になります。コンパイルとリンクを別々の手順で実行する場合は、リンク手順とコンパイル手順の両方で同じ -xprofile オプションを指定する必要があります。
実行頻度のデータを集めて保存します。のちに -xprofile=use を指定した場合にオプティマイザがこれを使用します。コンパイラによって文の実行頻度を測定するためのコードが生成されます。
-xMerge、-ztext、および -xprofile=collect を一緒に使用しないでください。-xMerge を指定すると、静的に初期化されたデータを読み取り専用記憶領域に強制的に配置します。 -ztext を指定すると、位置に依存するシンボルを読み取り専用記憶領域内で再配置することを禁止します。-xprofile=collect を指定すると、書き込み可能記憶領域内で、静的に初期化された、位置に依存するシンボルの再配置を生成します。
プロファイルディレクトリ名として profdir を指定すると、この名前が、プロファイル化されたオブジェクトコードを含むプログラムまたは共有ライブラリの実行時にプロファイルデータが保存されるディレクトリのパス名になります。profdir パス名が絶対パスではない場合、プログラムがオプション -xprofile=use:profdir でコンパイルされるときの現在の作業用ディレクトリの相対パスとみなされます。プロファイルディレクトリ名を指定しないと、プロファイルデータは、program.profile という名前のディレクトリに保存されます (program はプロファイル化されたプロセスのメインプログラムのベース名)。
例 [1]: プログラムが構築されたディレクトリと同じディレクトリにある 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 |
例 [2]: ディレクトリ/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 |
環境変数の SUN_PROFDATA と SUN_PROFDATA_DIR を設定して、-xprofile=collect を指定してコンパイルされたプログラムがどこにプロファイルデータを入れるかを制御できます。これらの環境変数を設定すると、-xprofile=collect データが $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 を指定してください。
-xprofile=collect[: profdir] でコンパイルされたコードから収集された実行頻度データを使用して、プロファイル化されたコードが実行されたときに実行された作業用の最適化が行えます。profdir は、-xprofile=collect[: 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(1) を使用する基本のブロックカバレッジ分析用の命令オブジェクトファイル。
オプションの profdir 引数を指定すると、コンパイラは指定された場所にプロファイルディレクトリを作成します。プロファイルディレクトリに保存されたデータは、tcov(1) または -xprofile=use:profdir を付けたコンパイラで使用できます。オプションの profdir パス名を省略すると、プロファイル化されたプログラムの実行時にプロファイルディレクトリが作成されます。プロファイルディレクトリに保存されたデータは、tcov(1) でのみ使用できます。プロファイルディレクトリの場所は、環境変数 SUN_PROFDATA および SUN_PROFDATA_DIR を使用して指定できます。
profdir で指定された場所が絶対パス名ではない場合、コンパイル時に、現在のオブジェクトファイルが作成されたディレクトリの相対パスとみなされます。いずれかのオブジェクトファイルに profdir を指定する場合は、同じプログラムのすべてのオブジェクトファイルに対して同じ場所を指定する必要があります。場所が profdir で指定されているディレクトリには、プロファイル化されたプログラムを実行するときにすべてのマシンからアクセスできる必要があります。プロファイルディレクトリはその内容が必要なくなるまで削除できません。コンパイラでプロファイルディレクトリに保存されたデータは、再コンパイルする以外復元できません。
例 [1]: 1 つ以上のプログラムのオブジェクトファイルが -xprofile=tcov:/test/profdata でコンパイルされる場合、/test/profdata.profile という名前のディレクトリがコンパイラによって作成されて、プロファイル化されたオブジェクトファイルを表すデータの保存に使用されます。実行時に同じディレクトリを使用して、プロファイル化されたオブジェクトファイルに関連付けられた実行データを保存できます。
例 [2]: myprog という名前のプログラムが -xprofile=tcov でコンパイルされ、ディレクトリ /home/joe で実行されると、実行時にディレクトリ /home/joe/myprog.profile が作成されて、実行時プロファイルデータの保存に使用されます。
(SPARC) collect 段階で保存されたコンパイルデータを再利用して use 段階のコンパイル時間を向上させるには、-xprofile=collect|use で -xprofile_ircache[=path] を使用します。
大きなプログラムでは、中間データが保存されるため、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 |
(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 がオブジェクトファイルのパス名と一致しないことが確認されるまで、オブジェクトファイルのパス名と比較されます。
自動的な並列化を実行するときにループの縮約を解析します。このオプションは、-xautopar が指定する場合のみ有効です。それ以外の場合は、コンパイラは警告を発行します。
縮約の認識が有効な場合、コンパイラは内積、最大値発見、最小値発見などの縮約を並列化します。これらの縮約によって非並列化コードによる四捨五入の結果と異なります。
r には、appl、float、frameptr サブオプションのいずれか 1 つ以上をコンマで区切って指定します。
サブオプションの前に no% を付けるとそのサブオプションは無効になります。
—xregs サブオプションは、特定のハードウェアプラットフォームでしか使用できません。
例: -xregs=appl,no%float
表 A–45 -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 を無視し、警告を表示します。 |
SPARC のデフォルトは -xregs=appl,float です。
x86 のデフォルトは -xregs=no%frameptr です。
x86 システムでは、-xpg には -xregs=frameptr との互換性がないため、これらの 2 つのオプションは同時に使用できません。 -xregs=frameptr は -fast に含まれている点にも注意してください。
アプリケーションにリンクする共有ライブラリ用のコードは、-xregs=no%appl,float を指定してコンパイルすることをお勧めします。少なくとも、共有ライブラリとリンクするアプリケーションがこれらのレジスタの割り当てを認識するように、共有ライブラリがアプリケーションレジスタを使用する方法を明示的に示す必要があります。
たとえば、大局的な方法で (重要なデータ構造体を示すためにレジスタを使用するなど) レジスタを使用するアプリケーションは、ライブラリと確実にリンクするため、-xregs=no%appl なしでコンパイルされたコードを含むライブラリがアプリケーションレジスタをどのように使用するかを正確に特定する必要があります。
ポインタ型の値をとる関数の引数を制限付きポインタとして扱います。f には次の値のいずれかを指定します。
表 A–46 -xrestrict の値
値 |
意味 |
---|---|
%all |
ファイル全体のすべてのポインタ型引数を制限付きとして扱います。 |
%none |
ファイル内のどのポインタ型引数も制限付きとして扱いません。 |
%source |
メインソースファイル内に定義されている関数のみ制限付きにします。インクルードファイル内に定義されている関数は制限付きにしません。 |
fn[,fn...] |
1 つ以上の関数名のコンマ区切りのリスト。関数リストが指定された場合は、指定された関数内のポインタ型引数を制限付きとして扱います。詳細については、次の「A.2.175.1 制限付きポインタ」を参照してください。 |
このコマンド行オプションは独立して使用できますが、最適化時に使用するのがもっとも適しています。たとえば、次のようなコマンドを使用します。
%CC -xO3 -xrestrict=%all prog.cc |
このコマンドでは、ファイル prog.c 内のすべてのポインタ引数を制限付きポインタとして扱います。次のようなコマンド行があるとします。
%CC -xO3 -xrestrict=agc prog.cc |
このコマンドでは、ファイル prog.c 内の関数 agc のすべてのポインタ引数を制限付きポインタとして扱います。
C プログラミング言語の C99 標準には restrict キーワードが導入されましたが、このキーワードは最新の C++ 標準に含まれない点に注意してください。一部のコンパイラには、C99 restrict キーワードの C++ 言語拡張があり、__restrict または __restrict__ と表記されることがありますが、Solaris Studio C++ コンパイラには現在のところこの拡張はありません。-xrestrict オプションは、ソースコードで restrict キーワードを部分的に置き換えます。このキーワードを使用しても、関数のすべてのポインタ引数を restrict と宣言する必要があるわけではありません。このキーワードは、主に最適化の機会に影響を与え、関数に渡すことができる引数を制限します。ソースコードから restict または __restrict のすべてのインスタンスを削除しても、プログラムの見た目の動作には影響しません。
デフォルトは %none で、-xrestrict と指定すると -xrestrict=%sourcel と指定した場合と同様の結果が得られます。
コンパイラが効率よくループを並列化できるようにするには、左辺値が記憶領域の特定の領域を示している必要があります。別名とは、記憶領域の決まった位置を示していない左辺値のことです。オブジェクトへの 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 を正しく使用することはとても重要です。区別できないオブジェクトを指しているポインタを制限付きポインタにしてしまうと、ループを正しく並列化できなくなり、不定な動作をすることになります。たとえば、関数 vsq() のポインタ a および b が重なりあっているオブジェクトを指している場合には、b[i] と a[i+1] などが同じオブジェクトである可能性があります。このとき a および b が制限付きポインタとして宣言されていなければ、ループは順次実行されます。a および b が間違って制限付きであると宣言されていれば、コンパイラはループを並列実行するようになりますが、この場合 b[i+1] の結果は b[i] を計算したあとでなければ得られないので、安全に実行することはできません。
オブジェクト (.o) ファイルなしに dbx でデバッグできるようにします。
このオプションを指定すると、すべてのデバッグ情報が実行可能ファイルにコピーされます。dbx のパフォーマンスやプログラムの実行時のパフォーマンスにはあまり影響はありませんが、より多くのディスク容量が必要となります。
このオプションは、-xdebugformat=stabs で指定した場合だけ影響があります。この場合のデフォルトは、デバッグデータを実行可能ファイルにコピーしません。デフォルトのデバッグ形式である -xdebugformat=dwarf を使用する場合は、デバッグデータは常に実行可能ファイルにコピーされます。コピーを防止するオプションはありません。
SPARC: メモリー保護違反が発生しなかったとコンパイラで想定されるようにすることができます。
このオプションを使用すると、コンパイラでは SPARC V6 アークテクチャーで違反のないロード命令を使用できます。
このオプションは、最適化レベルの -xO5 と、次のいずれかの値の -xarch を組み合わせた場合にだけ有効です。m32 と m64 の両方で sparc、sparcvis、-sparcvis2、または -sparcvis3。
アドレスの位置合わせが合わない、またはセグメンテーション侵害などの違反が発生した場合は違反のないロードはトラップを引き起こさないので、このオプションはこのような違反が起こる可能性のないプログラムでしか使用しないでください。ほとんどのプログラムではメモリーに関するトラップは起こらないので、大多数のプログラムでこのオプションを安全に使用できます。例外条件の処理にメモリーベースのトラップを明示的に使用するプログラムでは、このオプションは使用しないでください。
非推奨、使用しないでください。ソースブラウザ機能は廃止されました。このオプションはメッセージを表示せずに無視されます。
非推奨、使用しないでください。ソースブラウザ機能は廃止されました。このオプションはメッセージを表示せずに無視されます。
SPARC: コードサイズが大きくなるような最適化を行いません。
コンパイラにハードウェアシステムを正確に指定すると、プログラムによってはパフォーマンスが向上します。プログラムのパフォーマンスが重要な場合は、対象となるハードウェアを正確に指定してください。これは特に、新しい 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 設定にならない場合があります。
この節では、—xtarget 値をプラットフォームごとに説明します。次の表は、すべてのプラットフォーム向けの —xtarget の値を一覧表示します。
表 A–47 すべてのプラットフォームでの -xtarget の値
値 |
意味 |
---|---|
native |
ホストシステムで最高のパフォーマンスが得られます。コンパイラは、ホストシステム用に最適化されたコードを生成します。コンパイラは自身が動作しているマシンで利用できるアーキテクチャー、チップ、キャッシュ特性を判定します。 |
native64 |
ホストシステムで 64 ビットのオブジェクトバイナリの最高のパフォーマンスが得られます。コンパイラは、ホストシステム用に最適化された 64 ビットのオブジェクトバイナリを生成します。コンパイラが動作しているマシンで使用できる 64 ビットのアーキテクチャー、チップ、キャッシュ特性を判定します。 |
generic |
これはデフォルト値です。汎用アーキテクチャー、チップ、およびキャッシュで最高のパフォーマンスが得られます。 |
generic64 |
大多数の 64 ビットのプラットフォームのアーキテクチャーで 64 ビットのオブジェクトバイナリの最適なパフォーマンスを得るためのパラメータを設定します。 |
システム名 |
指定するシステムで最高のパフォーマンスが得られます。 対象となる実際のシステムを表すシステム名を、次のリストから選択してください。 |
SPARC または UltraSPARC V9 での 64 ビット Solaris ソフトウェアのコンパイルは、-m64 オプションで指定します。-xtarget を指定し、native64 または generic64 以外のフラグを付ける場合は、-m64 オプションも次のように指定する必要があります。-xtarget=ultra ... -m64。この指定を行わない場合は、コンパイラは 32 ビットメモリーモデルを使用します。
表 A–48 SPARC アーキテクチャーでの -xtarget の展開
-xtarget= |
-xarch |
-xchip |
-xcache |
---|---|---|---|
generic |
generic |
generic |
generic |
ultra |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra1/140 |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra1/170 |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra1/200 |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra2 |
v8plusa |
ultra2 |
16/32/1:512/64/1 |
ultra2/1170 |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra2/1200 |
v8plusa |
ultra |
16/32/1:1024/64/1 |
ultra2/1300 |
v8plusa |
ultra2 |
16/32/1:2048/64/1 |
ultra2/2170 |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra2/2200 |
v8plusa |
ultra |
16/32/1:1024/64/1 |
ultra2/2300 |
v8plusa |
ultra2 |
16/32/1:2048/64/1 |
ultra2e |
v8plusa |
ultra2e |
16/32/1:256/64/4 |
ultra2i |
v8plusa |
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 |
ultraT3 |
sparcvis3 |
ultraT3 |
8/16/4:6144/64/24 |
sparc64vi |
sparcfmaf |
sparc64vi |
128/64/2:5120/64/10 |
sparc64vii |
sparcima |
sparc64vii |
64/64/2:5120/256/10 |
UltraSPARC IVplus、UltraSPARC T1、および UltraSPARC T2 チップのキャッシュプロパティーについての詳細は、「A.2.113 -xcache=c」を参照してください。 |
64 ビット x86 プラットフォームでの 64 ビット Solaris ソフトウェアのコンパイルは、-m64 オプションで指定します。-xtarget を指定し、native64 または generic64 以外のフラグを付ける場合は、-m64 オプションも次のように指定する必要があります。-xtarget=opteron ... -m64。この指定を行わない場合は、コンパイラは 32 ビットメモリーモデルを使用します。
表 A–49 x86 プラットフォームでの -xtarget の値
-xtarget= |
-xarch |
-xchip |
-xcache |
---|---|---|---|
generic |
generic |
generic |
generic |
opteron |
sse2 |
opteron |
64/64/2:1024/64/16 |
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 |
SPARC および x86 で、-xtarget を指定しないと、-xtarget=generic が想定されます。
-xtarget オプションは、市販で購入したプラットフォーム上で使用する -xarch、-xchip、-xcache の組み合わせを素早く、簡単に指定するためのマクロです。-xtarget の意味は = のあとに指定した値を展開したものにあります。
-xtarget=sun4/15 は -xarch=v8a -xchip=micro -xcache=2/16/1 を意味します。
-xarch=v9|v9a|v9b オプションで指定する、SPARC V9 アーキテクチャーのコンパイル。-xtarget=ultra や ultra2 の設定は、必要でないか、十分ではありません。-xtarget を指定する場合、-xarch=v9|v9a|v9b オプションは -xtarget よりもあとに表示される必要があります。次に例を示します。
-xarch=v9 -xtarget=ultra |
前述の指定は次のように展開され、-xarch の値が v8 に戻ります。
-xarch=v9 -xarch=v8 -xchip=ultra -xcache=16/32/1:512/64/1 |
正しくは、次のように、-xarch を -xtarget よりもあとに指定します。次に例を示します。
–xtarget=ultra -xarch=v9 |
別々の手順でコンパイルしてリンクする場合は、コンパイル手順とリンク手順で同じ -xtarget の設定値を使用する必要があります。
スレッドローカルな変数の実装を制御するには -xthreadvar を指定します。コンパイラのスレッドローカルな記憶機能を利用するには、このオプションを __thread 宣言指定子と組み合わせて使用します。__thread 指示子を使用してスレッド変数を宣言したあとは、-xthreadvar を指定して動的 (共有) ライブラリの位置に依存しないコード (PIC 以外のコード) でスレッド固有の記憶領域を使用できるようにします。__thread の使用方法の詳細については、「4.2 スレッドローカルな記憶装置」を参照してください。
o には、次のいずれかを指定します。
表 A–50 -xthreadvar の値
値 |
意味 |
---|---|
[no%]dynamic |
動的ロード用の変数をコンパイルします [しません]。-xthreadvar=no%dynamic を指定すると、スレッド変数へのアクセスは非常に早くなりますが、動的ライブラリ内のオブジェクトファイルは使用できません。すなわち、実行可能ファイル内のオブジェクトファイルだけが使用可能です。 |
-xthreadvar を指定しない場合、コンパイラが使用するデフォルトは位置独立コード (PIC) が有効になっているかどうかによって決まります。位置独立コードが有効になっている場合、オプションは -xthreadvar=dynamic に設定されます。位置独立コードが無効になっている場合、オプションは -xthreadvar=no%dynamic に設定されます。
引数を指定しないで -xthreadvar を指定する場合、オプションは -xthreadvar=dynamic に設定されます。
-mt オプションは、__thread を使用しているファイルのコンパイルおよびリンクを実行するときに指定する必要があります。
動的ライブラリ内に位置に依存するコードがある場合、-xthreadvar を指定する必要があります。
リンカーは、動的ライブラリ内の位置依存コード (非 PIC) スレッド変数と同等のスレッド変数はサポートできません。非 PIC スレッド変数は非常に高速なため、実行可能ファイルのデフォルトとして指定できます。
-xcode、-KPIC、-Kpic
CC ドライバが、さまざまなコンパイル過程の実行時間を報告します。
ISO/ANSI C 標準の定義に従って文字表記シーケンスの認識を有効または無効にします。
コンパイラが文字表記シーケンスとして解釈している疑問符 (?) の入ったリテラル文字列がソースコードにある場合は、-xtrigraph=no サブオプションを使用して文字表記シーケンスの認識をオフにすることができます。
-xtrigraphs には、次のいずれかを指定します。
表 A–51 -xtrigraphs の値
値 |
意味 |
---|---|
yes |
コンパイル単位全体の 3 文字表記の認識を有効にします。 |
no |
コンパイル単位全体の 3 文字表記の認識を無効にします。 |
コマンド行に -xtrigraphs オプションを指定しなかった場合、コンパイラは -xtrigraphs=yes を使用します。
-xtrigraphs だけを指定すると、コンパイラは -xtrigraphs=yes を使用しま す。
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 (??) |
3 文字表記については、『C ユーザーズガイド』の ANSI/ISO C への移行に関する章を参照してください。
可能な場合は、ループを展開します。
このオプションは、コンパイラがループを最適化 (展開) するかどうかを指定します。
n が 1 の場合、コンパイラはループを展開しません。
n が 1 より大きな整数の場合は、-unroll=n によってコンパイラがループを n 回展開します。
コンパイラにオブジェクトファイル内で UTF-16 文字列に変換させたい文字列リテラルまたは文字リテラルがコードに含まれる場合、を使用します。このオプションが指定されていない場合、コンパイラは 16 ビット文字列リテラルの生成、認識のいずれも行いません。このオプションを使用すれば、U"ASCII_string" 文字列リテラルが unsigned short int の配列として認識されます。このような文字列はまだ標準となっていないので、このオプションは、非標準 C++ の認識を可能にします。
すべてのファイルを、このオプションによってコンパイルしなければならないわけではありません。
ISO10646 UTF--16 文字列リテラルを使用する国際化アプリケーションをサポートする必要がある場合、-xustr=ascii_utf-16_ushort を指定します。-xustr=no を指定すれば、コンパイラが U"ASCII_string" 文字列リテラルまたは文字リテラルを認識しなくなります。このオプションのコマンド行の右端にあるインスタンスは、それまでのインスタンスをすべて上書きします。
-xustr=ascii_ustf16_ushort は、U"ASCII_string" 文字列リテラルを指定しなくてもかまいません。そのようにしても、エラーとはなりません。
デフォルトは -xustr=no です。引数を指定しないで -xustr を指定した場合、コンパイラはこの指定を受け付けず、警告を出力します。C または C++ 規格で構文の意味が定義されると、デフォルト値が変わることがあります。
次の例では、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'; |
ベクタライブラリ関数の呼び出しの自動生成や、SIMD (Single Instruction Multiple Data) 命令の生成ができます。このオプションを使用するときは -fround=nearest を指定することによって、デフォルトの丸めモードを使用する必要があります。
-xvector オプションを指定するには、最適化レベルが -xO3 かそれ以上に設定されていることが必要です。最適化レベルが指定されていない場合や —xO3 よりも低い場合はコンパイルは続行されず、メッセージが表示されます。
a は、次の指定と同じです。
表 A–52 -xvector のフラグ
値 |
意味 |
---|---|
[no%]lib |
(Solaris のみ)コンパイラは可能な場合はループ内の数学ライブラリへの呼び出しを、同等のベクトル数学ルーチンへの単一の呼び出しに変換します [しません]。大きなループカウントを持つループでは、これによりパフォーマンスが向上します。 |
[no%]simd |
コンパイラはネイティブ x86 SSE SIMD 命令を使用して特定のループのパフォーマンスを向上させます [させません]。ストリーミング拡張機能は、x86 で最適化レベルが 3 かそれ以上に設定されている場合にデフォルトで使用されます。サブオプション no%simd を使用すると、この機能を無効にできます。 コンパイラは、ストリーミング拡張機能がターゲットのアーキテクチャーに存在する場合、つまりターゲットの ISA が SSE2 以上である場合にのみ SIMD を使用します。たとえば、最新のプラットフォームで -xtarget=woodcrest、—xarch=generic64、-xarch=sse2、-xarch=sse3、または -fast を指定して使用できます。ターゲットの ISA にストリーミング拡張機能がない場合、このサブオプションは無効です。 |
yes |
このオプションは、非推奨です。代わりに、-xvector=lib を指定します。 |
no |
このオプションは、非推奨です。代わりに、-xvector=none を指定します。 |
デフォルトは、x86 では -xvector=simd で、SPARC プラットフォームでは -xvector=%none です。サブオプションなしで -xvector を指定すると、コンパイラでは、x86 では -xvector=simd,lib、SPARC (Solaris) では -xvector=lib、および -xvector=simd (Linux) が使用されます。
コンパイラは、リンク時に libmvec ライブラリを取り込みます。
コンパイルとリンクを別々のコマンドで実行する場合は、リンク時の CC コマンドに必ず -xvector を使用してください。「3.3.3 コンパイル時とリンク時のオプション」に、コンパイル時とリンク時の両方に指定する必要があるオプションの全一覧をまとめています。
(SPARC) VIS instruction-set Software Developers Kit (VSDK) に定義されているアセンブリ言語のテンプレートを使用する場合は、-xvis=[yes|no] コマンドを 使用します。
VIS 命令セットは、SPARC v9 命令セットの拡張です。UltraSPARC プロセッサは 64 ビットでも、多くの場合、特にマルチメディアアプリケーションではデータサイズが 8 ビットまたは 16 ビットに制限されています。VIS 命令では、1 命令で 4 つの 16 ビットデータを処理できるので、画像、線形代数、信号処理、オーディオ、ビデオ、ネットワーキングなどの新しいメディアを扱うアプリケーションのパフォーマンスが大幅に向上します。
デフォルトは -xvis=no です。-xvis と指定すると -xvis=yes と指定した場合と同様の結果が得られます。
OpenMP を使用する場合に正しくない結果をもたらす可能性のある、並列プログラミングに関連する潜在的な問題に関して、警告を発行します。-xopenmp および OpenMP API 指令とともに使用します。
次の状況が検出された場合は、コンパイラは警告を発行します。
異なるループ繰り返し間でデータに依存関係がある場合に、MP 指令を使用して並列化されたループ。
OpenMP データ共有属性節に問題がある場合。たとえば、「shared」と宣言された変数に、OpenMP 並列領域からアクセスするとデータ競合が発生する可能性がある場合や、並列領域の中に値を持つ変数を「private」と宣言し、並列領域よりあとでその変数を使用する場合です。
すべての並列化命令が問題なく処理される場合、警告は表示されません。
次に例を示します。
CC -xopenmp -xvpara any.cc |
Solaris Studio のコンパイラは OpenMP 2.5 API の並列化をサポートします。そのため、MP プラグマ命令は非推奨で、サポートされません。OpenMP API への移植については、『OpenMP API ユーザーズガイド』を参照してください。
ゼロ以外の終了状態を返すことによって、すべての警告をエラーとして扱います。
構成要素 c がある場所の新しいパスを指定します。
構成要素の場所を指定する場合、新しいパス名はパス/構成要素名の形式になります。このオプションは ld に渡されます。
c には次の値のいずれかを指定します。
表 A–53 -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 |
すべてのコンパイラ構成要素を検索するときのディレクトリを指定します。構成要素がパスにない場合は、コンパイラがインストールされているディレクトリに戻って検索が行われます。 |
P |
デフォルトのライブラリ検索パスにパスを追加します。デフォルトのライブラリ検索パスの前にこのパスが調べられます。 |
S |
起動用のオブジェクトファイルのデフォルトのディレクトリを変更します。 |
コマンド行に複数の -Y オプションを配置できます。2 つ以上の -Y オプションが 1 つの項目に適用されている場合には、最後に指定されたものが有効です。
リンカーとライブラリ
リンクエディタのオプション。詳細は、ld(1) のマニュアルページと Solaris 関連のマニュアル『リンカーとライブラリ』を参照してください。
この付録では、プラグマについて説明します。「プラグマ」とは、コンパイラに特定の情報を渡すために使用するコンパイラ指令です。プラグマを使用すると、コンパイル内容を詳細に渡って制御できます。たとえば、pack プラグマを使用すると、構造体の中のデータの配置を変えることができます。プラグマは「指令」とも呼ばれます。
プリプロセッサキーワード pragma は C++ 標準の一部ですが、書式、内容、および意味はコンパイラごとに異なります。プラグマは C++ 標準には定義されていません。
したがってプラグマに依存するコードには移植性はありません。プラグマに依存するコードは移植性がありません。
次に、C++ コンパイラのプラグマのさまざまな書式を示します。
#pragma keyword #pragma keyword ( a [ , a ] ...) [ , keyword ( a [ , a ] ...) ] ,... #pragma sun keyword |
変数 keyword は特定の指令を示し、a は引数を示します。
ここで示すいくつかのプラグマは、引数として関数名をとります。その関数が多重定義されている場合、プラグマは、その引数として、その直前の関数宣言を使用します。次の例を考えてみましょう。
int bar(int); int foo(int); int foo(double); #pragma does_not_read_global_data(foo, bar) |
この例の foo は、プラグマの直前の foo の宣言である foo(double) を意味し、bar は、単に宣言されている bar である bar(int) を意味します。ここで、foo が再び多重定義されている次の例を考えてみます。
int foo(int); int foo(double); int bar(int); #pragma does_not_read_global_data(foo, bar) |
この例の bar は、単に宣言されている bar である bar(int) を意味します。しかし、プラグマは、どのバージョンの foo を使用すべきか分かりません。この問題を解決するには、プラグマが使用すべき foo の定義の直後にプログラムを置く必要があります。
次のプラグマは、この節で説明した方法で選択を行います。
does_not_read_global_data
does_not_return
does_not_write_global_data
no_side_effect
opt
rarely_called
returns_new_memory
この節では、C++ コンパイラにより認識されるプラグマキーワードについて説明します。
#pragma align integer(variable [,variable...]) |
align を使用すると、指定したすべての変数のメモリー境界を integer バイト境界に揃えることができます (デフォルト値より優先されます)。ただし、次の制限があります。
integer は、1 ~ 128 の範囲にある 2 の二乗、つまり、1、2、4、8、16、32、64、128 のいずれかでなければいけません。
variable には、大域変数か静的変数を指定します。局所変数またはクラスメンバー変数は指定できません。
指定された境界がデフォルトより小さい場合は、デフォルトが優先します。
この #pragma 行は、指定した変数の宣言より前になければいけません。前にないと、この #pragma 行は無視されます。
この #pragma 行で指定されていても、プラグマ行に続くコードの中で宣言されない変数は、すべて無視されます。次に、正しく宣言されている例を示します。
#pragma align 64 (aninteger, astring, astruct) int aninteger; static char astring[256]; struct S {int a; char *b;} astruct; |
#pragma align を名前空間内で使用するときは、符号化された名前を使用する必要があります。たとえば、次のコード中の、#pragma align 文には何の効果もありません。この問題を解決するには、#pragma align 文の a、b、および c を符号化された名前に変更します。
namespace foo { #pragma align 8 (a, b, c) static char a; static char b; static char c; } |
#pragma does_not_read_global_data(funcname [, funcname]) |
このプラグマは、指定したルーチンが直接的にも間接的にも大域データを読み込まないことをコンパイラに宣言します。この表明により、そうしたルーチンへの呼び出し前後のコードをさらに最適化することができます。具体的には、代入文やストア命令をそうした呼び出しの前後に移動することができます。
このプラグマを使用できるのは、指定した関数のプロトタイプを宣言したあとに限定されます。大域アクセスに関する表明が真でない場合は、プログラムの動作は未定義になります。
プラグマがその引数として多重定義関数を処理する方法の詳細は、「B.1.1 プラグマの引数としての多重定義関数」を参照してください。
#pragma does_not_return(funcname [, funcname]) |
指定した関数への呼び出しが復帰しないことをコンパイラに表明します。この表明により、コンパイラは、指定された関数への呼び出しが戻らないと仮定して最適化を行うことができます。たとえば、呼び出し側で終了したライフ回数を登録すると、より多くの最適化が可能となります。
指定した関数が復帰した場合は、プログラムの動作は未定義になります。
次の例のとおり、このプラグマを使用できるのは、指定した関数のプロトタイプを宣言したあとに限定されます。
extern void exit(int); #pragma does_not_return(exit) extern void __assert(int); #pragma does_not_return(__assert) |
プラグマがその引数として多重定義関数を処理する方法の詳細は、「B.1.1 プラグマの引数としての多重定義関数」を参照してください。
#pragma does_not_write_global_data(funcname [, funcname]) |
このプラグマは、指定したルーチンが直接的にも間接的にも大域データを書き込まないことをコンパイラに宣言します。この表明により、そうしたルーチンへの呼び出し前後のコードをさらに最適化することができます。具体的には、代入文やストア命令をそうした呼び出しの前後に移動することができます。
このプラグマを使用できるのは、指定した関数のプロトタイプを宣言したあとに限定されます。大域アクセスに関する表明が真でない場合は、プログラムの動作は未定義になります。
プラグマがその引数として多重定義関数を処理する方法の詳細は、「B.1.1 プラグマの引数としての多重定義関数」を参照してください。
#pragma dumpmacros (value[,value...]) |
マクロがプログラム内でどのように動作しているかを調べたいときに、このプラグマを使用します。このプラグマは、定義済みマクロ、解除済みマクロ、実際の使用状況といった情報を提供します。マクロの処理順序に従って、標準エラー (stderr) に出力します。dumpmacros プラグマは、ファイルが終わるまで、または #pragma end_dumpmacro に到達するまで、有効です。「B.2.6 #pragma end_dumpmacros」 を参照してください。value の代わりに次の引数を使用できます。
値 |
意味 |
---|---|
defs |
すべての定義済みマクロを出力します |
undefs |
すべての解除済みマクロを出力します |
use |
使用されているマクロの情報を出力します |
loc |
defs、undefs、use の位置 (パス名と行番号) も出力します |
conds |
条件付き指令で使用したマクロの使用情報を出力します |
sys |
システムヘッダーファイルのマクロについて、すべての定義済みマクロ、解除済みマクロ、使用状況も出力します |
サブオプション loc、conds、sys は、オプション defs、undefs、use の修飾子です。loc、conds、sys は、単独では効果はありません。たとえば #pragma dumpmacros=loc,conds,sys には、何も効果はありません。
dumpmacros プラグマとコマンド行オプションの効果は同じですが、プラグマがコマンド行オプションを上書きします。「A.2.122 -xdumpmacros[= value[,value...]]」を参照してください。
dumpmacros プラグマは入れ子にならないので、次のコードでは #pragma end_dumpmacros が処理されるとマクロ情報の出力が停止します。
#pragma dumpmacros (defs, undefs) #pragma dumpmacros (defs, undefs) ... #pragma end_dumpmacros |
dumpmacros プラグマの効果は累積的です。次のものは、
#pragma dumpmacros(defs, undefs) #pragma dumpmacros(loc) |
次と同じ効果を持ちます。
#pragma dumpmacros(defs, undefs, loc) |
オプション #pragma dumpmacros=use,no%loc を使用した場合、使用したマクロそれぞれの名前が一度だけ出力されます。オプション #pragma dumpmacros=use,loc を使用した場合、マクロを使用するたびに位置とマクロ名が出力されます。
#pragma end_dumpmacros |
このプラグマは、dumpmacrospragma が終わったことを通知し、マクロ情報の出力を停止します。dumpmacros プラグマ終了時に end_dumpmacros プラグマを使用しなかった場合、dumpmacros プラグマはファイルが終わるまで出力を生成し続けます。
#pragma error_messages (on|off|default, tag… tag)
このエラーメッセージプラグマは、ソースプログラムの中から、コンパイラが発行するメッセージを制御可能にします。プラグマは警告メッセージにのみ効果があります。-w コマンド行オプションは、すべての警告メッセージを無効にすることでこのプラグマを上書きします。
#pragma error_messages (on, tag… tag)
on オプションは、先行する #pragma error_messages オプション (off オプションなど) をその時点で無効にして、-erroff オプションも無効にします。
#pragma error_messages (off, tag… tag)
off オプションは、コンパイラプログラムが指定トークンから始まる特定のメッセージを発行することを禁止します。この特定のエラーメッセージに対するプラグマの指定は、別の #pragma error_messages によって無効にされるか、コンパイルが終了するまで有効です。
#pragma error_messages (default, tag… tag)
default オプションは、指定タグについて、先行する #pragma error_messages 指令を無効にします。
#pragma fini (identifier[,identifier...]) |
fini を使用すると、identifier を「終了関数」にします。この関数は void 型で、引数を持ちません。この関数は、プログラム制御によってプログラムが終了する時、または関数内の共有オブジェクトがメモリーから削除されるときに呼び出されます。初期設定関数と同様に、終了関数はリンカーが処理した順序で実行されます。
ソースファイル内で #pragma fini で指定された関数は、そのファイルの中にある静的デストラクタのあとに実行されます。identifier は、この #pragma で指定する前に宣言しておく必要があります。
このような関数は #pragma fini 指令の中に登場するたびに、1 回呼び出されます。
hdrstop プラグマをソースファイルヘッダーに埋め込むと、活性文字列の終わりが指示されます。たとえば次のファイルがあるとします。
example% cat a.cc #include "a.h" #include "b.h" #include "c.h" #include <stdio.h> #include "d.h" . . . example% cat b.cc #include "a.h" #include "b.h" #include "c.h" |
活性文字列は c.h で終わるので、各ファイルの c.h の後に #pragma hdrstop を挿入します。
#pragma hdrstop を挿入できる場所は、CC コマンドで指定したソースファイルの活性文字列の終わりだけです。#pragma hdrstop をインクルードファイル内に指定しないでください。
「A.2.162 -xpch=v」および 「A.2.163 -xpchstop=file」 を参照してください。
#pragma ident string |
ident を使用すると、実行可能ファイルの .comment 部に、string に指定した文字列を記述できます。
#pragma init(identifier[,identifier...]) |
init を使用すると、identifier (識別子) を「初期設定関数」にします。この関数は void 型で、引数を持ちません。この関数は、実行開始時にプログラムのメモリーイメージを構築する時に呼び出されます。共有オブジェクトの初期設定子の場合、共有オブジェクトをメモリーに入れるとき、つまりプログラムの起動時または dlopen() のような動的ロード時のいずれかに実行されます。初期設定関数の呼び出し順序は、静的と動的のどちらの場合でもリンカーが処理した順序になります。
ソースファイル内で #pragma init で指定された関数は、そのファイルの中にある静的コンストラクタのあとに実行されます。identifier は、この #pragma で指定する前に宣言しておく必要があります。
このような関数は #pragma init 指令の中に登場するたびに、1 回呼び出されます。
#pragma must_have_frame(funcname [,funcname]) |
このプラグマは、(System V ABI で定義されているとおり) 完全なスタックフレームを必ず持つように、指定した関数リストをコンパイルすることを要求します。このプラグマで関数を列挙する前に、関数のプロトタイプを宣言する必要があります。
extern void foo(int); extern void bar(int); #pragma must_have_frame(foo, bar) |
このプラグマを使用できるのは、指定した関数のプロトタイプの宣言後のみに限定されます。プラグマは関数の最後より先に記述する必要があります
void foo(int) { . #pragma must_have_frame(foo) . return; } |
「B.1.1 プラグマの引数としての多重定義関数」を参照してください。
#pragma no_side_effect(name[,name...]) |
no_side_effect は、関数によって持続性を持つ状態が変更されないことを通知するためのものです。このプラグマは、指定された関数がどのような副作用も起こさないことをコンパイラに宣言します。すなわち、これらの関数は、渡された引数だけに依存する値を返します。さらに、これらの関数と、そこから呼び出される関数は、次の処理も行なってはいけません。
呼び出し時点で呼び出し側が認識できるプログラム状態の一部に、読み出しまたは書き込みのためにアクセスすることはありません。
入出力を実行しません。
呼び出し時点で認識できるプログラム状態のどの部分も変更しません。
コンパイラは、この情報を最適化に使用します。
関数に副作用があると、この関数を呼び出すプログラムの実行結果は未定義になります。
name 引数で、現在の翻訳単位に含まれている関数の名前を指定します。プラグマは関数と同じスコープ内になければならず、また、関数宣言後に位置していなければいけません。プラグマは、関数定義の前に位置していなければいけません。
プラグマがその引数として多重定義関数を処理する方法の詳細は、「B.1.1 プラグマの引数としての多重定義関数」を参照してください。
#pragma opt level (funcname[, funcname]) |
funcname には、現在の翻訳単位内で定義されている関数の名前を指定します。level の値は、指定した関数に対する最適化レベルです。0、1、2、3、4、5 いずれかの最適化レベルを割り当てることができます。level を 0 に設定すると、最適化を無効にできます。関数は、プラグマの前にプロトタイプまたは空のパラメータリストで宣言する必要があります。プラグマは、最適化する関数の定義を処理する必要があります。
プラグマ内に指定される関数の最適化レベルは、-xmaxopt の値に下げられます。-xmaxopt=off の場合、プラグマは無視されます。
プラグマがその引数として多重定義関数を処理する方法の詳細は、「B.1.1 プラグマの引数としての多重定義関数」を参照してください。
#pragma pack([n]) |
pack は、構造体メンバーの配置制御に使用します。
n を指定する場合は、0 または 2 の累乗にする必要があります。0 以外の値を指定すると、コンパイラは n バイトの境界整列と、データ型に対するプラットフォームの自然境界のどちらか小さい方を使用します。たとえば次の指令は、自然境界整列が 4 バイトまたは 8 バイト境界である場合でも、指令のあと (および後続の pack 指令の前) に定義されているすべての構造体のメンバーを 2 バイト境界を超えないように揃えます。
#pragma pack(2) |
n が 0 であるか省略された場合、メンバー整列は自然境界整列の値に戻ります。
n の値がプラットフォームのもっとも厳密な境界整列と同じかそれ以上の場合には、自然境界整列になります。次の表に、各プラットフォームのもっとも厳密な境界整列を示します。
表 B–1 プラットフォームのもっとも厳密な境界整列
プラットフォーム |
もっとも厳密な境界整列 |
---|---|
x86 |
4 |
SPARC 一般、V8、V8a、V8plus、V8plusa、V8plusb |
8 |
SPARC V9、V9a、V9b |
16 |
pack 指令は、次の pack 指令までに存在するすべての構造体定義に適用されます。別々の翻訳単位にある同じ構造体に対して異なる境界整列が指定されると、プログラムは予測できない状態で異常終了する場合があります。特に、コンパイル済みライブラリのインタフェースを定義するヘッダーをインクルードする場合は、その前に pack を使用しないでください。プログラムコード内では、pack 指令は境界整列を指定する構造体の直前に置き、#pragma pack() は構造体の直後に置くことをお勧めします。
SPARC プラットフォーム上で #pragma pack を使用して、型のデフォルトの境界整列よりも密に配置するには、アプリケーションのコンパイルとリンクの両方で -misalign オプションを指定する必要があります。次の表に、整数データ型のメモリーサイズとデフォルトの境界整列を示します。
表 B–2 メモリーサイズとデフォルトの境界整列 (単位はバイト数)
種類 |
SPARC V8 サイズ、境界整列 |
SPARC V9 サイズ、境界整列 |
x86 サイズ、境界整列 |
---|---|---|---|
bool |
1, 1 |
1, 1 |
1, 1 |
char |
1, 1 |
1, 1 |
1, 1 |
short |
2, 2 |
2, 2 |
2, 2 |
wchar_t |
4, 4 |
4, 4 |
4, 4 |
int |
4, 4 |
4, 4 |
4, 4 |
long |
4, 4 |
8, 8 |
4, 4 |
float |
4, 4 |
4, 4 |
4, 4 |
double |
8, 8 |
8, 8 |
8, 4 |
long double |
16, 8 |
16, 16 |
12, 4 |
データへのポインタ |
4, 4 |
8, 8 |
4, 4 |
関数へのポインタ |
4, 4 |
8, 8 |
4, 4 |
メンバーデータへのポインタ |
4, 4 |
8, 8 |
4, 4 |
メンバー関数へのポインタ |
8, 4 |
16, 8 |
8, 4 |
#pragms rarely_called(funcname[, funcname]) |
このプラグマは、指定の関数がほとんど呼び出されないことをコンパイラに示唆します。このヒントにより、コンパイラは、プロファイル収集段階に負担をかけることなく、ルーチンの呼び出し元でプロファイルフィードバック方式の最適化を行うことができます。このプラグマはヒントの提示ですので、コンパイラは、このプラグマに基づく最適化を行わないこともあります。
#pragma rarely_called プリプロセッサ指令を使用できるのは、指定の関数のプロトタイプが宣言されたあとだけです。次は、#pragma rarely_called の例です。
extern void error (char *message); #pragma rarely_called(error) |
プラグマがその引数として多重定義関数を処理する方法の詳細は、「B.1.1 プラグマの引数としての多重定義関数」を参照してください。
#pragma returns_new_memory(name[,name...]) |
このプラグマは、指定した関数が新しく割り当てられたメモリーのアドレスを返し、そのポインタがほかのポインタの別名として使用されないことをコンパイラに宣言します。この情報により、オプティマイザはポインタ値をより正確に追跡し、メモリー位置を明確化することができます。この結果、スケジューリングとパイプライン化が改善されます。
このプラグマの宣言が実際には誤っている場合は、該当する関数を呼び出したプログラムの実行結果は保証されません。
name 引数で、現在の翻訳単位に含まれている関数の名前を指定します。プラグマは関数と同じスコープ内になければならず、また、関数宣言後に位置していなければいけません。プラグマは、関数定義の前に位置していなければいけません。
プラグマがその引数として多重定義関数を処理する方法の詳細は、「B.1.1 プラグマの引数としての多重定義関数」を参照してください。
#pragma unknown_control_flow(name[,name...]) |
unknown_control_flow を使用すると、手続き呼び出しの通常の制御フロー属性に違反するルーチンの名前のリストを指定できます。たとえば、setjmp() の直後の文は、ほかのどんなルーチンを呼び出してもそこから返ってくることができます。これは、longjmp() を呼び出すことによって行います。
このようなルーチンを使用すると標準のフローグラフ解析ができないため、呼び出す側のルーチンを最適化すると安全性が確保できません。このような場合に #pragma unknown_control_flow を使用すると安全な最適化が行えます。
関数名が多重定義されている場合、最後に宣言された関数が選ばれます。
#pragma weak name1 [= name2] |
weak を使用すると、弱い (weak) 大域シンボルを定義できます。このプラグマは主にソースファイルの中でライブラリを構築するために使用されます。リンカーは弱いシンボルを認識できなくてもエラーメッセージを出しません。
weak プラグマは、次の 2 つの書式でシンボルを指定できます。
文字列書式。文字列は、C++ の変数または関数の符号化された名前でなければいけません。無効な符号化名が指定された場合、その名前を参照したときの動作は予測できません。無効な符号化名を参照した場合、バックエンドがエラーを生成するかどうかは不明です。エラーを生成するかどうかに関わらず、無効な符号化名を参照したときのバックエンドの動作は予測できません。
識別子書式。識別子は、コンパイル単位内であらかじめ宣言された C++ の関数のあいまいでない識別子でなければいけません。識別子書式は変数には使用できません。無効な識別子への参照を検出した場合、フロントエンド (ccfe) はエラーメッセージを生成します。
#pragma weak name という書式の指令は、name を弱い (weak) シンボルに定義します。name のシンボル定義が見つからなくても、リンカーはエラーメッセージを生成しません。また、弱いシンボルの定義を複数見つけた場合でも、リンカーはエラーメッセージを生成しません。リンカーは単に最初に検出した定義を使用します。
プラグマ name の強い定義が存在しない場合、リンカーはシンボルの値を 0 にします。
次の指令は、ping を弱いシンボルに定義しています。ping という名前のシンボルの定義が見つからない場合でも、リンカーはエラーメッセージを生成しません。
#pragma weak ping |
#pragma weak name1 = name2 という書式の指令は、シンボル name1 を name2 への弱い参照として定義します。name1 がどこにも定義されていない場合、name1 の値は name2 の値になります。name1 が別の場所で定義されている場合、リンカーはその定義を使用し、name2 への弱い参照は無視します。次の指令では、bar がプログラムのどこかで定義されている場合、リンカーはすべての参照先を bar に設定します。そうでない場合、リンカーは bar への参照を foo にリンクします。
#pragma weak bar = foo |
識別子書式では、name2 は現在のコンパイル単位内で宣言および定義しなければいけません。次に例を示します。
extern void bar(int) {...} extern void _bar(int); #pragma weak _bar=bar |
文字列書式を使用する場合、シンボルはあらかじめ宣言されている必要はありません。次の例において、_bar と bar の両方が extern "C" である場合、その関数はあらかじめ宣言されている必要はありません。しかし、bar は同じオブジェクト内で定義されている必要があります。
extern "C" void bar(int) {...} #pragma weak "_bar" = "bar" |
識別子書式を使用するとき、プラグマのあるスコープ中には指定した名前を持つ関数は、1 つしか存在してはいけません。多重定義関数に識別子書式の #pragma weak を使おうとすると、エラーになります。次に例を示します。
int bar(int); float bar(float); #pragma weak bar // error, ambiguous function name |
このエラーを回避するには、文字列書式を使用します。例を次に示します。
int bar(int); float bar(float); #pragma weak "__1cDbar6Fi_i_" // make float bar(int) weak |
詳細は、Solaris の『リンカーとライブラリ』を参照してください。