この章では、C コンパイラオプションについてアルファベット順に説明します。機能別のオプションは、Appendix A, 機能別コンパイラオプションを参照してください。たとえば、Table A–1 には、最適化とパフォーマンスのすべてのオプションがまとめられています。
C コンパイラは、デフォルトでは 2011 ISO/IEC C 規格の構文の一部を認識します。サポートされる機能については、Appendix C, C11 の機能で詳しく説明します。コンパイラを以前のバージョンの ISO/IEC C 規格に制限する場合は、-std コマンドを使用します。
% cc [options] filenames [libraries]...
ここでは:
options は、Table A–14 で説明している各種のオプションで、複数指定可能です。
filename; は、実行可能プログラムの作成に使用するファイル名で、複数指定可能です。
C コンパイラは filename;で指定されたファイルリストに含まれている C ソースファイルとオブジェクトファイルのリストを受け取ります。生成された実行可能コードは、-o オプションを使用した場合を除いて a.out に出力されます。-o オプションを使用した場合には、コードは -o オプションで指定したファイルに出力されます。
C コンパイラを使用すると、次のファイルのどのような組み合わせに対しても、コンパイルとリンクを行うことができます。
接尾辞 .c の C ソースファイル
接尾辞 .il のインラインテンプレートファイル (.c ファイルで指定される場合のみ)
接尾辞 .i の前処理済みソースファイル
接尾辞 .o のオブジェクトコードファイル
接尾辞 .s のアセンブラソースファイル
リンク後、C コンパイラは実行可能コードの形式になったリンク済みファイルを、a.out ファイルまたは -o オプションで指定したファイルに出力します。コンパイラが .i または .c の各入力ファイルに対応するオブジェクトコードを生成する場合は、現在の作業ディレクトリにオブジェクト (.o) ファイルを作成します。
ライブラリは複数の標準ライブラリやユーザー提供のライブラリです。ライブラ リには関数、マクロ、そして定数の定義が含まれます。
オプションライブラリの検索に使用されるデフォルトのディレクトリを変更する場合は、-YP,dir を使用します。dir は、コロン区切りのパスリストです。デフォルトのライブラリ検索順序は、-### または -xdryrun オプションを使用し、ld 呼び出しの -Y オプションを検査することで、確認できます。
cc は getopt を使用してコマンド行オプションの構文を解析します。オプションは単一文字、または後ろに引数を 1 つとる単一文字によって指定します。getopt(3c) のマニュアルページを参照してください。
このセクションでは、cc オプションについてアルファベット順に説明します。これらの説明は cc(1) のマニュアルページでも見ることができます。1 行に要約した説明が必要な場合は、cc -flags オプションを使用してください。
特定のプラットフォームに固有と表記されたオプションを別のプラットフォームで使用してもエラーは起きません。単に無視されます。
冗長モードを有効にし、コマンドオプションがどのように展開されるかを示します。要素が呼び出されるごとにその要素を表示します。
呼び出された各コンポーネントが表示されますが、実行はされません。また、コマンドオプションの展開内容を表示します。
#assert 前処理指令に似せて、指定の tokens を使用し name を述語として関連付けます。事前表明 (preassertion) は次のとおりです。
system(unix)
machine(sparc) (SPARC)
machine(i386) (x86)
cpu(sparc) (SPARC)
cpu(i386) (x86)
これらの事前表明は -pedantic モードでは無効です。
-A のあとにハイフン (-) だけが続く場合は、事前定義のマクロ (__ から始まるもの以外) および事前定義の表明はすべて無視されます。
-std=c89 と同等です。
リンク時に結合するライブラリをstatic (静的) (指定するとライブラリが非共有ライブラリであることを示す) と dynamic (動的) (指定すると共有ライブラリであることを示す) のどちらにするかを指定します。
–Bdynamic を指定すると、-lx オプションが指定されていれば、リンカーは libx.so というファイルを探し、次に libx.a というファイルを探します。
-Bstatic を指定すると、リンカーは libx.a というファイルだけを探します。このオプションは、コマンド行中で何度も指定して、切り替えることができます。このオプションと引数は ld(1) に渡されます。
このオプションと引数はリンカーに渡されます。
C プリプロセッサが、前処理指令の行にあるコメント以外のコメントを削除しないようにします。
C コンパイラ ld(1) によるリンクを行わず、ソースファイルごとに .o ファイルを作成します。-o オプションを使用すると、1 つのオブジェクトファイルを明示的に指定することができます。コンパイラが .i または .c の各入力ファイルに対応するオブジェクトコードを生成する場合は、現在の作業ディレクトリにオブジェクト (.o) ファイルを作成します。リンクを行わないと、オブジェクトファイルの削除も行われません。
#define 前処理マクロが指令によって定義されるのと同様に、オプションの引数を使用してマクロを定義します。=expansion が指定されていない場合は、コンパイラは 1 であると仮定します。
コンパイラの定義済みマクロのリストについては、cc(1) のマニュアルページを参照してください。
-dy はリンクエディタに動的なリンクを指定します (デフォルト)。
-dn はリンクエディタに静的なリンクを指定します。
このオプションとその引数は ld(1) に渡されます。
(SPARC) 廃止。このオプションは使わないでください。代わりに -xmemalign=8s を使用してください。詳細は、-xmemalign=abを参照してください。廃止オプションに、廃止のオプションの全一覧をまとめています。x86 プラットフォームでは、このオプションはメッセージを表示せずに無視されます。
プリプロセッサのみでソースファイルを処理し、出力を stdout に送ります。プリプロセッサはコンパイラ内部に直接組み込まれます。/usr/ccs/lib/cpp が直接呼び出される -Xs モードの場合は除きます。プリプロセッサの行番号付け情報も含みます。-P オプションの説明も参照してください。
このオプションは、エラーメッセージの最初に “error:” という接頭辞を追加して、警告メッセージと区別しやすくする場合に使用します。接頭辞は、-errwarn によってエラーに変換された警告にも追加されます。
|
このオプションを指定しない場合は、-errfmt=no%errorに設定されます。–errfmt を指定したけれども値を指定しない場合、コンパイラはそれを -errfmt=error に指定します。
ヘッダーファイルからの警告を、次の表のフラグによって示されるヘッダーファイルのグループに限定します。
|
このコマンドは、C コンパイラの警告メッセージを無効にし、エラーメッセージには影響しません。このオプションは、-errwarn によってゼロ以外の終了ステータスを発生させるように指定されているかどうかにかかわらず、すべての警告メッセージに適用されます。
t には、次の 1 つまたは複数の項目をコンマで区切って指定します。tag、no%tag、%all、%none。指定順序によって実行内容が異なります。たとえば、「%all,no%tag」と指定すると、tag 以外のすべての警告メッセージを抑制します。次の表は、-erroff の値を示しています。
|
デフォルトは -erroff=%none です。-erroff と指定することは、-erroff=%all を指定することと同義です。
-erroff オプションで無効にできるのは、C コンパイラのフロントエンドで -errtags オプションを指定したときにタグを表示する警告メッセージだけです。無効にするエラーメッセージをさらに詳細に設定することができます。error_messagesを参照してください。
このオプションは、コンパイラで型の不一致が検出されたときに生成されるエラーメッセージの詳細さを設定する場合に使用します。大きな集合体が関係する型の不一致がコンパイラで検出される場合にこのオプションを使用すると特に便利です。
i は、次の表に示す値のいずれかです。
|
-errshort を指定しない場合は、コンパイラでは -errshort=full が指定されます。-errshort を指定したけれども値を指定しない場合、コンパイラはこのオプションを -errshort=tags に設定します。
このオプションは累積されません。コマンド行で指定された最後の値を受け入れます。
C コンパイラのフロントエンドで出力される警告メッセージのうち、-erroff オプションで無効にできるか、または -errwarn オプションで致命的なエラーにできるメッセージのメッセージタグを表示します。C コンパイラのドライバおよび C のコンパイルシステムのほかのコンポーネントから出力されるメッセージにはエラータグが含まれないため、-erroff で無効にしたり、-errwarn で致命的なエラーに変換したりすることはできません。
a には yes または no のいずれかを指定します。デフォルトは -errtags=no です。-errtags だけを指定すると、-errtags=yes を指定するのと同じことになります。
指定した警告メッセージが生成された場合に、失敗ステータスで C コンパイラを終了する場合は、-errwarn オプションを使用します。
t には、次の 1 つまたは複数の項目をコンマで区切って指定します。tag、no%tag、%all、%none。このとき、順序が重要になります。たとえば、%all,no%tag と指定すると、tag 以外のすべての警告メッセージが生成された場合に、致命的ステータスで cc を終了します。
C コンパイラで生成される警告メッセージは、コンパイラのエラーチェックの改善や機能追加に応じて、リリースごとに変更されます。-errwarn=%all を指定してエラーなしでコンパイルされるコードが、コンパイラの次のリリースではエラーなしでコンパイルされない可能性があります。
-errwarn オプションを使用して、障害ステータスで C コンパイラを終了するように指定できるのは、C コンパイラのフロントエンドで -errtags オプションを指定したときにタグを表示する警告メッセージだけです。
-errwarn の値を次の表に示します。
|
デフォルトは -errwarn=%none です。-errwarn のみを指定することは、-errwarn=%all と同義です。
このオプションは、 実行可能ファイルをチューニングして実行時パフォーマンスを最大化するための出発点として効果的に使用できるマクロです。-fast オプションマクロは、コンパイラのあるリリースから次の変更される可能性があり、ターゲットプラットフォーム固有のオプションに展開されます。-# オプションまたは -xdryrun を使用して -fast の展開を調べ、-fast の該当するオプションを使用して実行可能ファイルのチューニングを行なってください。
-fast の展開には、コンパイラが最適化された数学ルーチンのライブラリを使用できるようにする -xlibmopt オプションが含まれます。詳細は、-xlibmoptを参照してください。
-fast オプションは、errno の値に影響します。詳細は、errno の値の保持を参照してください。
-fast を指定してコンパイルしたモジュールは、-fast を指定してリンクする必要があります。コンパイル時とリンク時のオプションに、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。
-fast オプションは、特にコンパイルするマシンとは異なるターゲットで実行するプログラムでは使用できません。そのような場合は、-fast のあとに適切な -xtarget オプションを指定します。例:
cc -fast -xtarget=generic ...
SUID によって規定された例外処理に依存する C モジュールに対しては、-fast のあとに -xnolibmil を指定します。
% cc -fast -xnolibmil
-xlibmil を使用すると、例外発生時でも errno が設定されず、また、matherr(3m) が呼び出されません。
-fast オプションは、厳密な IEEE 754 規格準拠を必要とするプログラムには適していません。
次に、-fast により指定されるオプションをプラットフォームごとに示します。
|
これらのオプションで実行される最適化は、ISO C および IEEE 規格で定義されたプログラムの動作を変えることがあります。詳細については、各オプションの説明を参照してください。
-fast フラグは、コマンド行でのマクロ展開のように動作します。したがって、最適化レベルとコード生成の内容を -fast のあとに指定したオプションで指定した場合は、-fast での指定は無視されます。-fast -xO4 の組み合わせでコンパイルすることは、-xO2 -xO4 の組み合わせでコンパイルすることと同じです。後ろの指定が優先されます。
x86 では、-fast オプションに -xregs=frameptr が含まれます。特に C、Fortran、および C++ の混合ソースコードをコンパイルする場合は、その詳細について、このオプションの説明を参照してください。
このオプションは、IEEE 規格例外処理に依存するプログラムには使用しないでください。数値結果が異なったり、プログラムが途中で終了したり、予想外の SIGFPE シグナルが発生する可能性があります。
実行中のプラットフォームで —fast の実際の展開を確認するには、次のコマンドを使用します。
% cc -fast -xdryrun |& grep ###
|
古い C および C++ オブジェクト (このリリースより前の Solaris Studio コンパイラで作成されたオブジェクト) は、そのオブジェクトの動作変更なしに、新しい C および C++ オブジェクトとリンクできます。規格に適合した動作を実現するには、最新のコンパイラを使って古いコードをコンパイルする必要があります。
typeof(int) i;/* declares variable "i" to be type int*/
typeof(i+10) j;/* declares variable "j" to be type int,
the type of the expression */
i = sizeof(typeof(j)); /* sizeof returns the size of
the type associated with variable "j" */
int a[10];
typeof(a) b;/* declares variable "b" to be array of
size 10 */
typeof 演算子は、任意の型の引数を使用できるマクロ定義で特に役立つ可能性があります。例:
#define SWAP(a,b)
{ typeof(a) temp; temp = a; a = b; b = temp; }
(x86) このオプションは、浮動小数点式の評価方法の制御に使用します。
|
-flteval が指定されない場合は、-flteval=any に設定されます。-flteval を指定したけれども値を指定しない場合、コンパイラはそれを -flteval=2 に設定します。
-flteval=2 は -xarch=sse、 pentium_pro、ssea、または pentium_proa と一緒でのみ使用できます。-flteval=2 は、-fprecision または -nofstore オプションとの組み合わせでも互換性がありません。
浮動小数点評価における精度も参照してください。
浮動小数点の積和演算 (FMA) 命令の自動生成を有効にします。–fma=none を指定すると、これらの命令の生成を無効にします。–fma=fused を指定すると、コンパイラは浮動小数点の積和演算 (FMA) 命令を使用して、コードのパフォーマンスを改善する機会を検出しようとします。
デフォルトは –fma=none です。
積和演算命令を生成するための最低限のアーキテクチャーの要件は、SPARC では –xarch=sparcfmaf、x86 では -xarch=avx2 です。積和演算 (FMA) 命令をサポートしていないプラットフォームでプログラムが実行されないようにするため、コンパイラは積和演算 (FMA) 命令を生成する場合、バイナリプログラムにマーク付けをします。最低限のアーキテクチャーが使用されていない場合、-fma=fused は無効になります。
積和演算 (FMA) 命令により、積と和の間で中間の丸め手順が排除されます。その結果、–fma=fused を指定してコンパイルしたプログラムは、精度は減少ではなく増加する傾向にありますが、異なる結果になることがあります。
このオプションは、-fns および -ftrap=common 用のマクロです。
SPARC プラットフォームでは、このオプションは標準でない浮動小数点モードを有効にします。
x86 プラットフォームの場合、このオプションは SSE flush-to-zero モードを選択し、使用可能な場合には denormals-are-zero モードを選択します。これにより、非正規数の結果がゼロに切り捨てられ、使用可能な場合には、非正規化数のオペランドもゼロとして扱われます。このオプションは、SSE や SSE2 命令セットを利用しない従来の x86 浮動小数点演算には影響しません。
デフォルトは -fns=no、標準の浮動小数点モードです。-fns は -fns=yes と同じです。
オプションの =yes または =no を使用すると、-fast のように、-fns を含むほかのマクロフラグに続く -fns フラグを切り替えることができます。
一部の SPARC システムでは、非標準の浮動小数点モードは「段階的アンダーフロー」を無効にします。つまり、小さな結果は、非正規数にはならず、ゼロに切り捨てられます。また、非正規オペランドはメッセージなしにゼロに変更されます。このような SPARC システムでは、ハードウェアの段階的アンダーフローや非正規数がサポートされておらず、このオプションを使用するとプログラムのパフォーマンスを著しく改善することができます。
非標準モードを有効にすると、浮動小数点演算は IEEE 754 規格に準拠しない結果を生成する場合があります。詳細は、『数値計算ガイド』を参照してください。
SPARC システムでは、このオプションはメインプログラムのコンパイル時に使用される場合にのみ有効です。
-xopenmp=parallel と同じです。
-KPIC と同義です。
-Kpic と同義です。
(x86) -fprecision={single, double, extended}
浮動小数点制御ワードの丸め精度モードのビットを、単精度 (24 ビット)、倍精度 (53 ビット) または拡張精度 (64 ビット) に設定します。デフォルトの浮動小数点丸め精度モードは拡張モードです。
x86 では、浮動小数点丸め精度モードの設定は精度に対してのみ影響します。指数の有効範囲に対しては影響しません。
このオプションは、x86 システムでメインプログラムのコンパイル時に使用する場合にのみ有効で、64 ビット (-m64) または SSE2 対応 (-xarch=sse2) プロセッサでコンパイルする場合は無視されます。SPARC システムでも無視されます。
プログラム初期化中に、実行時に確立される IEEE 754 丸めモードを設定します。
r は、nearest、 tozero、negative、positive のいずれかです。
デフォルトは、-fround=nearest です。
ieee_flags サブルーチンと同義です。
r を tozero、negative、positive のいずれかにすると、プログラムが実行を開始するときに、丸め方向モードがそれぞれ、ゼロの方向に丸める、負の無限の方向に丸める、正の無限の方向に丸めるに設定されます。r が nearest のとき、あるいは -fround フラグを使用しないとき、丸め方向モードは初期値から変更されません (デフォルトは nearest)。
このオプションは、メインプログラムをコンパイルするときにだけ有効です。
オプティマイザが浮動小数点演算に関する前提事項を単純化することを許可します。
デフォルトは -fsimple=0 です。-fsimple は -fsimple=1 と同義です。
n を指定する場合、0、1、2 のいずれかにしなければいけません。
|
-fsimple=2 を指定しても、そうでない場合は何も生成しないプログラムで、オプティマイザが浮動小数点例外を発生させることは許可されません。
最適化が精度に与える影響の詳細は、『Techniques for Optimizing Applications: High Performance Computing』(Rajat Garg と Ilya Sharapov 著) をお読みください。
(-Xt および -Xs モードのみ) デフォルトでは、-Xs と -Xt は float 式を double に拡張して倍精度で評価することで、これらの式に関する K&R C の規則に従います。-fsingle は、-Xs または -Xt を指定して、コンパイラに浮動小数点式を単精度として評価させる場合に使用します。
(x86) 浮動小数点式または関数が、ある変数に代入されるか、より小さい型の浮動小数点にキャストされる場合に、コンパイラがその値をレジスタに残さないで、代入値の左側に表記される型に変換するようにします。丸めや切り上げによって、結果はレジスタの値から生成されるものと異なる可能性があります。これは、デフォルトのモードです。
このオプションを無効にするには、-nofstore フラグを使用します。
SIGFPE ハンドラを組み込まずに、起動時に有効にする IEEE トラップモードの設定のみ行います。トラップの設定と SIGFPE ハンドラの組み込みを同時に行うには、ieee_handler(3M) か fex_set_handling(3M) を使用します。複数の値を指定すると、それらの値は左から右に処理されます。
t には、次の表に示す値のいずれかにできます。
|
例に示すように、no% 接頭辞は、%all および common 値の意味を変更するためにのみ使用され、これらの値のいずれかと一緒に使用される必要があります。no% 接頭辞は、特定のトラップを明示的に無効にするものではありません。
-ftrap を指定しない場合、コンパイラは -ftrap=%none とみなします。
例: –ftrap=%all,no%inexact は、inexact を除くすべてのトラップを設定します。
-ftrap=t 付きで 1 つのルーチンを コンパイルする場合は、予期しない結果を避けるために、プログラムのすべてのルーチンを同じオプションでコンパイルしてください。
-ftrap=inexact のトラップは慎重に使用してください。-ftrap=inexact では、浮動小数点の値が正確でないとトラップが発生します。たとえば、次の文ではこの条件が発生します。
x = 1.0 / 3.0;
このオプションは、メインプログラムをコンパイルするときにだけ有効です。このオプションを使用する際には注意してください。IEEE トラップを有効にするには、-ftrap=common を使用します。
動的にリンクされた実行可能ファイルではなく、共有オブジェクトを生成します。このオプションは ld(1) に渡され、-dn オプションと一緒に使用できません。
-G オプションを使用すると、コンパイラはデフォルトの -l オプションを ld に渡しません。共有ライブラリを別の共有ライブラリに依存させる場合は、必要な -l オプションをコマンド行に渡す必要があります。
コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションと -G オプションを組み合わせて共有ライブラリを作成した場合は、生成された共有オブジェクトとのリンクでも、必ず同じオプションを指定してください。
共有オブジェクトを作成するときは、-m64 付きでコンパイルされるすべての 64 ビット SPARC オブジェクトファイルも、-xcode[=v]で説明するように、明示的な -xcode[=v] 値付きでコンパイルする必要があります。
dbx(1) とパフォーマンスアナライザ analyzer(1) によるデバッグのために、追加のシンボルテーブル情報を生成します。
-xO3 以下の最適化レベルで -g を指定すると、ほとんど完全な最適化と可能なかぎりのシンボル情報を取得することができます。末尾呼び出しの最適化とバックエンドのインライン化は無効です。
-xO4 以下の最適化レベルで -g を指定すると、完全な最適化と可能なかぎりのシンボル情報が得られます。
-g オプションでコンパイルすると、パフォーマンスアナライザの機能をフルに利用できます。 一部のパフォーマンス分析機能は -g を必要としませんが、注釈付きのソースコード、一部の関数レベルの情報、およびコンパイラの注釈メッセージを確認するには、-g でコンパイルする必要があります。詳細は、analyzer(1) のマニュアルページおよび『プログラムのパフォーマンス解析』のマニュアルを参照してください。
-g オプションで生成される注釈メッセージは、プログラムのコンパイル時にコンパイラが実行した最適化と変換について説明します。メッセージを表示するには、er_src(1) コマンドを使用します。これらのメッセージはソースコードでインタリーブされます。
-g は、さまざまなよりプリミティブなオプションに展開されるマクロとして実装されます。展開の詳細については、-xdebuginfo を参照してください。
標準のデバッグ情報を生成します。
デバッグ情報は生成されません。これはデフォルト値です。
事後デバッグの際に重要と思われるファイル、行番号、および簡単なパラメータ情報を生成します。
-g と同じです。
追加のデバッグ情報 (現在はマクロの定義情報のみで構成されます) を生成します。この追加情報により、-g のみを使用したコンパイルと比較して、結果の .o および実行可能ファイルのデバッグ情報のサイズが増える可能性があります。
デバッグの詳細は、『dbx コマンドによるデバッグ』を参照してください。
現在のコンパイルでインクルードされたファイルのパス名を 1 行に 1 つずつ標準エラーに出力します。表示は、どのファイルがほかのファイルにインクルードされるかを示すためにインデントされます。
次の例では、プログラム sample.c はファイル stdio.h と math.h をインクルードします。math.h はファイル floatingpoint.h をインクルードし、これ自体が sys/ieeefp.h を使用する関数をインクルードします。
% cc -H sample.c
/usr/include/stdio.h
/usr/include/math.h
/usr/include/floatingpoint.h
/usr/include/sys/ieeefp.h
共有動的ライブラリに、異なったバージョンのライブラリを持つように名前を割り当てます。name は、-o オプションで指定されるものと同じファイル名にしてください。-h と name の間の空白は任意です。
リンカーは指定された name; をライブラリに割り当て、この名前をライブラリのイントリンシック名としてライブラリファイルに記録します。-hname; オプションがない場合、イントリンシック名はライブラリファイルに記録されません。
実行時リンカーはライブラリを実行可能ファイルにロードするとき、組み込み名をライブラリファイルから実行可能ファイルが必要とする共有ライブラリファイルのリストにコピーします。実行可能ファイルはこのリストを持っています。共有ライブラリの組み込み名が提供されない場合、リンカーは代わりに共有ライブラリファイルのパスをコピーします。
-I dir は、相対ファイル名、つまり、/ (スラッシュ) から始まらないディレクトリパスを持つ #include ファイルを検索するディレクトリのリスト内の /usr/include の前に dir を追加します。
複数の -I オプションが指定された場合は、指定された順序でディレクトリが調べられます。
コンパイラの検索パターンの詳細については、-I- オプションによる検索アルゴリズムの変更を参照してください。
オプションをリンカーへ渡して、LD_LIBRARY_PATH または LD_LIBRARY_PATH_64 の設定を無視します。
このオプションを指定すると、コンパイラは filename を、主要なソースファイルの 1 行目に記述されているかのように #include プリプロセッサ指令として処理します。ソースファイル t.c の考慮:
main()
{
...
}
t.c を cc -include t.h t.c コマンドを使用してコンパイルする場合は、ソースファイルに次の内容が含まれているかのようにコンパイルが進行します。
#include "t.h"
main()
{
...
}
コンパイラが filename を最初に検索するのは、ファイルが明示的にインクルードされる場合のように、main ソースファイルが含まれるディレクトリではなく、現在の作業ディレクトリです。たとえば、次のディレクトリ構造では、同じ名前を持つ 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 オプションを指定する場合は、コマンド行で表示される順にファイルがインクルードされます。
(SPARC) 廃止。このオプションは使わないでください。代わりに -xcode=pic32 を使用してください。
詳細は、-xcode[=v] を参照してください。廃止オプションに、廃止のオプションの全一覧をまとめています。
(SPARC) 廃止。このオプションは使わないでください。代わりに -xcode=pic13 を使用してください。詳細は、-xcode[=v] を参照してください。廃止オプションに、廃止のオプションの全一覧をまとめています。
(x86) 位置独立コードを生成します。このオプションは、共有ライブラリを構築するためにソースファイルをコンパイルするときに使用します。大域データへの各参照は、大域オフセットテーブルにおけるポインタの間接参照として生成されます。各関数呼び出しは、手続きリンケージテーブルを通して PC 相対アドレス指定モードで生成されます。
コンパイル中に作成される一時ファイルを自動的に削除しないで保持します。
ld(1) がライブラリを検索するディレクトリのリストに dir を付け加えます。このオプションとその引数は ld(1) に渡されます。
オブジェクトライブラリlib name.so または libname .a をリンクの対象とします。シンボルは左から右へ解決されるため、コマンドでのライブラリの順序は重要です。
このオプションはソースファイル引数のあとに指定してください。
Oracle Solaris Studio パフォーマンスライブラリとリンクします。
コンパイルされたバイナリオブジェクトのメモリーモデルを指定します。
–m32 を使用すると、32 ビット実行可能ファイルと共有ライブラリが作成されます。–m64 を使用すると、64 ビット実行可能ファイルと共有ライブラリが作成されます。
ILP32 メモリーモデル (32 ビット int、long、ポインタデータ型) は 64 ビット対応ではないすべての Solaris プラットフォームおよび Linux プラットフォームのデフォルトです。LP64 メモリーモデル (64 ビット long、ポインタデータ型) は 64 ビット対応の Linux プラットフォームのデフォルトです。–m64 は LP64 モデル対応のプラットフォームでのみ許可されます。
–m32 を使用してコンパイルされたオブジェクトファイルまたはライブラリを、–m64 を使用してコンパイルされたオブジェクトファイルまたはライブラリにリンクすることはできません。
–m32|–m64 を指定してコンパイルしたモジュールは、–m32 |–m64 を指定してリンクする必要があります。コンパイル時とリンク時のオプションに、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの一覧をまとめています。
x86/x64 プラットフォームで大量の静的データを持つアプリケーションを –m64 を使用してコンパイルするときは、–xmodel=medium も必要になることがあります。一部の Linux プラットフォームは、ミディアムモデルをサポートしていません。
以前のコンパイラリリースでは、–xarch で命令セットを選択すると、メモリーモデル ILP32 または LP64 が使用されていました。Oracle Solaris Studio 12 コンパイラから、このデフォルトは該当しません。ほとんどのプラットフォームでは、–m64 をコマンド行に追加するだけで、64 ビットオブジェクトが作成されます。
Oracle Solaris では、–m32 がデフォルトです。64 ビットプログラムをサポートする Linux システムでは、–m64 –xarch=sse2 がデフォルトです。
–xarch の説明も参照してください。
オブジェクトファイルの .comment セクションから重複している文字列を削除します。-mc フラグを使用すると、mcs -c が起動されます。
(SPARC) 廃止。このオプションは使わないでください。代わりに -xmemalign=1i オプションを使ってください。詳細は、-xmemalign=abを参照してください。廃止オプションに、廃止のオプションの全一覧をまとめています。
(SPARC) 廃止。このオプションは使わないでください。代わりに –xmemalign=2i オプションを使ってください。詳細は、-xmemalign=abを参照してください。廃止オプションに、廃止のオプションの全一覧をまとめています。
-mr は、 .comment セクションからすべての文字を削除します。このフラグを使用すると、mcs -d -a が呼び出されます。
-mr, string はオブジェクトファイルの .comment セクションからすべての文字列を削除して、string を挿入します。string に空白が含まれている場合は二重引用符で囲みます。string がなければ .comment セクションは空になります。このオプションは -d -string として mcs に渡されます。
このオプションを使用して、Oracle Solaris スレッドまたは POSIX スレッド API を使用しているマルチスレッド化コードをコンパイルおよびリンクします。–mt=yes オプションにより、ライブラリが適切な順序でリンクされることが保証されます。
このオプションは -D_REENTRANT をプリプロセッサに渡します。
Oracle Solaris スレッドを使用するには、thread.h ヘッダーファイルをインクルードし、—mt=yes オプション付きでコンパイルします。Oracle Solaris プラットフォームで POSIX スレッドを使用するには、pthread.h ヘッダーファイルをインクルードし、—mt=yes オプション付きでコンパイルします。
Linux プラットフォームでは、POSIX スレッド API のみを使用できます。(libthread は Linux プラットフォームでは使用できません。)したがって、Linux プラットフォームで —mt=yes を使用すると、—lthread の代わりに —lpthread が追加されます。Linux プラットフォームで POSIX スレッドを使用するには、—mt 付きでコンパイルします。
—G を使用してコンパイルする場合は、—mt=yes を指定しても、—lthread と —lpthread のどちらも自動的には含められません。共有ライブラリを構築する場合は、これらのライブラリを明示的にリストする必要があります。
-xopenmp オプションおよび -xautopar オプションには -mt=yes が自動的に含まれます。
–mt=yes を指定してコンパイルを実行し、リンクを個別の手順でリンクする場合は、コンパイル手順と同様にリンク手順でも -mt=yes オプションを使用する必要があります。–mt=yes を使用して 1 つの変換ユニットをコンパイルおよびリンクする場合は、–mt=yes を指定してプログラムのすべてのユニットをコンパイルおよびリンクする必要があります。
-mt=yes は、コンパイラのデフォルトの動作です。この動作が望ましくない場合は、-mt=no でコンパイルします。
オプション —mt は —mt=yes と同じです。
-xnolib と、Oracle Solaris の『Multithreaded Programming Guide』および『リンカーとライブラリガイド』も参照してください。
このオプションは、-xtarget=native と同義です。
(x86) 浮動小数点式または関数が変数に代入されるか、より短い浮動小数点型にキャストされるときに、その式または関数の値を代入の左辺の型に変換しません。代わりに、値をレジスタに残します。-fstoreも参照してください。
デフォルトの最適化レベルの -xO3 を使ってください。 -O マクロは -xO3 に展開されます。
-xO3 最適化レベルがより高い実行時パフォーマンスを生み出します。ただし、あらゆる変数が自動的に volatile と見なされることに依存するプログラムの場合、これは不適切なことがあります。この前提を持つ典型的なプログラムは、独自の同期処理プリミティブを実装するデバイスドライバや古いマルチスレッドアプリケーションです。回避策は、-O ではなく、-xO2 でコンパイルすることです。
デフォルトの a.out ではなく、出力ファイル filename を指定します。コンパイラはソースファイルを上書きしないため、filename を入力ソースファイルと同じにできません。
filename は適切な接尾辞を持つ必要があります。—c とともに使用すると、filename はターゲット .o オブジェクトファイルを指定します。—G とともに使用すると、ターゲット .so ライブラリファイルを指定します。このオプションとその引数はリンカー ld に渡されます。
ソースファイルのプリプロセッサ処理のみを行います。.i 接尾辞の付いたファイルに結果を出力します。-E オプションと異なり、出力ファイルに C のプリプロセッサ行番号付け情報は含まれません。-E オプションも参照してください。
このオプションは廃止されました。代わりに -xpgを使用してください。
非 ANSI 構文に対するエラー/警告に厳密に準拠します。有効な ANSI 標準を指定するために -std フラグを使用できます。-Xc、-Xa、-Xt、-Xs、および -xc99 フラグは、-pedantic フラグとともに指定できません。一緒に指定するとコンパイラによってエラーが発行されます。
-pedantic が指定されていない場合のデフォルトは -pedantic=no です。
-pedantic は -pedantic=yes と同義です。
(x86) レジスタベースの関数の引数のコピーをスタックに保存します。
コマンド行に none を指定した場合、または -preserve_argvalues オプションを指定しない場合、コンパイラは通常どおりに動作します。
simple を指定した場合、最大で 6 つの整数引数が保存されます。
complete を指定した場合、スタックトレース内のすべての関数引数の値は、適切な順序でユーザーに表示されます。
仮引数に割り当てられている関数の有効期間中、値は更新されません。
複数のオプションを渡すには、コンマで区切って指定します。-Qoption でコンポーネントに渡されるオプションは、順序が変更されることがあります。ドライバが認識するオプションは、正しい順序に保持されます。ドライバがすでに認識しているオプションに、-Qoption は使わないでください。
phase は、次のリスト内のいずれかの値にできます。
コンパイラ
コードジェネレータ (SPARC)
プリプロセッサ
cc ドライバ
アセンブラ
内部手続きオプティマイザ
オプティマイザ
リンクエディタ (ld)
mcs — —mc または —mr が指定されたとき、オブジェクトファイルのコメントセクションを操作します。
ポストオプティマイザ
lock_lint のコンパイラ段階
コードジェネレータ (x86)
同等の機能を提供する —Wc, arg も参照してください。—Qoption は、ほかのコンパイラとの互換性のために提供されています。
出力ファイルに識別情報を出力するかどうかを決定します。-Qy がデフォルトです。
-Qy を指定すると、起動した各コンパイラツールの識別情報が出力ファイルの .comment 部分に追加され、mcs でのアクセスが可能になります。これはソフトウェア管理に役立ちます。
-Qn を指定すると、この情報が抑制されます。
コロンで区切られたディレクトリのリストを、ライブラリ検索ディレクトリとして、実行時リンカーに渡します。ディレクトリリストが存在していて null でない場合は、出力オブジェクトファイルに記録され、実行時リンカーに渡されます。
LD_RUN_PATH と -R オプションの両方が指定されたときは、この -R オプションが優先されます。
cc に対して、アセンブリソースファイルを作成するけれども、プログラムをアセンブルまたはリンクしないように指示します。アセンブラ言語出力は、接尾辞が .s の対応するファイルに書き込まれます。
出力されるオブジェクトファイルからシンボリックデバッグのための情報をすべて削除します。このオプションは、-g とともに指定することはできません。
ld(1) に渡します。
-library=sunperf とともに使用すると、-staticlib=sunperf は Sun パフォーマンスライブラリと静的にリンクします。デフォルトの場合、および -library=no%sunperf を指定すると、-library=sunperf は Sun パフォーマンスライブラリと動的にリンクします。
CC との互換性のため、%all および %none も -staticlib で受け入れられる値です (%all は sunperf と同等であり、%none は no%sunperf と同義です)。
value は次のいずれかとして定義します。
受け入れられる C ソース言語は、ISO C90 標準で定義されたものです。
受け入れられる C ソース言語は、ISO C99 標準で定義されたものです。
受け入れられる C ソース言語は、ISO C11 標準で定義されたものです。
最初のデフォルトは c11 であり、ANSI C11 で定義されている C ソース言語を拡張したものを受け入れることを意味します。2 番目のデフォルトはありません。代わりに、値なしで -std を指定すると、エラーが生成されます。
フラグ -Xc、-Xa、-Xt、または -xtransition のいずれかを指定すると、-std の最初のデフォルトは無効になり、コンパイラではデフォルトで -xc99=all,no_lib が指定されます。-Xs を指定すると、最初のデフォルトは無効になり、コンパイラではデフォルトで -xc99=none が指定されます。-xc99 を指定すると、-std の最初のデフォルトは無効になり、コンパイラは -xc99 の指定を受け入れます。
-std フラグを指定した場合、-Xc、-Xa、-Xt、-Xs、および -xc99 フラグは使用できません。一緒に指定するとコンパイラによってエラーが発行されます。
コンパイルとリンクを別々に行う場合は、両方の手順で同じ -std フラグの値を使用する必要があります。
一時ファイルのディレクトリを定義します。
このオプションは、コンパイル中に生成される一時ファイルを格納するディレクトリのパス名を指定します。コンパイラは –temp によって設定された値を、TMPDIR の値より優先します。
-keeptmp
実行時に重大エラーが発生した場合にスタックトレースを発行します。
-traceback オプションを指定すると、プログラムによって特定のシグナルが生成された場合に、実行可能ファイルで stderr へのスタックトレースが発行されて、コアダンプが実行され、終了します。複数のスレッドが 1 つのシグナルを生成すると、スタックトレースは最初のスレッドに対してのみ生成されます。
追跡表示を使用するには、リンク時に -traceback オプションをコンパイラコマンド行に追加します。このオプションはコンパイル時にも使用できますが、実行可能バイナリが生成されない場合無視されます。-traceback を -G とともに使用して共有ライブラリを作成すると、エラーが発生します。
|
このオプションを指定しない場合、デフォルトは -traceback=%none になります。
= 記号を指定せずに、-traceback だけを指定すると、-traceback=common と同義になります。
コアダンプが必要ない場合は、次のように coredumpsize 制限を 0 に設定します。
% limit coredumpsize 0
-traceback オプションは、実行時のパフォーマンスに影響しません。
プリプロセッサシンボル name; の定義を削除します。このオプションは、同じコマンド行で -D で作成されたプリプロセッサシンボル name の初期定義を削除します。コマンド行ドライバでそこに配置されたものも含みます。
-U は、ソースファイルのプリプロセッサ指令に影響しません。コマンド行に複数の -U オプションを配置できます。
コマンド行で -D と -U の両方に同じ name が指定された場合、オプションの配置順に関係なく、name は未定義になります。次の図で、-U は __sun の定義のを削除します。
cc -U__sun text.c
test.c の次の書式のプリプロセッサ文は、__sun の定義が削除されているために有効になりません。
#ifdef(__sun)
定義済みシンボルのリストについては、-Dname[(arg[,arg])][=expansion] を参照してください。
コンパイラの実行時に cc によって各コンポーネントの名前とバージョン番号を出力します。
より厳しい意味検査およびほかの lint に似た検査を行います。たとえば、次のコードは支障なくコンパイルおよび実行されます。
#include <stdio.h>
main(void)
{
printf("Hello World.\n");
}
-v オプションを指定した場合も、コンパイルされます。ただし、コンパイラは次の警告を表示します。
"hello.c", line 5: warning: function has no return statement: main
-v は lint(1) が発する警告をすべて表示するわけではありません。lint を通して前の例を実行することにより、違いを確認できます。
指定されたコンパイラコンポーネント c に、arg を渡します。コンポーネントのリストについては、Table 1–1 を参照してください。
引数は前の引数からコンマでのみ区切る必要があります。すべての -W 引数は、残りのコマンド行引数のあとに渡されます。コンマを引数の一部として含めるには、コンマの直前にエスケープ文字 \ (バックスラッシュ) を使用します。すべての -W arg は、通常のコマンド行引数のあとに渡されます。
たとえば、-Wa,-o,objfile は、-o と objfile をこの順番でアセンブラに渡します。また、-Wl,-I,name; を指定すると、リンク段階で動的リンカー /usr/lib/ld.so.1 のデフォルト名がオーバーライドされます。
引数がツールに渡される順序は、ほかに指定されるコマンド行オプションとの関係で、今後のコンパイラリリースで変更される可能性があります。
c に使用できる値の一覧を次の表に示します
|
-Wd を使用して cc のオプションを c コンパイラに渡すことはできません。
このオプションは error_messages プラグマを無効にします。
(廃止) -Xs オプションは、将来のリリースで削除される予定です。適切なビルドおよびコンパイルに -Xs が必要になる C コードは、少なくとも ISO C 標準の C99 ダイアレクトに準拠するように、つまり -std=c99 でコンパイルできるように移行することをお勧めします。
-std または -xlang フラグを指定した場合、-Xc、-Xa、-Xt、および -Xs フラグは使用できません。
-std フラグを使用しない場合、 -X (大文字の X である点に注意) オプションは 1990 および 1999 ISO C 規格に準拠する度合いを指定します。-xc99 の値により、-X オプションが適用される ISO C 規格のバージョンが異なります。-xc99 オプションは、デフォルトでは -xc99=all になっています。この場合は、1999 ISO/IEC C 規格のサブセットをサポートします。-xc99=none を指定した場合は、1990 ISO/IEC C 規格をサポートします。サポートされている 1999 ISO/IEC の機能については、「D.1」を参照してください。ISO/IEC C と K&R C の相違点については、「付録 H」を参照してください。
コンパイラのデフォルトモードは、-pedantic フラグのない -std=c11 です。-xc99 フラグが指定されているかまたは有効な場合、-Xa がコンパイラのデフォルトモードになります 。
-Xc
(c = conformance) ISO C にない言語構造を使用しているプログラムに対してエラーや警告を発行します。このオプションは、K&R C 互換性拡張機能なしで、ISO C に厳格に準拠しています。 –-Xc オプションを指定すると事前定義されたマクロ __STDC__ の値は 1 になります。
–Xa
ISO C に K&R C 互換性拡張機能を加え、ISO C により求められる意味の変更を含めたものです。K&R C と ISO C が同じ構造体に異なる意味を指定している場合、コンパイラは ISO C の解釈を使用します。-Xa オプションを -xtransition オプションと併せて使用すると、異なる意味論に関する警告が出力されます。–Xa オプションを指定すると事前定義されたマクロ __STDC__ の値は –0 になります。
-Xt
(t = transition) このオプションは、ISO C ＋ K&R C 互換性拡張 (ISO C により求められる意味の変更 なし) を使用します。 K&R C と ISO C が同じ構文に対して異なるセマンティクスを指定している場合、コンパイラは K&R C の解釈を使用します。-Xt オプションを -xtransition オプションと併せて使用すると、異なる意味論に関する警告が出力されます。-Xt オプションを指定すると事前定義されたマクロ __STDC__ の値は 0 になります。
-Xs
(s = K&R C) ISO C と K&R C とで異なる動作を持つすべての言語構造体について警告を試みます。コンパイラ言語には、K&R C と互換性のあるすべての機能が含まれています。このオプションは前処理のために cpp を呼び出します。__STDC__ はこのモードでは定義されません。
(x86) 廃止。このオプションは使わないでください。代わりに、-xchip=generic を使用してください。廃止オプションに、廃止のオプションの全一覧をまとめています。
(x86) 廃止。このオプションは使わないでください。代わりに、-xchip=generic を使用してください。廃止オプションに、廃止のオプションの全一覧をまとめています。
arg をリンカー ld(1) に渡します。—z arg と同等
(Solaris x86/x64 のみ) コンパイラフラグ -xaddr32=yes は、結果として生成される実行可能ファイルまたは共有オブジェクトを 32 ビットアドレス空間に制限します。
この方法でコンパイルする実行可能ファイルは、32 ビットアドレス空間に制限されるプロセスを作成する結果になります。
-xaddr32=no を指定する場合は、通常の 64 ビットバイナリが作成されます。
-xaddr32 オプションを指定しないと、-xaddr32=no が想定されます。
-xaddr32 だけを指定すると、-xaddr32=yes が想定されます。
このオプションは、-m64 コンパイルのみ、および SF1_SUNW_ADDR32 ソフトウェア機能をサポートしている Oracle Solaris プラットフォームのみに適用できます。Linux カーネルはアドレス空間制限をサポートしていないので、Linux ではこのオプションは使用できません。
単一のオブジェクトファイルが -xaddr32=yes を指定してコンパイルされた場合は、出力ファイル全体が -xaddr32=yes を指定してコンパイルされたものと、リンク時に想定されます。
32 ビットアドレス空間に制限される共有オブジェクトは、制限された 32 ビットモードのアドレス空間内で実行されるプロセスから読み込む必要があります。
詳細は、『Linker and Libraries Guide』で説明されている SF1_SUNW_ADDR32 ソフトウェア機能の定義を参照してください。
コンパイラで -xalias_level オプションを使用して、型に基づく別名の解析による最適化でのレベルを指定します。このオプションは、コンパイル対象の変換ユニットで、指定した別名レベルを有効にします。
-xalias_level コマンドを発行しない場合、コンパイラは -xalias_level=any を仮定します。値を設定しないで -xalias_level を指定する場合、デフォルトは -xalias_level=layout になります。
-xalias_level オプションを使用するには、-xO3 以上の最適化レベルが必要です。最適化がこれよりも低く設定されている場合は、警告が表示され、-xalias_level オプションは無視されます。
-xalias_level オプションを発行しても、別名レベルごとに記述されている規則と制限を遵守しない場合、プログラムが未定義の動作をします。
l を次の表のいずれかの用語で置き換えます。
(廃止) このオプションは、将来のリリースで削除される予定です。代わりに -xprevise を使用してください。
ソースコードの静的分析を生成します。Oracle Solaris Studio コードアナライザを使用して表示できます。
—xanalyze=code を指定してコンパイルし、別の手順でリンクするときは、リンク手順でも —xanalyze=code を含めてください。
デフォルトは —xanalyze=%none です。
Linux では、-xanalyze=code を -xannotate とともに指定する必要があります。
詳細は、Oracle Solaris Studio コードアナライザのドキュメントを参照してください。
最適化ツールおよび可観測性ツール binopt(1)、 code-analyzer(1)、discover(1)、collect (1)、および uncover(1) によってあとで使用できるバイナリを作成します。
Oracle Solaris でのデフォルトは -xannotate=yes です。Linux でのデフォルトは -xannotate=no です。値なしで -xannotate を指定することは、-xannotate=yes と同義です。
最適化および監視ツールを最適に使用するためには、コンパイル時とリンク時の両方で -xannotate=yes が有効である必要があります。最適化および監視ツールを使用しないときは、-xannotate=no を指定してコンパイルおよびリンクすると、バイナリとライブラリが若干小さくなります。
対象となる命令セットアーキテクチャー (ISA) を指定します。
このオプションは、コンパイラが生成するコードを、指定した命令セットアーキテクチャーの命令だけに制限します。このオプションは、すべてのターゲットを対象とするような命令としての使用は保証しません。ただし、このオプションを使用するとバイナリプログラムの移植性に影響を与える可能性があります。
別々の手順でコンパイルしてリンクする場合は、両方の手順に同じ -xarch の値を指定してください。
_asm 文を指定するときや、アーキテクチャー固有の命令を使用する .il インラインテンプレートファイルを使ってコンパイルするときは、コンパイルエラーを避けるために適切な -xarch 値を指定することが必要な場合があります。
次の表は、SPARC プラットフォームと x86 プラットフォームの両方に共通する -xarch キーワードの一覧です。
|
次の表は、SPARC プラットフォームでの -xarch キーワードの説明です。
|
また、次のことにも注意してください。
generic、sparc、sparcvis2、sparcvis3、sparcfmaf、sparcima でコンパイルされたオブジェクトライブラリファイル (.o) をリンクして、一度に実行できます。ただし、リンクされているすべての命令セットをサポートしているプロセッサでのみ実行できます。
特定の設定で、生成された実行可能ファイルが実行されなかったり、従来のアーキテクチャーよりも実行速度が遅くなったりする場合があります。また、4 倍精度 (REAL*16 および long double) 浮動小数点命令は、これらの命令セットアーキテクチャーのいずれにも実装されないため、コンパイラは、そのコンパイラが生成したコードではそれらの命令を使用しません。
次の表に、x86 プラットフォームでの -xarch フラグを示します。
|
プログラムのいずれかの部分が x86 プラットフォーム上で —m64 でコンパイルまたはリンクされる場合、プログラムのすべての部分もこれらのいずれかのオプションでコンパイルされる必要があります。各種 Intel 命令セットアーキテクチャー (SSE、SSE2、SSE3、SSSE3 など) の詳細は、http://www.intel.com にある Intel-64 および IA-32 の『Intel Architecture Software Developer's Manual』を参照してください。
x86 の特記事項および バイナリの互換性の妥当性検査も参照してください。
このオプションは単体でも使用できますが、-xtarget オプションの展開の一部でもあります。したがって、特定の -xtarget オプションで設定される -xarch のオーバーライドにも使用できます。-xtarget=ultra2 は -xarch=sparcvis -xchip=ultra2 -xcache=16/32/1:512/64/1 に展開されます。次のコマンドでは、-xarch=generic は、-xtarget=ultra2 の展開で設定された -xarch=sparcvis をオーバーライドします。
example% cc -xtarget=ultra2 -xarch=generic foo.c
このオプションを最適化と併せて使用する場合、適切なアーキテクチャーを選択すると、そのアーキテクチャー上での実行パフォーマンスを向上させることができます。ただし、適切な選択をしなかった場合、パフォーマンスが著しく低下するか、あるいは、作成されたバイナリプログラムが目的のターゲットプラットフォーム上で実行できない可能性があります。
別々の手順でコンパイルしてリンクする場合は、両方の手順に同じ -xarch の値を指定してください。
ループの自動並列化を有効にします。依存性の解析 (ループの繰り返し内部でのデータ依存性の解析) およびループ再構成を実行します。最適化が -xO3 以上でない場合、最適化は -xO3 に引き上げられ、警告が出されます。
独自のスレッド管理を行なっている場合には、-xautopar を使用しないでください。
より高速な実行を実現するため、このオプションには、複数のハードウェアスレッドがあるシステムが必要です。使用するスレッドの数を指定するには、OMP_NUM_THREADS または PARALLEL 環境変数を使用します。これらの環境変数とそのデフォルト値については、『OpenMP API ユーザーズガイド』を参照してください。
最高のパフォーマンスを得るため、並列領域の実行に使用するスレッドの数が、マシン上で使用できるハードウェアスレッド (仮想プロセッサ) の数を超えないようにしてください。Oracle Solaris システムでは、psrinfo (1M) コマンドを使用すると、この数を特定できます。Linux システムでは、ファイル /proc/cpuinfo を調べることでこの数を特定できます。
-xautopar を使用してコンパイルとリンクを一度に実行する場合、リンクには自動的にマイクロタスキングライブラリ (libmtsk.so) およびスレッドに対して安全な C 実行時ライブラリが含まれます。-xautopar を使用して別々にコンパイルし、リンクする場合、-xautopar でリンクする必要があります。Table A–2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。
(SPARC) このオプションは廃止されており、コンパイラの将来のリリースで削除される予定です。-xannotate[=yes|no]を参照してください。
コンパイラに あとで最適化、変換、および分析するためにバイナリを準備するように指示します。このオプションは、実行可能ファイルまたは共有オブジェクトの構築に使用できます。このオプションを有効にするには、最適化レベル -xO1 以上で使用する必要があります。このオプションを使用すると、構築したバイナリのサイズが少し増えます。
コンパイルとリンクを別々に行う場合は、両方の手順に -xbinopt を指定する必要があります。
example% cc -c -xO1 -xbinopt=prepare a.c b.c example% cc -o myprog -xbinopt=prepare a.o
一部のソースコードがコンパイルに使用できない場合も、このオプションを使用してそのほかのコードがコンパイルされます。このとき、最終的なバイナリを作成するリンク手順で、このオプションを使用する必要があります。この場合、このオプションでコンパイルされたコードだけが最適化、変換、分析できます。
-xbinopt=prepare と -g を指定してコンパイルすると、デバッグ情報が取り込まれるので、実行可能ファイルのサイズが増えます。デフォルトは -xbinopt=off です。
詳細は、binopt(1) のマニュアルページを参照してください。
標準ライブラリ関数を呼び出すコードの最適化を改善するには、-xbuiltin オプションを使用します。多くの標準ライブラリ関数 (math.h や stdio.h で定義されたものなど) は、さまざまなプログラムで一般的に使用されます。-xbuiltin オプションは、パフォーマンスに役立つ場合、コンパイラが組み込み関数やインラインシステム関数を置き換えることを許可します。 コンパイラが実際に置換を行う関数を判断するために、オブジェクトファイル内のコンパイラコメントを読み取る方法については、er_src(1) のマニュアルページを参照してください。
これらの置換によって、errno の設定の信頼性が失われる場合があります。プログラムが errno の値に依存している場合、このオプションの使用は避けてください。errno の値の保持も参照してください。
-xbuiltin=%default は、errno を設定しない関数のみをインライン化します。errno の値はどの最適化レベルでも常に正確であり、高い信頼度でチェックできます。-xbuiltin=%default が -xO3 以下の場合、コンパイラはどの呼び出しをインライン化すると役立つかを判断し、ほかのものはインライン化しません。-xbuiltin=%none オプションは、ライブラリ関数のすべての置換を無効にします。
-xbuiltin を指定しない場合、デフォルトは、最適化レベル -xO1 以上でコンパイルするときは -xbuiltin=%default、 -xO0 のときは -xbuiltin=%none です。引数なしで -xbuiltin を指定する場合、デフォルトは -xbuiltin=%all で、コンパイラはより積極的に組み込み関数を置き換えたり、標準ライブラリ関数をインライン化したりします。
-fast を指定してコンパイルする場合は、-xbuiltin は %all になります。
-std=c89 および -xCC を指定した場合は、コンパイラで C++ 形式のコメントが認識されます。このオプションを使用すると、// を使用してコメントの始まりを示すことができます。
-xc99 オプションは、C99 規格 (『Programming Language - C (ISO/IEC 9899:1999)』) からの実装機能に対するコンパイラの認識状況を制御します。
次の表に、o の許容値の一覧を示します。複数の値はコンマで区切ることができます。
|
-xc99 を指定しない場合は、コンパイラではデフォルトで -xc99=all,no_lib が設定されます。値を指定しないで -xc99 を指定すると、オプションは -xc99=all に設定されます。
-std または -xlang フラグが指定されている場合、-xc99 フラグは使用できません。
オプティマイザ用のキャッシュ特性を定義します。この定義によって、特定のキャッシュが使用されるわけではありません。
オプションのプロパティー [/ti ] は、キャッシュを共有できるスレッド数を設定します。t の値を指定しない場合のデフォルトは 1 です。
c には次のいずれかを指定します。
generic
native
s1/l1/a1[/t1]
s1/l1/a1[/t1]:s2/l2/a2[/t2]
s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3]
s、l、a、t の各特性の定義は次のとおりです。
レベル i のデータキャッシュのサイズ (キロバイト単位)
レベル i のデータキャッシュのラインサイズ (バイト単位)
レベル i のデータキャッシュの結合特性
レベル i でキャッシュを共有するハードウェアスレッドの数
次に、-xcache の値を示します。
|
例: -xcache=16/32/4:1024/32/1 では、次の内容を指定します。
レベル 1 のキャッシュ:
16K バイト
ラインサイズ 32 バイト
4 ウェイアソシアティブ
レベル 2 のキャッシュ:
1024 バイト
ラインサイズ 32 バイト
ダイレクトマッピングの結合規則
(SPARC) 廃止。このオプションは使わないでください。このオプションでコンパイルすると、現在の SPARC プラットフォームでの実行速度が遅いコードが生成されます。代わりに -O を使用して、-xarch、-xchip、および -xcache のコンパイラデフォルトを利用します。
オプションこのオプションは、char 型が符号なしで定義されているシステムからのコードの移行を簡単にするためだけに提供されています。そのようなシステムからの移植以外では、このオプションは使用しないでください。char の符号に依存するコードだけは、signed または unsigned を明示的に指定するように書き直す必要があります。
次の表に、o の許容値の一覧を示します。
|
-xchar を指定しない場合は、コンパイラでは -xchar=s が指定されます。
-xchar を指定するけれども値を指定しない場合は、コンパイラは -xchar=s と見なします。
-xchar オプションは、-xchar でコンパイルしたコードでだけ、char 型の値の範囲を変更します。このオプションは、システムルーチンまたはヘッダーファイル内の char 型の値の範囲は変更されません。特に、CHAR_MAX および CHAR_MIN の値 (limits.h で定義される) は、このオプションを指定しても変更されません。したがって、CHAR_MAX および CHAR_MIN は、通常の char で符号化可能な値の範囲は表示されなくなります。
-xchar を使用するときは、マクロ内の値が符号付きの場合があるため、char を定義済みシステムマクロと比較する際には特に注意してください。この状況は、マクロを使用してアクセスするエラーコードを戻すルーチンでもっとも一般的です。エラーコードは、一般的には負の値になっています。したがって、char をそのようなマクロによる値と比較するときは、結果は常に false になります。負の数値が符号なしの型の値と等しくなることはありません。
ライブラリ経由でエクスポートされるインタフェースのルーチンをコンパイルするために、-xchar を使用しないでください。Oracle Solaris Studio のすべてのターゲットプラットフォームの ABI は、型 char を signed として指定し、システムライブラリはそれに応じて動作します。char を符号なしにする影響は、システムライブラリで十分にテストされていませんでした。このオプションを使用する代わりに、char 型の符号の有無に依存しないようにコードを変更してください。型 char の符号は、コンパイラやオペレーティングシステムによって異なります。
複数文字定数の文字を指定されたバイト順序で配置することにより、整定数を生成します。o には、次のいずれかの値を使用します。
low: 複数文字定数の文字を低いバイトから順に配置します。
high: 複数文字定数の文字を高いバイトから順に配置します。
default: 複数文字定数の文字を、コンパイルモード (-X v) で決定された順に配置します。詳細は、文字定数および -X[c|a|t|s]を参照してください。
スタックオーバーフローに関する実行時検査を追加し、局所変数を初期化します。
次の表に、o の値の一覧を示します。
|
-xcheck を指定しない場合は、コンパイラではデフォルトで -xcheck=%none が指定されます。引数を指定せずに xcheck を使用した場合は、コンパイラではデフォルトで -xcheck=%all が指定されます。
-xcheck オプションは、コマンド行で累積されません。コンパイラは、コマンドで最後に指定したものに従ってフラグを設定します。したがってスタックオーバーフロー診断と局所変数の初期化の両方を有効にするには、次のオプションを使用します。
cc -xcheck=stkovf:diagnose,init_local ...
-xcheck=init_local では、次の表に示すように、コンパイラは初期化子なしで宣言されたローカル変数を事前定義された値に初期化します。(これらの値は変更される可能性があるため、信頼しないでください)。
|
計算された goto で使用するために宣言されたローカル変数 (単純な void * ポインタ) は、表中のポインタの説明に従って初期化されます。
次の局所変数型は初期化されません: 修飾された const、register、計算された goto のラベル番号、ローカルラベル。
初期化されていない参照が可視エラーを生成する可能性を最大化するために、struct 内の基本型であるフィールドは、表で説明されているとおりに初期化されます。union 内で最初に宣言された pointer または float フィールドも同様です。
配列要素も表で説明されているとおりに初期化されます。
入れ子の struct、union、および配列フィールドは、ビットフィールドを含む struct、pointer または float フィールドのない union、または完全に初期化できない型の配列を除いて、表で説明されているとおりに初期化されます。これらの例外は、型 double のローカル変数に使用される値で初期化されます。
このオプションは単独でも使用できますが、-xtarget オプションの展開の一部です。その主な使用方法は、-xtarget オプションで提供される値をオーバーライドすることです。
このオプションは、処理対象となるプロセッサを指定することによって、タイミング特性を指定します。いくつかの影響があります。
命令の順序 (スケジューリング)
コンパイラが分岐を使用する方法
意味が同じもので代用できる場合に使用する命令
次の表は、SPARC プラットフォーム向けの c の -xchip 値の一覧です。
|
次の表は、x86 プラットフォーム向けの -xchip の値をまとめています。
|
次の表に、v の値の一覧を示します。
|
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 のどちらを使用するかを決定するには、elfdump -c を使用してセクションヘッダー sh_name: .got を探すことによって、大域オフセットテーブル (GOT) のサイズを確認します。sh_size 値が GOT のサイズです。GOT が 8,192 バイトに満たない場合は、-xcode=pic13 を指定します。そうでない場合は、-xcode=pic32 を指定します。詳細は、elfdump(1) のマニュアルページを参照してください。
-xcode どのように使用するべきかを決定するには、次のガイドラインに従います。
実行可能ファイルを構築する場合は、-xcode=pic13 と -xcode=pic32 のどちらも使用しない。
実行可能ファイルにリンクするためだけのアーカイブライブラリを構築する場合は、-xcode=pic13 と -xcode=pic32 のどちらも使用しない。
共有ライブラリを構築する場合は、-xcode=pic13 から始めてし、GOT のサイズが 8,192 バイトを超えたら、-xcode=pic32 を使用する。
共有ライブラリにリンクするためのアーカイブライブラリを構築する場合は、-xcode=pic32 を使用する。
廃止。使用しないでください。代わりに –xipo を使用します。—xcrossfile は —xipo=1 の別名です。
C コンパイラが ISO C ソース文字コードの要件に準拠しないロケールで記述されたソースコードを受け付けられるようにします。これらのロケールには、ja_JP.PCK が含まれます。
コンパイラの翻訳段階でこのようなロケールの処理が必要になると、コンパイルの時間が非常に長くなることがあります。そのため、このオプションを使用するのは、前述のロケールのソース文字を含むソースファイルをコンパイルする場合に限定すべきです。
コンパイラは、-xcsi が発行されないかぎり、ISO C ソース文字コードの要件に準拠しないロケールで記述されたソースコードを認識しません。
DWARF 形式のデバッグ情報を読み取るソフトウェアを保守している場合は、-xdebugformat=dwarf を指定します。このオプションにより、コンパイラは DWARF 標準形式を使用してデバッグ情報を生成します。これがデフォルトです。
|
-xdebugformat を指定しない場合は、コンパイラでは -xdebugformat=dwarf が指定されます。このオプションには引数が必要です。
このオプションは、-g オプションによって記録されるデータの形式に影響します。-g を指定しなくても、一部のデバッグ情報が記録されますが、その情報の形式もこのオプションによって制御されます。したがって、-g を使用しなくても、-xdebugformat は効果があります。
dbx とパフォーマンスアナライザソフトウェアは、STABS 形式と DWARF 形式を両方とも理解するので、このオプションを使用しても、いずれかのツールの機能に対する影響はありません。
詳細は、dumpstabs(1) および dwarfdump(1) のマニュアルページを参照してください。
タグタイプという用語は、タグ付きの型 (struct、union、enum、および class) を意味します。
次のリストには、サブオプション a に指定できる値が含まれています。サブオプションに接頭辞no%を適用すると、そのサブオプションが無効になります。デフォルトは -xdebuginfo=%none です。サブオプションなしで -xdebuginfo を指定することは禁止されています。
デバッグ情報は生成されません。これはデフォルト値です。
行番号およびファイル情報を出力します。
パラメータの場所の一覧情報を出力します。スカラー値 (たとえば、int、char *) の完全指定の型情報および型名を出力しますが、タグタイプの完全な定義は出力されません。
構文的にグローバル変数およびローカル変数である変数の場所の一覧情報を出力します。これには、ファイルおよび関数の static は含まれますが、クラスの static および extern は含まれません。スカラー値 (int、char * など) の完全指定の型情報および型名を出力しますが、タグタイプの完全な定義は出力されません。
関数と変数の宣言、メンバー関数、およびクラス宣言の静的なデータメンバーを出力します。
param および variable データセットから参照されるタグタイプの完全指定の型情報、およびテンプレートの定義を出力します。
マクロ情報を出力します。
DWARF コードタグ (Stabs N_PATCH とも呼ばれます) を出力します。これは、RTC および discover によって使用されるビットフィールド、構造体のコピー、およびスピルに関する情報です。
ハードウェアカウンタプロファイルに関する重要な情報を生成します。この情報には、ldst_map、ld/st 命令と参照されているシンボルテーブルのエントリのマッピング、およびバックトラックが分岐先を超えていないことを確認するため使用される分岐先アドレスの branch_target テーブルが含まれています。詳細は、-xhwcprof を参照してください。
次のマクロは、-xdebuginfo およびほかのオプションの組み合わせに次のように展開されます。
-g = -g2
-gnone =
-xdebuginfo=%none
-xglobalize=no
-xpatchpadding=fix
-xkeep_unref=no%funcs,no%vars
-g1 =
-xdebuginfo=line,param,codetag
-xglobalize=no
-xpatchpadding=fix
-xkeep_unref=no%funcs,no%vars
-g2 =
-xdebuginfo=line,param,decl,variable,tagtype,codetag
-xglobalize=yes
-xpatchpadding=fix
-xkeep_unref=funcs,vars
-g3 =
-xdebuginfo=line,param,decl,variable,tagtype,codetag,macro
-xglobalize=yes
-xpatchpadding=fix
-xkeep_unref=funcs,vars
ループの繰り返し内部でのデータ依存関係を解析し、ループの交換、ループの融合、スカラー置換など、ループの再構成を行います。
最適化レベルが -xO3 かそれ以上に設定されている場合はすべて、-xdepend のデフォルトは -xdepend=on です。-xdepend の明示的な設定を指定すると、デフォルト設定はオーバーライドされます。
引数なしで -xdepend を指定すると、-xdepend=yes と同等であることを意味します。
依存性の解析はシングルプロセッサシステムで役立つことがあります。ただし、シングルプロセッサシステムで -xdepend を使用する場合は、-xautopar も指定するべきではありません。-xdepend 最適化は、マルチプロセッサシステムのために行われるためです。
プログラム内でマクロがどのように動作しているかを確認するときは、このオプションを使用します。このオプションは、定義済みマクロ、解除済みマクロ、実際の使用状況といった情報を提供します。マクロの処理順序に基づいて、標準エラー (stderr) に出力します。-xdumpmacros オプションは、ファイルの終わりまで、または dumpmacros プラグマまたは end_dumpmacros プラグマによって上書きされるまで有効です。dumpmacrosを参照してください。
次の表に、value の有効な引数の一覧を示します。接頭辞 no% は関連付けられた値を無効にします。
|
オプションの値は累積されるので、-xdumpmacros=sys -xdumpmacros=undefs を指定することは、-xdumpmacros=undefs,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_C 0x512 #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_C 0x512 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 __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 コマンド行オプションのスコープより優先されます。
ソースファイルに対して構文および意味検査を実行しますが、オブジェクトコードや実行可能コードは生成しません。
リンカーによる関数と変数の最適な順序の並べ替えを有効にします。
このオプションは、コンパイラに対して、関数またはデータ変数を別々のセクションフラグメントに配置するように指示します。それによってリンカーは、リンカーの -M オプションで指定されたマップファイル内の指示を使用して、これらのセクションの順序を並べ替えてプログラムのパフォーマンスを最適化できます。この最適化は、ページフォルト時間がプログラム実行時間の多くの割合を占めているときにもっとも効果的です。
変数の並べ替えは、実行時のパフォーマンスに悪影響を及ぼす次のような問題の解決に役立ちます。
メモリー内で関係ない変数どうしが近接しているために生じる、キャッシュやページの競合
関係のある変数がメモリー内で互いに近くにないことの結果として、不必要に大きな作業セットサイズ。
使用していない weak 変数のコピーが有効なデータ密度を低下させた結果生じる、不必要に大きな作業セットサイズ
最適なパフォーマンスを得るために変数と関数の順序を並べ替えるには、次の処理が必要です。
-xF によるコンパイルとリンク
関数またはデータのマップファイルの生成については、『Oracle Solaris Studio パフォーマンスアナライザ』および『Oracle Solaris リンカーとライブラリ』に記載された手順に従ってください。
リンカーの -M オプションを使用して新しいマップファイルを再リンクします。
アナライザで再実行して、パフォーマンスが向上したかどうかを検証します。
次の表に、v の値の一覧を示します。
|
サブオプションを無効にするには、(%all および %none を除いた) 値の前に no% を置きます。たとえば no%func などです。
-xF を指定しない場合のデフォルトは、-xF=%none です。引数を指定しないで -xF を指定した場合のデフォルトは、-xF=%none,func です。
-xF=lcldata を使用するとアドレス計算最適化が一部禁止されるので、このフラグは試験によって正しいと認められた場合にのみ使用してください。
analyzer(1)、および ld(1) のマニュアルページを参照してください。
ファイルの静的変数のグローバル化を制御します (関数は制御しません)。
グローバル化は修正継続機能および内部手続きの最適化で必要となる手法であり、それによってファイルの静的シンボルがグローバルに拡張されます。同じ名前のシンボルを区別するために、名前に接頭辞が追加されます。
デフォルトは -xglobalize=no です。-xglobalize と指定することは -xglobalize=yes と指定することと同等です。
-xpatchpadding を参照してください。
-xipo もグローバル化を要求し、-xglobalize をオーバーライドします。
-xhelp=flags は、コンパイラオプションのサマリーを表示します。
(SPARC) コンパイラのハードウェアカウンタによるプロファイリングのサポートを有効にします。
-xhwcprof を有効にすると、コンパイラは、プロファイル対象のロード命令およびストア命令と、それらが参照するデータ型および構造体メンバーをツールが関連付けるのに役立つ情報を、-g で生成されたシンボル情報と組み合わせて生成します。プロファイルデータを、命令領域ではなくターゲットのデータ領域に関連付けます。これにより、命令プロファイリングだけからは簡単には得られない、動作に対する洞察が提供されます。
指定した一連のオブジェクトファイルは、-xhwcprof を指定してコンパイルできます。ただし、-xhwcprof は、アプリケーション内のすべてのオブジェクトファイルに適用されたときに、もっとも役立ちます。アプリケーションのオブジェクトファイルに分散しているすべてのメモリー参照が洗い出され、相互に関連付けられます。
コンパイルとリンクを別々に行う場合は、-xhwcprof をリンク時にも使用してくだ さい。-xhwcprof への今後の拡張により、リンク時にこれを使用することが必要になる可能性があります。Table A–2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。
-xhwcprof=enable または -xhwcprof=disable のインスタンスは、同じコマンド行にある以前の -xhwcprof のインスタンスをすべてオーバーライドします。
-xhwcprof はデフォルトでは無効です。引数を指定せずに -xhwcprof と指定することは、-xhwcprof=enable と指定することと同等です。
-xhwcprof を使用する場合は最適化を有効にし、デバッグのデータ形式を DWARF (-xdebugformat=dwarf) に設定しておく必要があります (これは、現在の Oracle Solaris Studio コンパイラのデフォルトです)。同じコマンド行に -xhwcprof と -xdebugformat=stabs を指定することはできません。
-xhwcprof は -xdebuginfo を使用して必要最低限のデバッグ情報を自動的に有効にするため、-g は必要ありません。
-xhwcprof と -g を組み合わせて使用すると、コンパイラに必要な一時ファイル記憶領域は、-xhwcprof と -g を単独で指定することによって増える量の合計を超えて大きくなります。
-xhwcprof は、次のようにさまざまなよりプリミティブなオプションに展開されるマクロとして実装されます。
-xhwcprof
-xdebuginfo=hwcprof,tagtype,line
-xhwcprof=enable
-xdebuginfo=hwcprof,tagtype,line
-xhwcprof=disable
-xdebuginfo=no%hwcprof,no%tagtype,no%line
次のコマンドは example.c をコンパイルし、ハードウェアカウンタによるプロファイリングのサポートを指定し、DWARF シンボルを使用してデータ型と構造体メンバーのシンボリック解析を指定します。
example% cc -c -O -xhwcprof -g -xdebugformat=dwarf example.c
ハードウェアカウンタベースのプロファイリングの詳細は、『Oracle Solaris Studio パフォーマンスアナライザ』を参照してください。
list for -xinline の書式を次に示します。[{%auto ,func_name,no%func_name }[,{%auto,func_name, no%func_name}]...]
-xinline は、オプションのリストで指定した関数だけのインライン化を試行します。このリストは、空か、func_name、no%func_name、または %auto のコンマ区切りのリストを含みます (func_name は関数名です)。-xinline は、–xO3 以上でのみ効果を持ちます。
|
値のリストは、左から右に累積されます。-xinline=%auto,no%foo と指定した場合、コンパイラは foo 以外のすべての関数をインライン化しようとします。-xinline=%bar,%myfunc,no%bar と指定した場合は、myfunc だけのインライン化が試行されます。
最適化レベルを -xO4 以上に設定してコンパイルすると、通常はソースファイルで定義されたすべての関数参照のインライン化が試行されます。-xinline オプションを使用することで、特定の関数をインライン化しないように制限できます。関数または %auto を指定せずに -xinline= のみを指定することは、ソースファイル内のどのルーチンもインライン化されないことを示します。%auto を指定せずに func_name および no%func_name を指定した場合、コンパイラはリストで指定されたそれらの関数のみをインライン化しようとします。最適化レベルが -xO4 以上に設定された状態で、-xinline オプションの値リストで %auto が指定されている場合、コンパイラは no%func_name で明示的に除外されていないすべての関数をインライン化しようとします。
次のいずれかの条件に該当する場合、ルーチンはインライン化されません。警告は出力されませんので注意してください。
最適化のレベルが -xO3 未満である。
ルーチンが見つからない。
iropt がルーチンのインライン化を実行できない。
ルーチンのソースが、コンパイル対象のファイル内にない (ただし、-xipo を参照)。
コマンド行で -xinline を複数指定した場合は、それらは累積されません。コマンド行の最後の -xinline が、コンパイラがインライン化しようとする関数を指定します。
-xldscope も参照してください。
このオプションは、コンパイラが関数呼び出しをインライン化するタイミングを判断するために使用するヒューリスティックを手動で変更するために使用します。
このオプションは -O3 以上でのみ有効となります。次のサブオプションは、自動インライン化がオンである場合に、-O4 以上でのみ有効となります。
次のサブオプションでは、n は正の整数である必要があります。a には次のいずれかを指定できます。
|
-xinline_param=default を指定すると、コンパイラはサブオプションのすべての値にデフォルト値を設定します。
このオプションを指定しない場合、デフォルトは -xinline_param=default です。
値およびオプションのリストは、左から右に適用されます。このため、-xinline_param=max_inst_hard:30,..,max_inst_hard:50 と指定した場合は、値 max_inst_hard:50 がコンパイラに渡されます。
コマンド行に複数の -xinline_param オプションを指定した場合、サブオプションのリストは同様に左から右に適用されます。たとえば、次のように指定した場合は
-xinline_param=max_inst_hard:50,min_counter:70 ... -xinline_param=max_growth:100,max_inst_hard:100
次の指定と同じになります。
-xinline_param=max_inst_hard:100,min_counter:70,max_growth:100
このオプションは、コンパイラによる関数のインライン化に関する報告を生成し、標準出力に書き込みます。報告のタイプは n の値 (0、1、または 2) によって異なります。
レポートは生成されません。
インライン化パラメータのデフォルト値のサマリー報告が生成されます。
インライン化メッセージの詳細な報告が生成され、インライン化された呼び出しサイトとインライン化されなかった呼び出しサイト、およびインライン化されなかったことの簡潔な理由が示されます。この報告には、インライン化されなかった呼び出しサイトをインライン化するために使用できる -xinline_param の推奨値が含まれている場合があります。
-xinline_report を指定しない場合、n のデフォルト値は 0 です。-xinline_report を指定して =n を指定しない場合、デフォルト値は 1 です。
-xlinkopt が指定されている場合は、インライン化されなかった呼び出しサイトに関するインライン化メッセージが正確でないことがあります。
スレッドアナライザで分析するためにプログラムをコンパイルして計測するには、このオプションを指定します。スレッドアナライザの詳細は、tha(1) のマニュアルページを参照してください。
そうすることで、パフォーマンスアナライザを使用して計測されたプログラムを collect –r races で実行し、データ競合の検出実験を行うことができます。計測機構の組み込まれたコードをスタンドアロンで実行した場合は、より遅く実行されます。
–xinstrument=no%datarace を指定して、スレッドアナライザ用のソースコードの準備をオフにすることができます。これはデフォルト値です。
–xinstrument= は引数付きで指定する必要があります。
コンパイルとリンクを別々に行う場合は、コンパイル時とリンク時の両方で –xinstrument=datarace を指定する必要があります。
このオプションは、プリプロセッサトークン __THA_NOTIFY を定義します。#ifdef __THA_NOTIFY を指定して、libtha(3) ルーチンへの呼び出しを保護できます。
このオプションにも、–g を設定します。
a を 0、 1、または 2 と置き換えます。引数なしの -xipo は、-xipo=1 と同義です。-xipo=0 はデフォルト設定で、-xipo を無効にします。-xipo=1 を指定した場合は、すべてのソースファイルでインライン化が実行されます。
-xipo=2 を指定した場合は、コンパイラは内部手続きの別名解析と、メモリーの割り当ておよび配置の最適化を実行し、キャッシュ性能を向上させます。
このコンパイラは、内部手続き解析コンポーネントを呼び出すことにより、プログラムの一部の最適化を実行します。このオプションを指定すると、リンク段階ですべてのオブジェクトファイルを介して最適化を実行し、最適化の対象をコンパイルコマンドのソースファイルだけに限定しません。ただし、-xipo によるプログラム全体の最適化には、アセンブリ (.s) ソースファイルは含まれません。
-xipo は、コンパイル時とリンク時の両方で指定する必要があります。Table A–2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。
-xipo オプションは、ファイルを介して最適化を実行する際に必要な情報を追加するため、非常に大きなオブジェクトファイルを生成します。ただし、この補足情報は最終的な実行可能バイナリファイルの一部にはなりません。実行可能プログラムのサイズが拡大するのは、最適化が追加実行されるためです。このコンパイル段階で作成されたオブジェクトファイルには、内部でコンパイルされた追加の分析情報が含まれているため、リンク段階でファイル相互の最適化を実行できます。
-xipo は、大きなマルチファイルアプリケーションをコンパイルおよびリンクする際に特に便利です。このフラグを指定してコンパイルされたオブジェクトファイルには、ソースプログラムファイルとコンパイル済みプログラムファイル間で内部手続き解析を有効にする解析情報が含まれています。
解析と最適化は、-xipo を指定してコンパイルされたオブジェクトファイルに限定され、オブジェクトファイルやライブラリまでは及びません。
-xipoは複数の段階にわかれているため、コンパイルとリンクを個別に実行する場合、各ステップで -xipo を指定する必要があります。
-xipo に関するそのほかの重要な情報を次に示します。
少なくとも最適化レベル -xO4 を必要とします。
-xipo なしでコンパイルされたオブジェクトは、-xipo でコンパイルされたオブジェクトと自由にリンクできます。
次の例では、コンパイルとリンクが単一ステップで実行されます。
cc -xipo -xO4 -o prog part1.c part2.c part3.c
オプティマイザは 3 つのすべてのソースファイル間でファイル間のインライン化を実行します。この処理は最後のリンクステップで行われるので、ソースファイルのコンパイルを単一コンパイルですべて実行する必要はありません。-xipo オプションをそれぞれ指定して、個別のコンパイルを何回か実行してもかまいません。
次の例では、個別のステップでコンパイルとリンクが実行されます。
cc -xipo -xO4 -c part1.c part2.c cc -xipo -xO4 -c part3.c cc -xipo -xO4 -o prog part1.o part2.o part3.o
制限は、-xipo でコンパイルする場合でも、ライブラリはファイル相互の内部手続き解析に含まれない点です。次の例を参照してください。
cc -xipo -xO4 one.c two.c three.c ar -r mylib.a one.o two.o three.o ... cc -xipo -xO4 -o myprog main.c four.c mylib.a
この例では、内部手続きの最適化は one.c、two.c および three.c 間と、main.c および four.c 間で実行されますが、main.c または four.c と mylib.a のルーチン間では実行されません。最初のコンパイルは未定義のシンボルに関する警告を生成する場合がありますが、内部手続きの最適化は、コンパイルおよびリンクステップであるために実行されます。
内部手続き解析では、コンパイラは、リンクステップでオブジェクトファイル群を操作しながら、プログラム全体の解析と最適化を試みます。このとき、コンパイラは、このオブジェクトファイル群に定義されているすべての foo() 関数 (またはサブルーチン) に関して次の 2 つのことを仮定します。
実行時、このオブジェクトファイル群の外部で定義されている別のルーチンによって foo() が明示的に呼び出されない。
オブジェクトファイル群内のルーチンからの foo() 呼び出しが、そのオブジェクトファイル群の外部に定義されている別のバージョンの foo() からの割り込みを受けない。
仮定 2 が真でない場合は、-xipo=1 または -xipo=2 でコンパイルしないでください。
1 例として、独自のバージョンの malloc で関数 malloc() を置き換え、-xipo=2 を指定してコンパイルするケースを考えてみましょう。したがって、コードとリンクされる malloc() を参照する、あらゆるライブラリのあらゆる関数のコンパイルで -xipo=2 を使用する必要があるとともに、リンクステップでそれらのオブジェクトファイルが必要になります。システムライブラリにはこの処理を実行できない場合があるため、独自のバージョンの malloc() を -xipo=2 でコンパイルしないでください。
もう 1 つの例として、別々のソースファイルにある foo() および bar() という 2 つの外部呼び出しを含む共有ライブラリを構築するケースを考えてみましょう。また、bar() は foo() を呼び出すと仮定します。foo() が実行時に割り込み処理される可能性がある場合、foo() または bar() のソースファイルを -xipo=1 または -xipo=2 でコンパイルしないでください。それ以外の場合、foo() が bar() にインライン化され、それによって正しくない結果になる可能性があります。
新しい -xipo_archive オプションは、コンパイラが、リンカーに渡されるオブジェクトファイルと、-xipo でコンパイルされて実行可能ファイルを生成する前にアーカイブライブラリ (.a) に常駐するオブジェクトファイルを最適化することを許可します。コンパイル中に最適化されたライブラリに含まれるオブジェクトファイルはすべて、その最適化されたバージョンに置き換えられます。
次の表に、a の値の一覧を示します。
|
-xipo_archive の値が指定されない場合、-xipo_archive=none に設定されます。
–xipo_archive= を値付きで指定する必要があります。
-xipo_build を指定せずに -xipo を構築すると、コンパイラを通じて 2 回受け渡しが行われることになります (オブジェクトファイルを生成するとき、およびリンク時にファイル間の最適化を実行するとき)。-xipo_build を設定すると、最初の受け渡し時には最適化されず、リンク時にのみ最適化されることによって、コンパイルの時間が短縮されます。-xipo を指定するとリンク時に最適化が実行されるため、オブジェクトファイルを最適化する必要はありません。-xipo_build を指定して作成された最適化されていないオブジェクトファイルを -xipo を指定せずにリンクして最適化すると、アプリケーションのリンクが未解決のシンボルエラーで失敗します。
次の例では、.o ファイルの高速ビルドを実行し、リンク時にファイル間の最適化を行なっています。
% cc -O -xipo -xipo_build -o code1.o -c code1.c % cc -O -xipo -xipo_build -o code2.o -c code2.c % cc -O -xipo -o a.out code1.o code2.o
-xipo_build は、.o ファイルを作成するときに -O をオフにして、ファイルを迅速に作成します。完全な -O の最適化は、-xipo のファイル間の最適化の一部としてリンク時に実行されます。
次の例は、-xipo を使用せずにリンクしています。
% cc -O -o a.out code1.o code2.o
-xipo_build を指定して code1.o または code2.o を生成した場合、リンク時にエラーになり、シンボル __unoptimized_object_file が未解決であることが示されます。
.o ファイルを別々に作成する場合、デフォルトの動作は -xipo_build=no です。ただし、実行可能ファイルまたはライブラリがソースファイルから 1 回の受け渡しで作成された場合は、-xipo_build が暗黙的に有効になります。例:
% cc -fast -xipo a.c b.c c.c
この場合、a.o、b.o、および c.o が生成される最初の受け渡しで、-xipo_build=yes が暗黙的に有効になります。この動作を無効にするには、オプション -xipo_build=no を含めます。
#pragma ivdep プラグマの解釈を無効化または設定します (ベクトル依存を無視)。
ivdep プラグマは、最適化の目的でループ内で検出された、配列参照へのループがもたらす依存関係の一部またはすべてを無視するようにコンパイラに指示します。これによってコンパイラは、マイクロベクトル化、分散、ソフトウェアパイプラインなど、それ以外の場合は不可能なさまざまなループ最適化を実行できます。これは、依存関係が重要ではない、または依存関係が実際に発生しないことをユーザーが把握している場合に使用されます。
#pragma ivdep 指令の解釈は、—xivdep オプションの値に応じて異なります。
次のリストは、p の値とそれらの意味です。
ループキャリーのベクトル依存と想定されるものを無視
ループキャリーのベクトル依存をすべて無視
逆方向のループキャリーのベクトル依存と想定されるものを無視
逆方向のループキャリーのベクトル依存をすべて無視
依存を無視しない (ivdep プラグマの無効化)
これらの解釈は、ほかのベンダーの ivdep プラグマの解釈との互換性のために提供されます。
複数のプロセスでコンパイルします。このフラグを指定しない場合、デフォルトの動作は -xjobs=auto です。
コンパイラが処理を行うために生成するプロセスの数を設定するには、-xjobs オプションを指定します。このオプションを使用すると、マルチ CPU マシン上での構築時間を短縮できます。現時点では、-xjobs とともに使用できるのは -xipo オプションだけです。-xjobs=n を指定すると、内部手続きオプティマイザ は、さまざまなファイルをコンパイルするために呼び出せるコードジェネレータインスタンスの最大数として n を使用します。
一般に、n に指定する確実な値は、使用できるプロセッサ数に 1.5 を掛けた数です。生成されたジョブ間のコンテキスト切り替えにより生じるオーバーヘッドのため、使用できるプロセッサ数の何倍もの値を指定すると、パフォーマンスが低下することがあります。また、あまり大きな数を使用すると、スワップ領域などシステムリソースの限界を超える場合があります。
-xjobs=auto を指定すると、コンパイラは適切な並列ジョブの数を自動的に選択します。
-xjobs には必ず値を指定する必要があります。それ以外の場合は、エラー診断が発行され、コンパイルは中止されます。
-xjobs を指定しない場合、デフォルトの動作は -xjobs=auto です。これは、コマンド行に -xjobs=n を追加することによってオーバーライドできます。コマンド行に複数の -xjobs のインスタンスがある場合、一番右にあるインスタンスが実行されるまで相互にオーバーライドします。
次の例は、-xipo に最大 3 つの並列プロセスを使用しています。
% cc -xipo -xO4 -xjobs=3 t1.o t2.o t3.o
次の例は、-xipo に単一のプロセスを順次リンクしています。
% cc -xipo -xO4 -xjobs=1 t1.o t2.o t3.o
次の例は、コンパイラが -xipo のジョブ数を選択して、並列でリンクしています。
% cc -xipo -xO4 t1.o t2.o t3.o
これは、-xjobs=auto を明示的に指定したときの動作とまったく同じです。
% cc -xipo -xO4 -xjobs=auto t1.o t2.o t3.o
参照されない関数および変数の定義を維持します。接頭辞 no%は、その定義を場合によっては削除することをコンパイラに許可します。
デフォルトは no%funcs,no%vars です。-xkeep_unref を指定することは -xkeep_unref=funcs,vars を指定することと同等であり、-keep_unref によってすべてが維持されることを意味します。
指定した機能 (name) のスタック関連の最適化を禁止します。
すべてのコードのスタック関連最適化を禁止します。
すべてのコードのスタック関連最適化を許可します。
このオプションは累積的で、コマンド行で複数回指定できます。たとえば、—xkeepframe=%all —xkeepframe=no%func1 は、func1 を除くすべての関数についてスタックフレームを維持するべきであることを示しています。また、—xkeepframe は —xregs=frameptr をオーバーライドします。たとえば、—xkeepframe=%all —xregs=frameptr は、すべての関数のスタックが保持されるはずですが、—xregs=frameptr の最適化は無視されることを示します。
このオプションがコマンド行で指定されていないと、コンパイラはデフォルトの -xkeepframe=%none を使用します。このオプションが値なしで指定されると、コンパイラは -xkeepframe=%all を使用します。
-xlang フラグは、-std フラグによって指定されたデフォルトの libc の動作をオーバーライドするために使用できます。language は次のいずれかである必要があります。
libc のランタイムライブラリの動作が C90 標準に準拠するように指定します。
libc のランタイムライブラリの動作が C99 標準に準拠するように指定します。
c99 と同義です。c99 および c11 の libc のランタイムライブラリの動作は同じです。
-xlang を指定しない場合のデフォルト値は、-std=c99 を指定したときは c99、および -std=c11 を指定したときは c11 です。それ以外の場合、デフォルト値は c89 です。
-xlang を指定した場合、-Xc、-Xa、-Xt、-Xs、および -xc99 フラグは使用できません。一緒に指定するとコンパイラによってエラーが発行されます。
別々の手順でコンパイルしてリンクする場合は、両方の手順に同じ -xlang の値を使用する必要があります。
言語混合リンクに使用するドライバを決定するには、次の言語階層を使用します。
CC コマンドを使用します。詳細は、『C++ ユーザーズガイド 』を参照してください。
f95 コマンドを使用します。詳細は、『Fortran ユーザーズガイド』を参照してください。
f95 -xlang=f77 を使用します。詳細は、『Fortran ユーザーズガイド』を参照してください。
cc コマンドを使用します。
extern シンボルの定義に対するデフォルトのリンカースコープを変更するには、-xldscope オプションを指定します。デフォルトを変更すると、実装がよりうまく隠されるので、より早く、より安全に共有ライブラリを使用できます。
v には、次のいずれかを指定します。
|
-xldscope を指定しない場合は、コンパイラでは -xldscope=global が指定されます。引数を指定しないで -xldscope を指定すると、エラーが表示されます。コマンド行にこのオプションの複数のインスタンスがある場合、一番右にあるインスタンスが実行されるまで相互にオーバーライドします。
クライアントがライブラリ内の関数をオーバーライドできるようにする場合は必ず、ライブラリの構築時に関数がインラインで生成されないようにしてください。コンパイラは次の状況で関数をインライン化します。
関数名を -xinline 付きで指定する。
-xO4 以上でコンパイルする。この場合、インライン化は自動的に行われることがあります。
インライン指定子を使用する。
インラインプラグマを使用する。
ファイル間最適化を使用する。
たとえば、ABC というライブラリにデフォルトの allocator 関数があり、ライブラリクライアントがその関数を使用でき、ライブラリの内部でも使用されるものとします。
void* ABC_allocator(size_t size) { return malloc(size); }
-xO4 以上でライブラリを構築すると、コンパイラはライブラリコンポーネント内での ABC_allocator の呼び出しをインライン化します。ライブラリユーザーが、カスタマイズされたバージョンで ABC_allocator を置き換えようとする場合、ABC_allocator を呼び出したライブラリコンポーネント内では置き換えは発生しません。最終的なプログラムには、この関数の相異なるバージョンが含まれることになります。
__hidden 指定子または __symbolic 指定子で宣言されたライブラリ関数は、ライブラリの構築時にインラインで生成できます。これらの関数では、ユーザーによるオーバーライドはサポートされていません。詳細については、リンカースコープ指定子を参照してください。
__global 指示子で宣言されたライブラリ関数はインラインで宣言しないでください。また、-xinline コンパイラオプションを使用してインライン化することから保護されるようにしてください。
-xinline、-xO、-xipo 、 #pragma inline も参照してください。
例外が起きた場合の数学ルーチンの戻り値を強制的に IEEE 754 形式にします。 この場合、例外メッセージは出力されないので、errno には依存しないでください。
実行速度を上げるため、一部のライブラリルーチンをインライン化します。オプションによって浮動小数点演算用オプションとプラットフォームに適したアセンブリ言語のインラインテンプレートが選択されます。
-xlibmil は、-xinline フラグで関数を指定しているかどうかに関係なく、関数をインライン化します。
ただし、こうした置換によって errno の値の信頼性が失われることがあります。プログラムが errno の値に依存している場合、このオプションの使用は避けてください。errno の値の保持も参照してください。
このオプションによって、コンパイラは最適化された数学ルーチンのライブラリを利用できます。このオプションを使用するときは -fround=nearest を指定することによって、デフォルトの丸めモードを使用する必要があります。
数学ルーチンライブラリは最高のパフォーマンスが得られるように最適化されており、通常、高速なコードを生成します。この結果は、通常の数学ライブラリが生成する結果と少し異なることがあります。その場合、通常、異なるのは最後のビットです。
これらの置換によって、errno の設定の信頼性が失われる可能性があります。プログラムが errno の値に依存している場合、このオプションの使用は避けてください。詳細は、errno の値の保持を参照してください。
このライブラリオプションをコマンド行に指定する順序は重要ではありません。
このオプションは -fast オプションを指定した場合にも設定されます。
-fast および -xnolibmopt も参照してください。
(廃止) Sun Performance Library とリンクするときは、-library=sunperf を使用してください。
このオプションは、コンパイル時には暗黙的に無視されます。
再配置可能なオブジェクトファイルのリンク時の最適化を実行するようコンパイラに指示します。このような最適化は、リンク時にオブジェクトのバイナリコードを解析することによって実行されます。オブジェクトファイルは書き換えられませんが、結果の実行可能コードは元のオブジェクトコードとは異なる場合があります。
-xlinkopt をリンク時に有効にするには、少なくともコンパイルコマンドで -xlinkopt を使用する必要があります。-xlinkopt を指定しないでコンパイルされたオブジェクトバイナリについても、オプティマイザは限定的な最適化を実行できます。
-xlinkopt は、コンパイラのコマンド行にある静的ライブラリのコードは最適化しますが、コマンド行にある共有 (動的) ライブラリのコードは最適化しません。共有ライブラリを構築 (-G でコンパイル) するときに、-xlinkopt も使用できます。
level には、実行する最適化のレベルを 0、1、2 のいずれかで設定します。次の表に、最適化レベルの一覧を示します。
|
別の手順でコンパイルする場合は、コンパイルとリンクの両方の手順で -xlinkopt を指定する必要があります。
example% cc -c -xlinkopt a.c b.c example% cc -o myprog -xlinkopt=2 a.o
Table A–2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。
レベルパラメータは、コンパイラのリンク時にだけ使用されます。例では、オブジェクトバイナリが暗黙のレベル 1 でコンパイルされた場合でも、使用される最適化後レベルは 2 です。
-xlinkopt をレベルパラメータなしで指定した場合は、-xlinkopt=1 を示します。
-xlinkopt オプションでは、プログラムを最適化するためにプロファイルフィードバック (-xprofile) が必要です。プロファイリングは、コードの使用頻度がもっとも高い部分ともっとも低い部分を明らかにし、オプティマイザにそれに基づいて処理を集中するよう指示します。リンク時の最適化は、コードの最適な配置によって命令キャッシュミスを大幅に削減できる大規模アプリケーションで特に重要です。また、-xlinkopt はプログラム全体のコンパイル時に使用するともっとも効果的です。このオプションは次のように使用します。
example% cc -o progt -xO5 -xprofile=collect:prog file.c example% progt example% cc -o prog -xO5 -xprofile=use:prog -xlinkopt file.c
プロファイルフィードバックの使用方法についての詳細は、–xprofile=pを参照してください。
-xlinkopt でコンパイルする場合は、-zcombreloc リンカーオプションは使用しないでください。
このオプションを指定してコンパイルすると、リンク時間がわずかに増えます。オブジェクトファイルも大きくなりますが、実行可能ファイルのサイズは変わりません。-xlinkopt と -g を指定してコンパイルすると、デバッグ情報が取り込まれるので、実行可能ファイルのサイズが増えます。
どのループが並列化されるかを表示します。ループを並列化しない理由を簡潔に提供します。-xloopinfo オプションは、-xautopar が指定されている場合にのみ有効です。指定されていない場合は、コンパイラによって警告が表示されます。
コードの実行速度を上げるには、このオプションにマルチプロセッサシステムが必要です。シングルプロセッサシステムでは、通常、生成されたコードの実行速度は低下します。
指定された C プログラムで C プリプロセッサのみを実行します。プリプロセッサがメイクファイル依存関係を生成して結果を標準出力に送信することを要求します。make ファイルと依存関係についての詳細は、make(1) のマニュアルページを参照してください。
例:
#include <unistd.h>
void main(void)
{}
この出力を生成します。
e.o: e.c e.o: /usr/include/unistd.h e.o: /usr/include/sys/types.h e.o: /usr/include/sys/machtypes.h e.o: /usr/include/sys/select.h e.o: /usr/include/sys/time.h e.o: /usr/include/sys/types.h e.o: /usr/include/sys/time.h e.o: /usr/include/sys/unistd.h
-xM と -xMF を指定する場合、-xMF で指定したファイルに、コンパイラはすべてのメイクファイルの依存関係情報を追加します。
-xM と同様にメイクファイルの依存関係を生成しますが、/usr/include ファイルは除きます。例:
more hello.c
#include<stdio.h>
main()
{
(void)printf(“hello\n”);
}
cc– xM hello.c
hello.o: hello.c
hello.o: /usr/include/stdio.h
-xM1 オプションを使用してコンパイルすると、ヘッダーファイルの依存関係の出力が抑制されます。
cc– xM1 hello.c hello.o: hello.c
-Xs モードでは -xM1 は使用できません。
-xM1 と -xMF を指定する場合、-xMF で指定したファイルに、コンパイラはすべてのメイクファイルの依存関係情報を追加します。
-xM と同様にメイクファイル依存関係を生成しますが、コンパイルは続行します。-xMD は、-o 出力 filename (指定されている場合、つまり入力ソース filename) から派生した、メイクファイル依存関係情報のための出力ファイルを生成します。filename の接尾辞は .d で置換 (または追加) されます。-xMD と -xMF を指定する場合、-xMF で指定したファイルに、プリプロセッサはすべてのメイクファイルの依存関係情報を書き込みます。複数のソースファイルを使って -xMD -xMF または -xMD -o filename でコンパイルすることは許可されず、エラーが生成されます。依存関係ファイルがすでに存在する場合は上書きされます。
makefile の依存関係の出力先ファイルを指定するには、このオプションを使用します。1 つのコマンド行の -xMF で、複数の入力ファイルに個々の filename を指定することはできません。複数のソースファイルで -xMD -xMF または -xMMD -xMF を使用してコンパイルすることはできず、エラーが生成されます。依存関係ファイルがすでに存在する場合は上書きされます。
このオプションは -xM または -xM1 とともに使用できません。
システムヘッダーファイルを除き、メイクファイルの依存関係を生成するには、このオプションを使用します。このオプションは -xM1 と同じ機能を提供しますが、コンパイルは続行します。-xMMD は、-o 出力 filename (指定されている場合、つまり入力ソース filename) から派生した、メイクファイル依存関係情報のための出力ファイルを生成します。filename の接尾辞は .d で置換 (または追加) されます。-xMF を指定する場合、コンパイラは代わりに、ユーザーが指定したファイル名を使用します。複数のソースファイルで -xMMD -xMF または -xMMD -o filename を使用してコンパイルすることはできず、エラーが生成されます。依存関係ファイルがすでに存在する場合は上書きされます。
データセグメントをテキストセグメントにマージします。このコンパイルで生成するオブジェクトファイルで初期化されるデータは読み取り専用なので、ld -N でリンクしていないかぎり、プロセスどうしで共有することができます。
3 つのオプション -xMerge -ztext -xprofile=collect を一緒に使用するべきではありません。-xMerge を指定すると、静的に初期化されたデータを読み取り専用記憶領域に強制的に配置します。 -ztext を指定すると、位置に依存するシンボルを読み取り専用記憶領域内で再配置することを禁止します。-xprofile=collect を指定すると、書き込み可能記憶領域内で、静的に初期化された、位置に依存するシンボルの再配置を生成します。
このオプションは、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 は、不正境界整列メモリーアクセスの動作を指定します。次に、-memalign の境界整列と動作の値を示します。
|
b を i か f のいずれかに設定してコンパイルしたオブジェクトファイルにリンクする場合は、必ず、-xmemalign を指定する必要があります。Table A–2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。
コンパイル時に境界整列が判別できるメモリーへのアクセスの場合、コンパイラはそのデータの境界整列に適したロードおよびストア命令を生成します。
境界整列がコンパイル時に決定できないメモリーアクセスの場合、コンパイラは、境界整列を想定して、必要なロード/ストア命令のシーケンスを生成します。-xmemalign オプションは、これらの状況のときにコンパイラが想定するデータの最大メモリー境界整列を指定できます。-xmemalign オプションは、境界整列に失敗したメモリーへのアクセスが実行時に発生した場合に行われるエラー動作 (処理) についても指定できます。
実行時の実際のデータ境界整列が指定された整列に達しない場合、境界整列に失敗したアクセス (メモリー読み取りまたは書き込み) が行われると、トラップが発生します。このトラップに対して可能な応答は 2 つあります。
OS がトラップを SIGBUS シグナルに変換します。プログラムがこのシグナルを捕捉しない場合、プログラムは停止します。プログラムがシグナルを捕捉しても、境界整列に失敗したアクセスが成功するわけではありません。
境界整列に失敗したアクセスが正常に成功したかのように OS がアクセスを解釈し、プログラムに制御を戻すことによってトラップを処理します。
次のデフォルトの値は、-xmemalign オプションがまったく指定されていない場合にのみ適用されます。
すべての 32 ビットプラットフォーム (-m32) で -xmemalgin=8i。
すべての 64 ビットプラットフォーム (-m64) で -xmemalign=8s。
-xmemalign オプションが指定されているけれども値が与えられていないときのデフォルトは、すべてのプラットフォームで -xmemalign=1i です。
次の表は、さまざまな境界整列状況を扱うために -xmemalign をどのように使用できるかについての説明です。
|
(x86) -xmodel オプションは、コンパイラが Oracle Solaris x86 プラットフォームのために 64 ビットオブジェクトの形式を変更することを許可します。そのようなオブジェクトのコンパイルにのみ指定するようにしてください。
このオプションは、64 ビット対応の x64 プロセッサで –m64 も指定した場合にのみ有効です。
次の表に、a の値の一覧を示します。
|
このオプションは累積的ではないため、コンパイラはコマンド行でもっとも右側の -xmodel に従ってモデル値を設定します。
-xmodel を指定しない場合、コンパイラは -xmodel=small と見なします。引数を指定せずに-xmodel を指定すると、エラーになります。
すべての変換単位をこのオプションでコンパイルする必要はありません。アクセスするオブジェクトが範囲内にあれば、選択したファイルをコンパイルできます。
すべての Linux システムが medium モデルをサポートしているわけではありません。
デフォルトのライブラリリンクを行いません。つまり ld(1) に -l オプションを渡しません。通常は、cc ドライバが -lc を ld に渡します。
-xnolib を使用する場合、すべての -l オプションをユーザーが渡さなければいけません。
数学ライブラリのルーチンをインライン化しません。このオプションは、–fast オプションのあとで使用します。例:
% cc– fast– xnolibmil....
以前に指定された -xlibmopt オプションを無効にすることによって、最適化された数学ライブラリがコンパイラによって使用されることを防ぎます。たとえば、このオプションは -xlibmopt を有効にする -fast のあとで使用します。
% cc -fast -xnolibmopt ...
実行可能ファイルに共有ライブラリへの実行時検索パスを組み込みません。
このオプションは、プログラムで使用される共有ライブラリに異なるパスを持つ可能性がある顧客に出荷される実行可能ファイルを構築する場合に推奨されます。
コンパイラ最適化レベルを設定します。 大文字 O のあとに数字 1、2、3、 4、または 5 が続きます。一般に、最適化のレベルが高いほど、実行時パフォーマンスは向上します。しかし、最適化レベルが高ければ、それだけコンパイル時間が増え、実行可能ファイルが大きくなる可能性があります。
いくつかの場合には、-xO2 がほかのものよりパフォーマンスが良いことがあり、-xO3 が -xO4 よりパフォーマンスが良いことがあります。
オプティマイザによりメモリーが不足した場合は、最適化のレベルを下げて現在の関数を再試行することによって処理を続行しようとします。これ以後の関数に対してはコマンド行オプションで指定されている本来のレベルで再開します。
デフォルトは最適化なしです。最適化レベルを指定しない場合にのみ可能です。最適化レベルを指定する場合は、最適化を無効にできません。
最適化レベルを設定しないようにする場合は、最適化レベルを示すようなオプションを指定しないようにしてください。たとえば、-fast は最適化を -xO5 に設定するマクロオプションです。最適化レベルを暗黙に示すほかのすべてのオプションは、最適化レベルが設定されているという警告メッセージを発行します。最適化なしでコンパイルする唯一の方法は、コマンド行またはメイクファイルから最適化レベルを指定するすべてのオプションを削除することです。
-xO3 以下の最適化レベルで -g を指定すると、ほぼ完全な最適化と可能なかぎりのシンボル情報を取得できます。末尾呼び出しの最適化とバックエンドのインライン化は無効です。
-xO4 以上の最適化レベルで -g を指定すると、完全な最適化と可能なかぎりのシンボル情報を取得できます。
-g を指定したデバッグでは、-xOn が抑制されませんが、-xOn はいくつかの方法で -g を制限します。たとえば、最適化オプションは、デバッグのユーティリティを減らすので dbx からの変数を表示できませんが、それでも dbx where コマンドを使用して、シンボリックトレースバックを取得することはできます。詳細は、『dbx コマンドによるデバッグ』の第 1 章の「最適化コードのデバッグ」を参照してください。
-xO と -xmaxopt の両方を指定する場合、-xO で設定する最適化レベルが -xmaxopt 値を超えてはいけません。
-xO3 または -xO4 で (1 つの関数内のコードが数千行になるような) 大きな関数を最適化する場合、膨大な量の仮想メモリーが必要になり、そのような場合、マシンパフォーマンスが低下することがあります。
次の表は、SPARC プラットフォームでの最適化レベルの一覧です。
|
次の表は、x86 プラットフォームでの最適化レベルの一覧です。
|
デバッグの詳細は、Oracle Solaris Studio: dbx コマンドによるデバッグを参照してください。最適化の詳細は、Oracle Solaris Studio パフォーマンスアナライザマニュアルを参照してください。
-xldscope および -xmaxopt も参照してください。
-xopenmp の値を次の表に示します。
|
-xopenmp を指定するけれども値を指定しない場合、コンパイラは -xopenmp=parallel であると見なします。-xopenmp を一切指定しない場合、コンパイラは -xopenmp=none であると見なします。
dbx を指定して OpenMP プログラムをデバッグする場合、-g -xopenmp=noopt を指定してコンパイルすれば、並列化部分にブレークポイントを設定して変数の内容を表示できます。
-xopenmp のデフォルトは、将来のリリースで変更される可能性があります。警告メッセージを出力しないようにするには、適切な最適化レベルを明示的に指定します。
OpenMP プログラムを実行するときに使用するスレッドの数を指定するには、OMP_NUM_THREADS 環境変数を使用します。OMP_NUM_THREADS が設定されていない場合、並列領域の実行に使用されるスレッドのデフォルトの数は、マシンで利用できるコアの数になりますが、上限は 32 です。別のスレッド数を指定するには、OMP_NUM_THREADS 環境変数を設定するか、omp_set_num_threads() OpenMP 実行時ルーチンを呼び出すか、並列領域ディレクティブの num_threads 節を使用します。最高のパフォーマンスを得るため、並列領域の実行に使用するスレッドの数が、マシン上で使用できるハードウェアスレッド (仮想プロセッサ) の数を超えないようにしてください。Oracle Solaris システムでは、psrinfo (1M) コマンドを使用すると、この数を特定できます。Linux システムでは、ファイル /proc/cpuinfo を調べることでこの数を特定できます。詳細は、『OpenMP API ユーザーズガイド』を参照してください。
入れ子並列は、デフォルトでは無効です。入れ子並列を有効にするには、OMP_NESTED 環境変数を TRUE に設定する必要があります。詳細は、『OpenMP API ユーザーズガイド』を参照してください。
コンパイルとリンクを別々に実行する場合は、コンパイル手順とリンク手順の両方に -xopenmp を指定してください。リンク手順とともに使用した場合、-xopenmp オプションは、OpenMP 実行時サポートライブラリ libmtsk.so とリンクします。
最新の機能と最適なパフォーマンスを得るために、OpenMP 実行時ライブラリの最新のパッチ、libmtsk.so がシステムにインストールされていることを確認してください。
マルチスレッド対応アプリケーションを構築するための OpenMP Fortran 95、C および C++ アプリケーションプログラムインタフェース (API) の詳細は、『Oracle Solaris Studio OpenMP ユーザーガイド』を参照してください。
すべての K&R C 関数のプロトタイプを出力する際、コンパイラはソースファイルに対して構文および意味検査のみ行います。このオプションは、オブジェクトコードや実行可能コードを生成しません。たとえば次のソースファイルに -xP を指定したと仮定します。
f()
{
}
main(argc,argv)
int argc;
char *argv[];
{
}
この出力を生成します。
int f(void); int main(int, char **);
SPARC: 次の値が有効です: 4k、8K、64K、512K、2M、4M、32M、256M、2G、16G、または default。
x86: 次の値が有効です: 4K、2M、4M、1G、または default。
有効なページサイズを指定しない場合は、要求は実行時にサイレントに無視されます。ターゲットプラットフォームに対して有効なページサイズを指定する必要があります。
ページ内のバイト数を判断するには、pagesize(1) Oracle Solaris コマンドを使用します。オペレーティングシステムでは、ページサイズ要求に従うという保証はありません。ただし、適切なセグメントの整合を使用して、要求されたページサイズを取得できる可能性を高められます。セグメントの整合の設定方法は、-xsegment_align オプションを参照してください。ターゲットプラットフォームのページサイズを判断するには、 pmap(2) または meminfo(2) を使用します。
-xpagesize オプションは、コンパイル時とリンク時に使用しないかぎり無効です。Table A–2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。
-xpagesize=default を指定する場合は、Oracle Solaris オペレーティングシステムがページサイズを設定します。
このオプションを指定してコンパイルすることは、LD_PRELOAD 環境変数を同等のオプションで mpss.so.1 に設定するか、またはプログラムを実行する前に同等のオプションを指定して Oracle Solaris コマンド ppgsz(1) を実行することと同じ効果を持ちます。詳細は、関連する Oracle Solaris マニュアルページを参照してください。
このオプションは -xpagesize_heap と -xpagesize_stack のマクロです。これらの 2 つのオプションは -xpagesize と同じ次の引数を使用します。-xpagesize を指定することで両方のオプションに同じ値を設定したり、それらをそれぞれ別々の値で指定したりできます。
このオプションは、—xpagesize と同じ値を受け入れます。有効なページサイズを指定しないと、要求は実行時に暗黙的に無視されます。
Oracle Solaris オペレーティングシステムでページのバイト数を判断するには、getpagesize(3C) コマンドを使用します。Oracle Solaris オペレーティングシステムは、ページサイズ要求に従うという保証を提供しません。ターゲットプラットフォームのページサイズを判断するには、 pmap(1) または meminfo(2) を使用します。
-xpagesize_heap=default を指定する場合は、Oracle Solaris オペレーティングシステムがページサイズを設定します。
このオプションを指定してコンパイルすることは、LD_PRELOAD 環境変数を同等のオプションで mpss.so.1 に設定するか、またはプログラムを実行する前に同等のオプションを指定して Oracle Solaris コマンド ppgsz(1) を実行することと同じ効果を持ちます。詳細は、関連する Oracle Solaris マニュアルページを参照してください。
-xpagesize_heap オプションは、コンパイル時とリンク時に使用しないかぎり無効です。Table A–2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。
このオプションは、—xpagesize と同じ値を受け入れます。有効なページサイズを指定しないと、要求は実行時に暗黙的に無視されます。
Oracle Solaris オペレーティングシステムでページのバイト数を判断するには、getpagesize(3C) コマンドを使用します。Oracle Solaris オペレーティングシステムは、ページサイズ要求に従うという保証を提供しません。ターゲットプラットフォームのページサイズを判断するには、 pmap(1) または meminfo(2) を使用します。
-xpagesize_stack=default を指定する場合は、Oracle Solaris オペレーティングシステムがページサイズを設定します。
このオプションを指定してコンパイルすることは、LD_PRELOAD 環境変数を同等のオプションで mpss.so.1 に設定するか、またはプログラムを実行する前に同等のオプションを指定して Oracle Solaris コマンド ppgsz(1) を実行することと同じ効果を持ちます。詳細は、関連する Oracle Solaris マニュアルページを参照してください。
-xpagesize_stack オプションは、コンパイル時とリンク時に使用しないかぎり無効 です。Table A–2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。
各関数の開始前にメモリー領域を予約します。fix を指定した場合、コンパイラは fix で必要となる領域を予約して続行します。これは最初のデフォルトです。patch を指定した場合、または値を指定しない場合、コンパイラはプラットフォーム固有のデフォルト値で予約します。値 -xpatchpadding=0 は 0 バイトの領域を予約します。size の最大値は、x86 では 127 バイト、および SPARC では 2048 バイトです。
このコンパイラオプションは、プリコンパイル済みヘッダー機能を起動します。v には、auto、autofirst、collect:pch_filename、use:pch_filename のいずれかを指定できます。この機能は、-xpch と -xpchstop オプションを、#pragma hdrstop ディレクティブと組み合わせることで利用できます。
-xpch オプションは、プリコンパイル済みヘッダーファイルを作成して、コンパイル時間を短縮するときに使用します。プリコンパイル済みヘッダーファイルは、大量のソースコードを含む一連の共通インクルードファイルセットをソースファイルが共有しているアプリケーションの、コンパイル時間を短縮します。プリコンパイル済みヘッダーを使用することによって、1 つのソースファイルから一連のヘッダーファイルに関する情報を収集し、そのソースファイルを再コンパイルする場合や、同じ一連のヘッダーを持つほかのソースファイルをコンパイルする場合に、その情報を使用することができます。コンパイラが収集する情報は、プリコンパイル済みヘッダーファイルに格納されます。
詳細は、次を参照してください。
コンパイラは、2 つの方法のいずれかでプリコンパイル済みヘッダーファイルを自動的に生成できます。1 つは、ソースファイルで検出された最初のインクルードファイルからプリコンパイル済みヘッダーファイルを作成する方法、もう 1 つの方法は、コンパイラが、ソースファイルで検出されたインクルードファイルのセット (最初のインクルードファイルから始めて、どのインクルードファイルが最後のものであるかを判断するためのよく定義されたポイントまで) から選択する方法です。プリコンパイル済みヘッダーを自動的に生成するためにコンパイラがどの方法を使用するかを判断するには、次の表で説明するフラグのいずれかを使用します。
|
プリコンパイル済みヘッダーファイルを手動で作成するには、最初に -xpch を使用し、collect モードを指定します。-xpch=collect を指定するコンパイルコマンドは、ソースファイルを 1 つしか指定できません。次の例では、-xpch オプションがソースファイル a.c に基づいて myheader.cpch というプリコンパイル済みヘッダーファイルを作成します。
cc -xpch=collect:myheader a.c
有効なプリコンパイル済みヘッダーファイル名には常に、接尾辞 .cpch が付きます。pch_filename を指定するときに、自分が接尾辞を追加することも、コンパイラに追加してもらうこともできます。たとえば、cc -xpch=collect:foo a.c と指定する場合は、プリコンパイル済みヘッダーファイルは foo.cpch と呼ばれます。
コンパイラが -xpch=auto および -xpch=autofirst と一緒にプリコンパイル済みヘッダーファイルを使用できない場合、新しいプリコンパイル済みヘッダーファイルを生成します。コンパイラが -xpch=use と一緒にプリコンパイル済みヘッダーファイルを使用できない場合は、警告が発行され、実際のヘッダーを使ってコンパイルが行われます。
-xpch=use:pch_filename を指定することによって、特定のプリコンパイル済みヘッダーを使用するようコンパイラに指示することもできます。プリコンパイル済みヘッダーファイルを作成するために使用されたソースファイルと同じインクルードファイルの並びを持つソースファイルであれば、いくつでも指定できます。たとえば、use モードのコマンドは次のようになる可能性があります: cc -xpch=use:foo.cpch foo.c bar.c foobar.c。
次の項目が真の場合にのみ、既存のプリコンパイル済みヘッダーファイルを使用してください。次のいずれかが真でない場合は、プリコンパイル済みヘッダーファイルを再作成するべきです。
プリコンパイル済みヘッダーファイルにアクセスするために使用するコンパイラは、プリコンパイル済みヘッダーファイルを作成したコンパイラと同じであること。あるバージョンのコンパイラによって作成されたプリコンパイル済みヘッダーファイルは、別のバージョンのコンパイラでは使用できない場合があります。
-xpch オプション以外で -xpch=use とともに指定するコンパイラオプションは、プリコンパイル済みヘッダーファイルが作成されたときに指定されたオプションと一致すること。
-xpch=use で指定する一連のインクルードヘッダー群は、プリコンパイル済み ヘッダーファイルが作成されたときに指定されたヘッダー群と同じであること。
-xpch=use で指定するインクルードヘッダーの内容が、プリコンパイル済みヘッダーファイルが作成されたときに指定されたインクルードヘッダーの内容と同じであること。
現在のディレクトリ (すなわち、コンパイルが実行中で指定されたプリコンパイル済みヘッダーファイルを使用しようとしているディレクトリ) が、プリコンパイル済みヘッダーファイルが作成されたディレクトリと同じであること。
-xpch=collect で指定したファイル内の前処理ディレクティブ (#include ディレクティブを含む) の最初のシーケンスが、-xpch=use で指定したファイル内の前処理ディレクティブのシーケンスと同じであること。
プリコンパイル済みヘッダーファイルを複数のソースファイル間で共有するために、これらのソースファイルには、最初のトークンの並びとして一連の同じインクルードファイルを使用していなければいけません。トークンはキーワードか名前、句読点のいずれかです。コンパイラは、コードおよび、#if 指令によって除外されたコードをトークンとして認識しません。この最初のトークンの並びは、活性文字列 (viable prefix) として知られています。言い替えれば、活性文字列は、すべてのソースファイルに共通のソースファイルの先頭部分です。コンパイラはこの活性文字列を、プリコンパイル済みヘッダーファイルを作成し、それによってソースからどのヘッダーファイルがプリコンパイルされるかを判断するためのベースとして使用します。
現在のコンパイル中にコンパイラが検出する活性文字列は、プリコンパイル済みヘッダーファイルの作成に使用した活性文字列と一致する必要があります。言い替えれば、活性文字列は、同じプリコンパイル済みヘッダーファイルを使用するすべてのソースファイル間で一貫して解釈される必要があります。
ソースファイルの活性文字列は、コメントと次の任意のプリプロセッサ指令のみで構成できます。
#include #if/ifdef/ifndef/else/elif/endif #define/undef #ident (if identical, passed through as is) #pragma (if identical)
これらの指令はいずれかがマクロを参照していてもかまいません。#else、#elif、および #endif 指令は、活性文字列内で一致している必要があります。コメントは無視されます。
-xpch=auto または -xpch=autofirst を指定すると、コンパイラは活性文字列の終点を自動的に判断します。次のように定義されます。
最初の宣言/定義
最初の #line 指令
#pragma hdrstop 指令
指定されたインクルードファイルのあと (–xpch=auto および –xpchstop が指定された場合)
最初のインクルードファイル (–xpch=autofirst が指定された場合)
-xpch=collect または -xpch=use の場合、活性文字列は #pragma hdrstop で終了します。
プリコンパイル済みヘッダーファイルを共有する各ファイルの活性文字列内では、対応する各 #define 指令と #undef 指令は同じシンボルを参照する必要があります。#define の場合は、それぞれが同じ値を参照する必要があります。各活性文字列内での順序も同じである必要があります。対応する各プラグマも同じで、その順序もプリコンパイル済みヘッダーを共有するすべてのファイルで同じでなければいけません。
ヘッダーファイルは、異なるソースファイル間で整合性のある方法で解釈されるとき (具体的には、完全な宣言のみを含むとき) に、プリコンパイル可能です。すなわち、どのファイルの宣言も有効な宣言として独立している必要があります。struct S; などの不完全な型宣言は有効な型宣言です。完全な型宣言がほかのファイルに存在している可能性があります。次のヘッダーファイルの例を考えてみてください。
file a.h
struct S {
#include "x.h" /* not allowed */
};
file b.h
struct T; // ok, complete declaration
struct S {
int i;
[end of file, continued in another file] /* not allowed*/
プリコンパイル済みヘッダーファイルに組み込まれるヘッダーファイルは、次の制約に違反してはいけません。これらの制限に違反するプログラムをコンパイルした場合、結果は予測できません。
ヘッダーファイルに、__DATE__ や __TIME__ が含まれていてはいけません。
ヘッダーファイルに、#pragma hdrstopが含まれていてはいけません。
ヘッダーに変数と関数の宣言が含まれている場合は、ヘッダーも同様にプリコンパイル可能です。
プリコンパイル済みヘッダーファイルの自動作成では、コンパイラは、そのファイルを SunWS_cache ディレクトリに書き込みます。このディレクトリは常に、オブジェクトファイルが作成される場所に置かれます。dmake の下で適切に機能するように、ファイルの更新はロックして行われます。
自動生成されるプリコンパイル済みヘッダーファイルをコンパイラに強制的に再構築させる必要がある場合は、CCadmin ツールを使って、プリコンパイル済みヘッダーファイルキャッシュディレクトリをクリアできます。詳細は、CCadmin(1) のマニュアルページを参照してください。
矛盾する -xpch フラグをコマンド行に指定しないでください。たとえば、-xpch=collect と -xpch=auto の両方を指定したり、-xpchstop=<include> を付けて -xpch=autofirst を指定したりすると、エラーになります。
-xpch=autofirst を指定するか、-xpchstop なしで -xpch=auto を指定した場合、最初のインクルードファイル、あるいは -xpch=auto に -xpchstop を付けて指定したインクルードファイルの前に宣言や定義、#line 指令があると、エラーになり、プリコンパイル済みヘッダーファイルの自動生成が無効になります。
-xpch=autofirst または -xpch=auto で、最初のインクルードファイルの前に #pragma hdrstop があると、プリコンパイル済みヘッダーファイルの自動生成が無効になります。
-xpch=collect が指定されている場合、コンパイラはプリコンパイル済みヘッダーファイル用の依存関係情報を生成します。この依存関係情報を利用するには、メイクファイル内に適切な規則を作成する必要があります。次のメイクファイルの例を考えてみてください。
%.o : %.c shared.cpch
$(CC) -xpch=use:shared -xpchstop=foo.h -c $<
default : a.out
foo.o + shared.cpch : foo.c
$(CC) -xpch=collect:shared -xpchstop=foo.h foo.c -c
a.out : foo.o bar.o foobar.o
$(CC) foo.o bar.o foobar.o
clean :
rm -f *.o shared.cpch .make.state a.out
これらの make 規則は、コンパイラによって生成される依存関係とともに、-xpch=collect で使用したソースファイルのいずれか、またはプリコンパイル済みヘッダーファイルの一部であるヘッダーのいずれかに変更があった場合、手動で作成されたプリコンパイル済みヘッダーファイルを強制的に再作成します。この制約は、古いプリコンパイル済みヘッダーファイルの使用を防ぎます。
-xpch=auto または -xpch=autofirst の場合、メイクファイルに追加の make 規則を作成する必要はありません。
-xpchstop=file オプションは、プリコンパイル済みヘッダーファイル用の活性文字列の最後のインクルードファイルを指定するときに使用します。コマンド行で -xpchstop を使用するのは、cc コマンドで指定する各ソースファイルの file を参照する最初のインクルード指令のあとに hdrstopプラグマを配置するのと同じことです。
<include> までのヘッダーファイルに基づくプリコンパイル済みヘッダーファイルを作成するには、-xpchstop=<include> と -xpch-auto を組み合わせて使用します。このフラグは、活性文字列全体に含まれているすべてのヘッダーファイルを使用するデフォルトの -xpch=auto の動作をオーバーライドします。
次の例では、-xpchstop オプションは、プリコンパイル済みヘッダーファイルの活性文字列が projectheader.h をインクルードして終わるよう指定します。したがって、privateheader.h は活性文字列の一部ではありません。
example% cat a.c
#include <stdio.h>
#include <strings.h>
#include "projectheader.h"
#include "privateheader.h"
.
.
.
example% cc -xpch=collect:foo.cpch a.c -xpchstop=projectheader.h -c
-xpch も参照してください。
(Solaris のみ) 移植可能な実行可能コード (Portable Executable Code、PEC) バイナリを生成します。このオプションは、プログラム中間表現をオブジェクトファイルとバイナリに入れます。このバイナリは、あとでチューニングやトラブルシューティングのために、使用される場合があります。
–xpec を指定して構築したバイナリは通常、–xpec なしで構築したバイナリより 5 ～ 10 倍の大きさになります。
–xpec を指定しない場合、コンパイラは –xpec=no と見なします。–xpec を指定するけれどもフラグを指定しない場合は、コンパイラは –xpec=yes と見なします。
(x86) Pentium プロセッサ用のコードを生成します。
gprof(1) によるプロファイリングの準備として、データを収集するためのオブジェクトコードを生成します。この記録メカニズムは実行が正常終了すると、gmon.outファイルを作成します。
プロファイルは、64 ビット Oracle Solaris プラットフォームでは prof(1) または gprof (1) を使用して、32 ビット Oracle Solaris プラットフォームでは gprof のみを使用して生成され、メイン実行可能ファイル内のルーチンと、実行可能ファイルのリンク時にリンカー引数として指定された共有ライブラリ内のルーチンの PC 標本データ (pcsample(2) を参照) から求められる、ユーザー CPU 時間の概算値を取り込みます。そのほかの共有ライブラリ (dlopen(3DL) を使用してプロセスの起動後に開かれたライブラリ) のプロファイルは作成されません。
32 ビット Oracle Solaris システムの場合、prof(1) を使用して生成されるプロファイルは、実行可能ファイル内のルーチンに制限されます。32 ビット共有ライブラリは、-xpg で実行可能ファイルをリンクし、gprof(1) を使用することでプロファイリングできます。
x86 システムでは、-xpg は -xregs=frameptr と互換性がありません。これら 2 つのオプションを一緒に使用しないでください。-xregs=frameptr は -fast に含まれている点にも注意してください。-fast を -xpg とともに使用するときは、-fast -xregs=no%frameptr -xpg を指定してコンパイルします。
現行の Oracle Solaris リリースには、-p でコンパイルされるシステムライブラリが含まれません。その結果、現行の Solaris プラットフォームで収集されるプロファイルには、システムライブラリルーチンの呼び出し回数が含まれません。
コンパイル時に -xpg を指定した場合は、リンク時にも指定する必要があります。コンパイル時とリンク時のオプションに、コンパイル時とリンク時の両方に指定する必要があるオプションの全一覧をまとめています。
先読みをサポートするそれらのアーキテクチャーで先読み命令を有効にします。
明示的な先読みは、測定方法によってサポートされる特殊な環境でのみ使用してください。
次の表に、val の値の一覧を示します。
|
デフォルトは -xprefetch=auto,explicit です。基本的に非線形のメモリーアクセスパターンを持つアプリケーションには、このデフォルトが良くない影響をもたらします。デフォルトを無効にするには、-xprefetch=no%auto,no%explicit を指定します。
sun_prefetch.h ヘッダーファイルには、明示的な先読み命令を指定するためのマクロが含まれています。先読み命令は、実行コード中のマクロの位置にほぼ相当するところに挿入されます。
先読みの応答時間とは、先読み命令を実行してから先読みされたデータがキャッシュで利用可能となるまでのハードウェアの遅延のことです。
係数には、n.n. という形式の正の数値を使用します。
コンパイラは、先読み命令と先読みされたデータを使用するロードまたはストア命令の距離を決定する際に先読み応答時間の値を想定します。先読みからロードまでの想定応答時間は、先読みからストアまでの想定応答時間と同じでない場合があります。
コンパイラは、幅広いマシンとアプリケーションで最適なパフォーマンスを得られるように先読みメカニズムを調整します。しかし、コンパイラの調整作業が必ずしも最適であるとはかぎりません。メモリーに負担のかかるアプリケーション、特に大型のマルチプロセッサでの実行を意図したアプリケーションの場合、先読みの応答時間の値を引き上げることにより、パフォーマンスを向上できる場合があります。この値を増やすには、1 よりも大きい係数を使用します。.5 と 2.0 の間の値は、おそらく最高のパフォーマンスを提供します。
外部キャッシュの中に完全に常駐するデータセットを持つアプリケーションの場合は、先読み応答時間の値を減らすことでパフォーマンスを向上できる場合があります。値を小さくするには、1 よりも小さな係数を使用します。
latx:factor サブオプションを使用するには、1.0 程度の係数から順にアプリケーションの性能テストを実行します。それに応じて係数を増減し、パフォーマンステストを再実行します。係数の調整を継続し、最適なパフォーマンスに到達するまでパフォーマンステストを実行します。係数を小刻みに増減すると、しばらくはパフォーマンスに変化がなく、突然変化し、再び平常に戻ります。
a の値は [no%]indirect_array_access です。
直接メモリーアクセス用の先読みが生成されるのと同じ方法で、-xprefetch_level オプションで指定するループ用の間接先読みをコンパイラが生成することを許可するときは、-xprefetch_auto_type=indirect_array_access を使用します。
-xprefetch_auto_type の値が指定されていない場合、-xprefetch_auto_type=no%indirect_array_access に設定されます。
-xalias_level などのオプションは、メモリー別名を明確化する情報の生成に役立つため、間接プリフェッチ候補の計算の積極性に影響し、このため、自動的な間接プリフェッチの挿入が促進されることがあります。
-xprefetch=auto で判断される先読み命令の自動挿入の積極性を制御するには、-xprefetch_level オプションを使用します。l は 1、2、または 3 である必要があります。-xprefetch_level が高いレベルであるほど、コンパイラはより積極的になります。つまり、より多くの先読みを取り込みます。
-xprefetch_level に適した値は、アプリケーションが持つキャッシュミス数によって異なります。-xprefetch_level の値を高くするほど、アプリケーションのパフォーマンスが向上する可能性が高くなります。
このオプションは、最適化レベル 3 以上、-xprefetch=auto でコンパイルされたときにのみ有効で、先読みをサポートするプラットフォーム (v8plus、 v8plusa、 v9、 v9a、 v9b、 sse2、 sse2a、 sse3、 amdsse4a、 sse4_1、 sse4_2、 aes、 avx、 avx_i、 avx2、 generic64、および native64) 用のコードを生成します。
-xprefetch_level=1 は、先読み命令の自動生成を有効にします。-xprefetch_level=2 は、レベル 1 を上回る追加生成を有効にします。-xprefetch_level=3 は、レベル 2 を上回る追加生成を有効にします。
デフォルトは、-xprefetch=auto を指定した場合は -xprefetch_level=1 になります。
コードアナライザを使用して表示できるソースコードの静的分析を生成する場合は、このオプションを指定してコンパイルします。
-xprevise=yes でコンパイルし、別の手順でリンクする場合、リンク手順でも -xprevise=yes をインクルードします。
デフォルトは -xprevise=no です。
Linux では、-xprevise=yes を -xannotate とともに指定する必要があります。
詳細は、Oracle Solaris Studio コードアナライザのドキュメントを参照してください。
プロファイルのデータを収集したり、プロファイルを使用して最適化したりします。
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 でコンパイルされるときの現在の作業用ディレクトリの相対パスとみなされます。
—xprofile=collect: prof_dir または —xprofile=tcov: prof_dir でプロファイルディレクトリ名を指定しない場合、プロファイルデータは実行時に、program.profile という名前のディレクトリに保存されます (program はプロファイリングされたプロセスのメインプログラムのベース名)。この場合は、環境変数 SUN_PROFDATA および SUN_PROFDATA_DIR を使用して、実行時にプロファイルデータが保存される場所を制御できます。設定する場合、プロファイルデータは $SUN_PROFDATA_DIR/$SUN_PROFDATA で指定されたディレクトリに書き込まれます。プロファイルディレクトリ名がコンパイル時に指定されても、実行時に SUN_PROFDATA_DIR および SUN_PROFDATA の効果はありません。これらの環境変数は、tcov で書き込まれるプロファイルデータファイルのパスと名前を同様に制御します (tcov(1) マニュアルページを参照)。
これらの環境変数が設定されていない場合、プロファイルデータは現在のディレクトリの profdir .profile ディレクトリに書き込まれます (profdir は実行可能ファイルの名前または -xprofile=collect: profdir フラグで指定された名前)。 profdir が .profile ですでに終了している場合、-xprofile では、.profile が profdir に追加されません。プログラムを複数回実行すると、実行頻度データは profdir.profile ディレクトリに蓄積されていくので、以前の実行頻度データは失われません。
別々の手順でコンパイルしてリンクする場合は、-xprofile=collect を指定してコンパイルしたオブジェクトファイルは、リンクでも必ず -xprofile=collect を指定してください。
次の例では、プログラムが構築されたディレクトリと同じディレクトリ内にある myprof.profile ディレクトリ内のプロファイルデータを収集して使用します。
demo: cc -xprofile=collect:myprof.profile -xO5 prog.c -o prog demo: ./prog demo: cc -xprofile=use:myprof.profile -xO5 prog.c -o prog
次の例では、/bench/myprof.profile ディレクトリ内のプロファイルデータを収集し、収集したプロファイルデータをあとでフィードバックコンパイルで最適化レベル -xO5 で使用します。
demo: cc -xprofile=collect:/bench/myprof.profile \ -xO5 prog.c -o prog ...run prog from multiple locations.. demo: cc -xprofile=use:/bench/myprof.profile \ -xO5 prog.c -o prog
プロファイリングされたコードが実行されたときに実行された作業のために最適化するときは、—xprofile=collect[: profdir] または —xprofile=tcov[: profdir] でコンパイルされたコードから収集された実行頻度データを使用します。profdir は、—xprofile=collect[: profdir] または —xprofile=tcov[: profdir] でコンパイルされたプログラムを実行して収集されたプロファイルデータを含むディレクトリのパス名です。
tcov と —xprofile=use[:profdir] の両方で使用できるデータを生成するには、 —xprofile=tcov[:profdir] オプションを使用して、コンパイル時にプロファイルディレクトリを指定する必要があります。—xprofile=tcov: profdir と —xprofile=use: profdir の両方で同じプロファイルディレクトリを指定する必要があります。混乱を最小限に抑えるには、profdir を絶対パス名として指定します。
profdir パス名はオプションです。profdir が指定されていない場合、実行可能バイナリの名前が使用されます。-o が指定されていない場合、a.out が使用されます。 profdir が指定されていない場合、コンパイラは、profdir .profile/feedback、または a.out.profile/feedback を探します。例:
demo: cc -xprofile=collect -o myexe prog.c demo: cc -xprofile=use:myexe -xO5 -o myexe prog.c
-xprofile=collect オプションを付けてコンパイルしたときに生成され、プログラムの前の実行で作成されたフィードバックファイルに保存された実行頻度データを使用して、プログラムが最適化されます。
-xprofile オプションを除き、ソースファイルおよびコンパイラのほかのオプションは、フィードバックファイルを生成したコンパイル済みプログラムのコンパイルに使用したものと完全に同一のものを指定する必要があります。同じバージョンのコンパイラは、collect 構築と use 構築の両方に使用する必要があります。
-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 で指定されているディレクトリには、プロファイル化されたプログラムを実行するときにすべてのマシンからアクセスできる必要があります。プロファイルディレクトリはその内容が必要なくなるまで削除できません。コンパイラでプロファイルディレクトリに保存されたデータは、再コンパイルする以外復元できません。
例 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.c t2.c example% a.out // run collects feedback data example% cc -xO5 -xprofile=use -xprofile_ircache t1.c t2.c
(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 が指定する場合のみ有効です。それ以外の場合は、コンパイラは警告を発行します。
縮約の認識が有効になっている場合、コンパイラは内積、最大値発見、最小値発見などの縮約を並列化します。これらの縮約によって非並列化コードによる四捨五入の結果と異なります。
『Oracle Solaris Studio OpenMP API ユーザーズガイド』も参照してください。
r には、appl、float、frameptr サブオプションのいずれか 1 つ以上をコンマで区切って指定します。
サブオプションの前に no% を付けるとそのサブオプションは無効になります。
—xregs サブオプションは、特定のハードウェアプラットフォームでしか使用できません。
例: -xregs=appl,no%float
|
SPARC のデフォルトは -xregs=appl,float です。
x86 のデフォルトは -xregs=no%frameptr,float です。
x86 システムでは、-xpg は -xregs=frameptr と互換性がありません。これら 2 つのオプションを一緒に使用しないでください。-xregs=frameptr は -fast に含まれている点にも注意してください。
アプリケーションにリンクする共有ライブラリ用に意図したコードは、-xregs=no%appl,float を指定してコンパイルしてください。少なくとも、共有ライブラリとリンクするアプリケーションがこれらのレジスタの割り当てを認識するように、共有ライブラリがアプリケーションレジスタを使用する方法を明示的に示す必要があります。
たとえば、大局的な方法でレジスタを使用する (重要なデータ構造体を指し示すためにレジスタを使用するなど) アプリケーションは、ライブラリと安全にリンクするため、-xregs=no%appl なしでコンパイルされたコードを含むライブラリがアプリケーションレジスタをどのように使用するかを認識する必要があります。
ポインタ値の関数パラメータを制限付きポインタとして扱います。f は、%all、%none、あるいは 1 つまたは複数の関数名のコンマ区切りリストです: {%all| %none|fn[,fn...]}。
このオプションとともに関数リストを指定する場合は、指定した関数内のポインタパラメータが制限付きとして扱われます。-xrestrict=%all を指定する場合は、C ファイル全体のすべてのポインタパラメータが制限付きとして扱われます。詳細は、制限付きポインタを参照してください。
このコマンド行オプションは独立して使用できますが、最適化時に使用するのがもっとも適しています。たとえば、このコマンドは、ファイル prog.c 内のすべてのポインタパラメータを制限付きポインタとして扱います。
%cc -xO3 -xrestrict=%all prog.c
このコマンドは、ファイル prog.c 内の関数 agc 内のすべてのポインタパラメータを制限付きポインタとして扱います。
%cc -xO3 -xrestrict=agc prog.c
デフォルトは %none です。-xrestrict を指定することは、-xrestrict=%all を指定することと同義です。
(Oracle Solaris) オブジェクトファイルからのデバッグ情報を実行可能ファイルにリンクします。
-xs は -xs=yes と同じです。
-xdebugformat=dwarf のデフォルトは -xs=yes と同じです。
-xdebugformat=stabs のデフォルトは -xs=no と同じです。
このオプションは、実行可能ファイルのサイズ、およびデバッグのためにオブジェクトファイルを保持する必要性のトレードオフを制御します。dwarf の場合は、-xs=no を使用して実行可能ファイルを小さくしますが、オブジェクトファイルに依存しています。stabs の場合は、-xs または -xs=yes を使用してオブジェクトファイルに依存しないようにしますが、実行可能ファイルが大きくなります。このオプションは、dbx のパフォーマンスやプログラムの実行時パフォーマンスにはほとんど影響しません。
コンパイルコマンドがリンクを強制した (つまり、-c を指定しない) 場合、オブジェクトファイルはなく、デバッグ情報を実行可能ファイルに含める必要があります。この場合、-xs=no (暗黙的または明示的) は無視されます。
この機能は、コンパイラが生成されるオブジェクトファイル内のセクションフラグおよびセクション名を調整し、リンカーにそのオブジェクトファイルのデバッグ情報に関する処理を指示することによって実装されます。このため、これはコンパイラオプションであり、リンカーオプションではありません。一部のオブジェクトファイルが -xs=yes でコンパイルされ、ほかのオブジェクトファイルが -xs=no でコンパイルされた実行可能ファイルを作成することが可能です。
Linux コンパイラは -xs を受け入れますが無視します。Linux コンパイラは -xs={yes|no} を受け入れません。
(SPARC) コンパイラが記憶域保護違反が発生した場合を前提とできるようにします。
このオプションを使用すると、コンパイラでは SPARC V9 アーキテクチャーで違反のないロード命令を使用できます。
このオプションは、最適化レベルの –xO5 と、次のいずれかの値の –xarch を組み合わせた場合にだけ有効です: m32 と m64 の両方で sparc、sparcvis、–sparcvis2、または –sparcvis3。
(Oracle Solaris) このオプションを指定すると、ドライバはリンク行で特殊なマップファイルをインクルードします。マップファイルはテキスト、データ、および bss セグメントを、n で指定された値に整列します。非常に大きなページを使用する場合は、ヒープセグメントおよびスタックセグメントが適切な境界に整列されることが重要です。これらのセグメントが整列されない場合、次の境界まで小さなページが使用され、この結果、パフォーマンスが低下することがあります。マップファイルにより、セグメントは確実に適切な境界上に整列されます。
n の値は次のいずれかである必要があります。
SPARC: 有効な値は、8K、64K、512K、2M、4M、32M、256M、1G、および none です。
x86: 有効な値は、4K、8K、64K、512K、2M、4M、32M、256M、1G、および none です。
SPARC と x86 のデフォルトはどちらも none です。
推奨の使用法は次のとおりです。
SPARC 32-bit compilation: -xsegment_align=64K SPARC 64-bit compilation: -xsegment_align=4M x86 32-bit compilation: -xsegment_align=8K x86 64-bit compilation: -xsegment_align=4M
ドライバは適切なマップファイルをインクルードします。たとえば、ユーザーが -xsegment_align=4M と指定した場合、ドライバは -Minstall-directory/lib/compilers/mapfiles/map.4M.align をリンク行に追加します。install-directory はインストールディレクトリです。前述のセグメントは、4M 境界上に整列されます。
接尾辞のない浮動小数点定数を、デフォルトの倍精度モードではなく、単精度として表します。-pedantic とともに指定した場合は無効となります。
例: コードサイズが増える場合は、ループの展開や並列化は行われません。
このオプションは非推奨であり、将来のリリースで削除される可能性があります。 —xstrconst は —features=conststrings の別名です。
t の値は、native、generic、native64、generic64、または system-name のいずれかである必要があります。
-xtarget に指定する値は、-xarch、-xchip、-xcache の各オプションの値に展開されます。実行中のシステムで -xtarget=native の展開を調べるには、-xdryrun コマンドを使用します。
たとえば、-xtarget=ultra4 は -xchip=ultra4 -xcache=64/32/4:8192/128/2 -xarch=sparcvis2 と同義です。
|
対象となるハードウェア (コンピュータ) の正式な名前をコンパイラに指定した方がパフォーマンスが優れているプログラムもあります。プログラムパフォーマンスがクリティカルな場合、ターゲットハードウェアの適切な指定は、より新しい SPARC プロセッサ上での実行時は特に、非常に重要である可能性があります。しかし、ほとんどのプログラムおよび旧式の SPARC システムではパフォーマンスの向上はわずかであるため、汎用的な指定方法で十分です。
SPARC または UltraSPARC V9 で 64 ビット Oracle Solaris ソフトウェアをコンパイルすることは、–m64 オプションで示されます。–xtarget を native64 または generic64 以外のフラグとともに指定する場合は、–xtarget=ultra ... –m64 のように、–m64 オプションも指定する必要があります。そうでない場合は、コンパイラは 32 ビットメモリーモデルを使用します。
|
64 ビット x86 プラットフォームで 64 ビット Oracle Solaris ソフトウェアをコンパイルすることは、–m64 オプションで示されます。–xtarget を native64 または generic64 以外のフラグとともに指定する場合は、次のように–m64 オプションも指定する必要があります。
–xtarget=opteron ... –m64
そうでない場合は、コンパイラは 32 ビットメモリーモデルを使用します。
|
スレッドローカルな変数の実装を制御するには -xthreadvar を指定します。コンパイラのスレッドローカルな記憶領域機能を利用するには、このオプションを __thread 宣言指定子と組み合わせて使用します。__thread 指定子を使用してスレッド変数を宣言したあとは、-xthreadvar を指定して動的 (共有) ライブラリの位置に依存しないコード (PIC 以外のコード) でスレッド固有の記憶領域を使用できるようにします。__thread の使用方法についての詳細は、スレッドローカルな記憶領域指示子を参照してください。
o は dynamic または no%dynamic である必要があります。
|
-xthreadvar を指定しない場合、コンパイラが使用するデフォルトは位置独立コード (PIC) が有効になっているかどうかによって決まります。位置独立コードが有効になっている場合、オプションは -xthreadvar=dynamic に設定されます。位置独立コードが無効になっている場合、オプションは -xthreadvar=no%dynamic に設定されます。
-xthreadvar を指定するけれども値を指定しない場合は、オプションは -xthreadvar=dynamic に設定されます。
位置独立ではないコードが動的ライブラリに含まれる場合、-xthreadvar を指定する必要があります。
リンカーは、動的ライブラリ内の位置依存コード (非 PIC) スレッド変数と同等のスレッド変数はサポートできません。PIC でないスレッド変数は非常に高速なため、実行可能ファイルのデフォルトにするべきです。
-xcode、-KPIC、および -Kpic の説明も参照してください。
-xthroughput オプションは、システム上で多数のプロセスが同時に実行されている状況でアプリケーションが実行されることをコンパイラに示します。
-xthroughput=yes を指定すると、コンパイラは、単一のプロセスのパフォーマンスは若干低下するが、システム上のすべてのプロセスによって実行される作業量が増加するように最適化を行います。たとえば、コンパイラがデータの先読みの積極性を下げることを選択する可能性があります。そのように選択すると、そのプロセスによって消費されるメモリー帯域幅が減少し、プロセスの実行が遅くなることがありますが、ほかのプロセスが共有するメモリー帯域幅が増加します。
デフォルトは -xthroughput=no です。
コンパイルの各コンポーネントが占有した実行時間とリソースを報告します。
K&R C と Solaris Studio ISO C との間の相違について警告を発行します。
-xtransition オプションを、-Xa または -Xt オプションとともに使用すると警告を出します。異なる動作に関するすべての警告メッセージは適切なコーディングを行うことによって取り除くことができます。次の警告は、-xtransition オプションを使用していなければ表示されません。
\a は ISO C の「警告」文字です
\x は ISO C の 16 進エスケープです
無効な 8 進数
型の種類は実際には type tag です: name
コメントが "##" で置き換えられます
コメントがトークンを連結していません
ISO C では新しい型で置き換えてしまう型の宣言です: type tag
文字定数中のマクロ置換
文字列リテラル中のマクロ置換
文字定数中のマクロ置換は行われません
文字列リテラル中のマクロ置換は行われません
オペランドが符号なしとして処理されました
3 文字表記シーケンスが置き換えられました
ISO C は定数を unsigned 型として扱います: operator
ISO C では operator の意味が変わります。明示的なキャストを使用してください。
-xtrigraphs オプションは、コンパイラが ISO C 規格で定義されている 3 文字表記シーケンスを認識するかどうかを決定します。
デフォルトにより、コンパイラは -xtrigraphs=yes を仮定し、コンパイル単位をとおしてすべての三文字表記シーケンスを認識します。
コンパイラが 3 文字表記シーケンスとして解釈している疑問符 (?) が含まれるリテラル文字列がソースコードにある場合は、-xtrigraph=no サブオプションを使用して 3 文字表記シーケンスの認識を無効にできます。-xtrigraphs=no オプションは、コンパイル単位全体ですべての 3 文字表記シーケンスの認識を無効にします。
次の例は、ソースファイル trigraphs_demo.c を示しています。
#include <stdio.h>
int main ()
{
(void) printf("(\?\?) in a string appears as (??)\n");
return 0;
}
次の例は、-xtrigraphs=yes を指定してこのコードをコンパイルする場合の出力を示します。
example% cc -xtrigraphs=yes trigraphs_demo.c example% a.out (??) in a string appears as (]
次の例は、-xtrigraphs=no を指定してこのコードをコンパイルする場合の出力を示します。
example% cc -xtrigraphs=no trigraphs_demo.c example% a.out (??) in a string appears as (??)
動的に結合されたシンボルへの参照がプログラムに含まれているかどうかを指定します。
-xunboundsym=yes は、動的に結合されたシンボルへの参照がプログラムに含まれていることを意味します。
-xunboundsym=no は、動的に結合されているシンボルへの参照がプログラムに含まれていないことを意味します。
デフォルトは -xunboundsym=no です。
ループを n 回展開するようオプティマイザに指示します。n は正の整数です。n が 1 のとき、ループを展開しないようコンパイラに要求します。n が 1 より大きいとき、-xunroll=n は、該当する場合にループを n 回展開することをコンパイラに推奨します。
ISO10646 UTF-16 文字列リテラルを使用する国際化アプリケーションをサポートする必要がある場合は、このオプション使用します。言い替えれば、このオプションは、オブジェクトファイル内で UTF-16 文字列に変換したい文字列リテラルがコードに含まれる場合に使用します。このオプションがない場合、コンパイラは 16 ビット文字列リテラルを生成も認識もしません。このオプションは、U"ASCII_string" 文字列リテラルを unsigned short int 型の配列として認識できるようにします。このような文字列はまだ標準の一部ではないので、このオプションは標準でない C の認識を有効にします。
U"ASCII_string" 文字列リテラルのコンパイラによる認識を無効にすることができます。-xustr=noこのオプションのコマンド行の右端にあるインスタンスは、それまでのインスタンスをすべてオーバーライドします。
デフォルトは -xustr=no です。引数を指定しないで -xustr を指定した場合、コンパイラはこの指定を受け付けず、警告を発行します。C または C++ 規格で構文の意味が定義されると、デフォルト値が変わることがあります。
-xustr=ascii_ustf16_ushort は、U"ASCII_string" 文字列リテラルを一緒に指定しなくても指定できます。
-std=c11 (デフォルトを含む) が有効である場合、フラグ -xustr=ascii_utf16_ushort を指定するとエラーになります。-xustr=ascii_utf16_ushort を指定した場合は、-Xc、-Xa、-Xt、-Xs、-xc99、-std=c99、-std=c89、または -ansi のいずれかも指定する必要があります。
すべてのファイルを、このオプションによってコンパイルしなければならないわけではありません。
次の例では、前に U が付いた引用符内の文字列リテラルを示します。-xustr を指定するコマンド行も示します。
example% cat file.c
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.c -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) をサポートする x86 プロセッサで、ベクトルライブラリ関数への呼び出しの自動生成や、SIMD 命令の生成を有効にします。このオプションを使用するときは -fround=nearest を指定することによって、デフォルトの丸めモードを使用する必要があります。
次の表は、a の値の一覧です。no% 接頭辞は関連付けられたサブオプションを無効にします。
|
デフォルトは、x86 では -xvector=simd で、SPARC プラットフォームでは -xvector=%none です。サブオプションなしで -xvector を指定すると、コンパイラは x86 Solaris では -xvector=simd,lib、SPARC Solaris では -xvector=lib、Linux プラットフォームでは -xvector=simd と想定します。
-xvector オプションを指定するには、最適化レベルが -xO3 かそれ以上に設定されていることが必要です。最適化レベルが指定されていない場合や —xO3 よりも低い場合はコンパイルは続行されず、メッセージが表示されます。
コンパイラは、リンク時に libmvec ライブラリを取り込みます。別々の手順でコンパイルおよびリンクする場合は、同じ -xvector オプションを両方のコマンドで使用します。
(SPARC) -xvis=[yes|no] コマンドは、vis.h ヘッダーを使用して VIS 命令を生成するときや、VIS 命令を使用するアセンブラインラインコード (.il) を使用するときに使用します。デフォルトは -xvis=no です。-xvis と指定すると -xvis=yes と指定した場合と同様の結果が得られます。
VIS 命令セットは、SPARC-V9 命令セットの拡張機能です。UltraSPARC プロセッサが 64 ビットの場合でも、多くの場合、特にマルチメディアアプリケーションではデータサイズが 8 ビットまたは 16 ビットに制限されています。VIS 命令は 1 つの命令で 4 つの 16 ビットデータを処理できるので、画像、線形代数、信号処理、オーディオ、ビデオ、ネットワーキングなどの新しいメディアを扱うアプリケーションのパフォーマンスが大幅に向上させます。
OpenMP を使用するときに正しくない結果をもたらす可能性のある、並列プログラミングに関連する潜在的な問題に関して、警告を発行します。-xopenmp および OpenMP API 指令とともに使用します。
次の状況が検出された場合は、コンパイラは警告を発行します。
異なるループ繰り返し間でデータに依存関係がある場合に、MP 指令を使用して並列化されたループ。
OpenMP データ共有属性節に問題がある場合。たとえば、変数「shared」を宣言するとき (OpenMP 並列領域でのアクセスがデータ競合を招く可能性がある) や、変数「private」を宣言するとき (並列領域内のその値が並列領域のあとで使用される) です。
すべての並列化命令が問題なく処理される場合、警告は表示されません。
例:
cc -xopenmp -vpara any.c
コンポーネント c の場所として新しい dir を指定します。c は -W オプションで示したコンポーネントを表す文字です。
コンポーネントの検索が指定されている場合、ツールのパス名は dir/tool になります。2 つ以上の -Y オプションが 1 つの項目に適用されている場合には、最後に指定されたものが有効です。
コンパイラのすべてのコンポーネントの検索場所にするディレクトリ dir を指定します。dir 内でコンポーネントが見つからない場合は、コンパイラがインストールされているディレクトリに戻って検索されます。
include ファイルを検索するデフォルトディレクトリを変更します。
ライブラリファイルを検索するデフォルトのディレクトリを変更します。
起動用のオブジェクトファイルのデフォルトのディレクトリを変更します。
(SPARC) lock_lint 用にプログラムデータベースを作成しますが、実行可能コードは生成しません。詳細は、lock_lint(1) のマニュアルページを参照してください。
cc は -a、-e、-r、-t、-u、-z を認識し、これらのオプションとその引数を ld に渡します。cc は認識できないオプションを警告付きで ld に渡します。Oracle Solaris プラットフォームでは、-i オプションとその引数もリンカーに渡されます。
これらのデフォルトコンパイラオプションファイルは、ユーザーがすべてのコンパイルに適用される (ほかの方法で上書きされる場合を除く)、一連のデフォルトオプションを指定することを許可します。たとえば、ファイルによって、すべてのコンパイルのデフォルトを —xO2 としたり、またはファイル setup.il を自動的に含めたりするように指定できます。
コンパイラは起動時に、すべてのコンパイルに含めるべきデフォルトオプションがリストされているデフォルトオプションファイルを検索します。環境変数 SPRO_DEFAULTS_PATH は、デフォルトファイルを検索するディレクトリのコロン区切りリストを指定します。
環境変数が設定されていない場合、標準のデフォルトセットが使用されます。環境変数が設定されているが空の場合、デフォルトは使用されません。
デフォルトのファイル名は compiler.defaults の形式である必要があり、ここで、コンパイラは cc、c89、c99、CC、ftn、または lint のいずれかです。たとえば、C コンパイラ用のデフォルトは cc.defaults です。
SPRO_DEFAULTS_PATH にリストされたディレクトリにコンパイラ用のデフォルトファイルが見つかった場合、コンパイラはファイルを読み取り、コマンド行でオプションを処理する前にオプションを処理します。最初に見つかったデフォルトファイルが使用され、検索は終了します。
システム管理者は、システム全体のデフォルトファイルを Studio-install-path/lib/compilers/etc/config に作成できます。環境変数が設定されている場合、インストールされたデフォルトファイルは読み取られません。
デフォルトファイルの形式はコマンド行と同様です。ファイルの各行には、1 つ以上のコンパイラオプションを空白で区切って含めてもかまいません。ワイルドカードや置換などのシェル展開は、デフォルトファイル内のオプションには適用されません。
—#、—###、および —dryrun の各オプションによって生成される詳細出力では、SPRO_DEFAULTS_PATH の値と、完全展開されたコマンド行が表示されます。
ユーザーによってコマンド行で指定されたオプションは、通常、デフォルトファイルから読み取られたオプションをオーバーライドします。たとえば、—xO4 でのコンパイルがデフォルトファイルで指定されており、ユーザーがコマンド行で —xO2 を指定した場合、—xO2 が使用されます。
デフォルトオプションファイルに記載されているオプションの一部は、コマンド行で指定されたオプションのあとに付加されます。これらは、プリプロセッサオプション —I、リンカーオプション —B、—L、—R、 —l、および、ソースファイル、オブジェクトファイル、アーカイブ、共有オブジェクトなどのすべてのファイル引数です。
次に示すのは、ユーザー指定のデフォルトコンパイラオプション起動ファイルがどのように使用される可能性があるかの例です。
demo% cat /project/defaults/cc.defaults -I/project/src/hdrs —L/project/libs —llibproj —xvpara demo% setenv SPRO_DEFAULTS_PATH /project/defaults demo% cc —c —I/local/hdrs —L/local/libs —lliblocal tst.c
現在、このコマンドは次と同義です。
cc -fast —xvpara —c —I/local/hdrs —L/local/libs —lliblocal tst.c \
—I/project/src/hdrs —L/project/libs —llibprojコンパイラデフォルトファイルはプロジェクト全体のデフォルトを設定するための便利な方法ですが、問題の診断を困難にする原因になる場合もあります。このような問題を回避するには、環境変数 SPRO_DEFAULTS_PATH を現在のディレクトリではなく絶対パスに設定します。
デフォルトオプションファイルのインタフェース安定性はコミットされていません。オプション処理の順序は、将来のリリースで変更される可能性があります。