| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris Studio 12.3: C ユーザーガイド Oracle Solaris Studio 12.3 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Oracle Solaris Studio 12.3: C ユーザーガイド Oracle Solaris Studio 12.3 Information Library (日本語) |
B.2.7 -Dname[(arg[,arg])][=expasion]
B.2.59 -Qoption phase option[,option..]
B.2.65 -traceback[={ %none|common|signals_list}]
B.2.79.1 SPARC および x86 用の -xarch フラグ
B.2.81 -xbinopt={prepare| off}
B.2.82 -xbuiltin[=( %all|%default|%none)]
B.2.89.1 -xcheck=init_local の初期化値
B.2.94 -xdebugformat=[stabs|dwarf ]
B.2.97 -xdumpmacros[= value[,value...]]
B.2.103 -xinstrument=[ no%]datarace
B.2.104.2 -xipo=2 による内部手続き解析を行うべきでないケース
B.2.108 -xkeepframe[=[ %all,%none,name,no% name]]
B.2.136.1 プリコンパイル済みヘッダーファイルの自動作成
B.2.136.2 プリコンパイル済みヘッダーファイルの手動作成
B.2.136.3 既存のプリコンパイル済みヘッダーファイルの処理方法
B.2.136.4 特定のプリコンパイル済みヘッダーファイルの使用の指定
B.2.136.5 活性文字列 (Viable Prefix)
B.2.136.7 プリコンパイル済みヘッダーファイルキャッシュ
B.2.136.9 プリコンパイル済みヘッダーファイルの依存関係と make ファイル
B.2.137 -xpchstop=[file |<include>]
B.2.141 -xprefetch[= val[,val]]
B.2.142 -xprefetch_auto_type= a
B.2.145 -xprofile_ircache[ =path]
B.2.155.1 SPARC プラットフォームの -xtarget の値
B.2.155.2 x86 プラットフォームの -xtarget の値
B.2.160 -xtrigraphs[={ yes|no}]
この節では、cc オプションについてアルファベット順に説明します。これらの説明は cc(1) のマニュアルページでも見ることができます。1 行に要約した説明が必要な場合は、cc -flags オプションを使用してください。
特定のプラットフォームに固有と表記されたオプションを別のプラットフォームで使用してもエラーは起きません。単に無視されます。
冗長モードを有効にします。コマンドオプションがどのように展開されるかが表示されます。要素が呼び出されるごとにその要素を表示します。
呼び出された各構成要素が表示されますが、実行はされません。また、コマンドオプションの展開内容を表示します。
#assert 前処理指令に似せて、指定の tokens を使用し name を述語として関連付けます。事前表明 (preassertion) は次のとおりです。
system(unix)
machine(sparc) (SPARC)
machine(i386) (x86)
cpu(sparc) (SPARC)
cpu(i386) (x86)
-Xc モードの場合、これらの事前表明は有効になりません。
-A のあとにハイフン (-) だけが続く場合は、事前定義のマクロ (__ から始まるもの以外) および事前定義の表明はすべて無視されます。
リンク時に結合するライブラリを静的と動的のどちらにするかを指定します。static (静的) と指定するとライブラリが非共有ライブラリであることを示し、dynamic (動的) と指定すると共有ライブラリであることを示します。
-Bdynamic を指定すると、-lx オプションが指定されていれば、リンカーは libx.so というファイルを探し、次に libx.a というファイルを探します。
-Bstatic を指定すると、リンカーは libx.a というファイルだけを探します。このオプションは、コマンド行中で何度も指定して、切り替えることができます。このオプションと引数は ld(1) に渡されます。
注 - Oracle Solaris 64 ビットコンパイル環境では、多くのシステムライブラリ (libc など) は、動的ライブラリとしてのみ使用できます。このため、コマンド行の最後に -Bstatic を使用しないでください。
このオプションと引数はリンカーに渡されます。
C プリプロセッサがコメントを削除しないようにします。ただし前処理指令の行にあるコメントは削除されます。
C コンパイラ ld(1) によるリンクを行わず、ソースファイルごとに o ファイルを作成します。-o オプションを使用すると、1 つのオブジェクトファイルを明示的に指定することができます。コンパイラが .i または .c の各入力ファイルに対応するオブジェクトコードを生成する場合は、現在の作業ディレクトリにオブジェクト (.o) ファイルを作成します。リンクを行わないと、オブジェクトファイルの削除も行われません。
#define 前処理マクロが指令によって定義されるのと同様に、オプションの引数を使用してマクロを定義します。=expansion が指定されていない場合は、コンパイラは 1 であると仮定します。
コンパイラの定義済みマクロのリストについては、cc(1) のマニュアルページを参照してください。
-dy はリンクエディタに動的なリンクを指定します (デフォルト)。
-dn はリンクエディタに静的なリンクを指定します。
このオプションとその引数は ld(1) に渡されます。
注 - このオプションを動的ライブラリと組み合わせて使用すると、重大なエラーが発生します。ほとんどのシステムライブラリは、動的ライブラリでのみ使用できます。
(SPARC) 廃止。このオプションは使わないでください。代わりに -xmemalign=8s を使用してください。詳細は、「B.2.124 -xmemalign=ab」を参照してください。「A.1.14 廃止オプション」に、廃止のオプションの全一覧をまとめています。x86 プラットフォームでは、このオプションはメッセージを表示せずに無視されます。
プリプロセッサのみでソースファイルを処理し、出力を stdout に送ります。プリプロセッサはコンパイラ内部に直接組み込まれます。/usr/ccs/lib/cpp が直接呼び出される -Xs モードの場合は除きます。プリプロセッサの行番号付け情報も含みます。-P オプションの説明も参照してください。
このオプションは、エラーメッセージの最初に「error:」という接頭辞を追加して、警告メッセージと区別しやすくする場合に使用します。接頭辞は、-errwarn によってエラーに変換された警告にも追加されます。
表 B-1 -errfmt のフラグ
|
このオプションを指定しない場合は、-errfmt=no%errorに設定されます。-errfmt を指定したけれども値を指定しない場合、コンパイラはそれを -errfmt=error に指定します。
ヘッダーファイルからの警告を、次の表のフラグによって示されるヘッダーファイルのグループに限定します。
表 B-2 —errhdr オプション
|
このコマンドは、C コンパイラの警告メッセージを無効にします。エラーメッセージには影響しません。このオプションは、-errwarn によってゼロ以外の終了状態を発生させるように指定されているかどうかにかかわらず、すべての警告メッセージに適用されます。
t には、次の 1 つまたは複数の項目をコンマで区切って指定します。tag、no%tag、 %all、%none。指定順序によって実行内容が異なります。たとえば、「%all,no%tag」と指定すると、tag 以外のすべての警告メッセージを抑制します。次の表は、-erroff の値を示しています。
表 B-3 -erroff のフラグ
|
デフォルトは -erroff=%none です。-erroff と指定すると、-erroff=%all を指定した場合と同じ結果が得られます。
-erroff オプションで無効にできるのは、C コンパイラのフロントエンドで -errtags オプションを指定したときにタグを表示する警告メッセージだけです。無効にするエラーメッセージをさらに詳細に設定することができます。「2.11.8 error_messages」を参照してください。
このオプションは、コンパイラで型の不一致が検出されたときに生成されるエラーメッセージの詳細さを設定する場合に使用します。大きな集合体が関係する型の不一致がコンパイラで検出される場合にこのオプションを使用すると特に便利です。
i は、次の表に示す値のいずれかです。
表 B-4 -errshort のフラグ
|
-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 の値を次の表に示します。
表 B-5 -errwarn のフラグ
|
デフォルトは -errwarn=%none です。-errwarn だけを指定することは、-errwarn=%all と同義です。
このオプションは、実行可能ファイルをチューニングして実行時パフォーマンスを最大化するための出発点として効果的に使用できるマクロです。-fast オプションマクロは、コンパイラのあるリリースから次の変更される可能性があり、ターゲットプラットフォーム固有のオプションに展開されます。-# オプションまたは -xdryrun を使用して -fast の展開を調べ、-fast の該当するオプションを使用して実行可能ファイルのチューニングを行なってください。
-fast の展開には、コンパイラが最適化された数学ルーチンのライブラリを使用できるようにする -xlibmopt オプションが含まれます。詳細は、「B.2.112 -xlibmopt」を参照してください。
-fast オプションは、errno の値に影響します。詳細は、「2.13 errno の値の保持」を参照してください。
-fast を指定してコンパイルしたモジュールは、-fast を指定してリンクする必要があります。「A.1.2 コンパイル時とリンク時のオプション」に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。
-fast オプションは、特にコンパイルするマシンとは異なるターゲットで実行するプログラムでは使用できません。そのような場合は、-fast のあとに適切な -xtarget オプションを指定します。例:
cc -fast -xtarget=generic ...
SUID によって規定された例外処理に依存する C モジュールに対しては、-fast のあとに -xnolibmil を指定します。
% cc -fast -xnolibmil
-xlibmil を使用すると、例外発生時でも errno が設定されず、また、matherr(3m) が呼び出されません。
-fast オプションは、厳密な IEEE 754 規格準拠を必要とするプログラムには適していません。
次に、-fast により指定されるオプションをプラットフォームごとに示します。
表 B-6 -fast 展開フラグ
|
注 - 一部の最適化では、プログラムの動作が特定の動作になることを想定しています。プログラムがこれらの想定に適合していない場合は、アプリケーションがエラーが発生したり、誤った結果を生成したりすることがあります。プログラムが -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 ###
表 B-7 -features のフラグ
|
古い 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) このオプションは、浮動小数点式の評価方法の制御に使用します。
表 B-8 -flteval のフラグ
|
-flteval が指定されない場合は、-flteval=any に設定されます。-flteval を指定したけれども値を指定しない場合、コンパイラはそれを -flteval=2 に設定します。
-flteval=2 は -xarch=sse、 pentium_pro、ssea、または pentium_proa と一緒でのみ使用できます。-flteval=2 は、-fprecision または -nofstore オプションとの組み合わせでも互換性がありません。
「D.1.1 浮動小数点評価における精度」も参照してください。
(SPARC) 浮動小数点、FMA (fused, multiply-add) 命令の自動生成を有効にします。-fma=none は、これらの命令の生成を無効にします。-fma=fused は、コンパイラが浮動小数点、FMA (fused, multiply-add) 命令を使用してコードのパフォーマンスを改善する機会を見出そうとすることを許可します。
デフォルトは -fma=none です。
コンパイラが積和演算 (FMA) 命令を生成するための最小要件は、-xarch=sparcfmaf と、最適化レベルが -xO2 以上であることです。積和演算 (FMA) 命令をサポートしていないプラットフォームでプログラムが 実行されないようにするため、コンパイラは積和演算 (FMA) 命令を生成する場合、バイナリプログラムにマーク付けをします。
積和演算 (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 システムでは、このオプションはメインプログラムのコンパイル時に使用される場合にのみ有効です。
-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 のいずれかにしなければいけません。
表 B-9 -fsimple のフラグ
|
-fsimple=2 を指定しても、そうでない場合は何も生成しないプログラムで、オプティマイザが浮動小数点例外を発生させることは許可されません。
最適化が精度に与える影響の詳細は、『Techniques for Optimizing Applications: High Performance Computing』(Rajat Garg と Ilya Sharapov 著) をお読みください。
-Xt モードまたは -Xs モードの場合にかぎり、float 式を倍精度ではなく単精度で評価します。-Xa モードまたは -Xc モードでコンパイラが使用される場合、float 式はすでに単精度として評価されているため、このオプションは効果がありません。
(x86) 浮動小数点式または関数が、ある変数に代入されるか、より小さい型の浮動小数点にキャストされる場合に、コンパイラがその値をレジスタに残さないで、代入値の左側に表記される型に変換するようにします。丸めや切り上げによって、結果はレジスタの値から生成されるものと異なる可能性があります。これは、デフォルトのモードです。
このオプションを無効にするには、-nofstore フラグを使用します。
SIGFPE ハンドラを組み込まずに、起動時に有効にする IEEE トラップモードの設定のみ行います。トラップの設定と SIGFPE ハンドラの組み込みを同時に行うには、ieee_handler(3M) か fex_set_handling(3M) を使用します。複数の値を指定すると、それらの値は左から右に処理されます。
t には、次の表に示す値のいずれかにできます。
表 B-10 -ftrap のフラグ
|
例に示すように、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 オブジェクトファイルも、「B.2.91 -xcode[= v]」で説明するように、明示的な -xcode 値付きでコンパイルする必要があります。
dbx(1) とパフォーマンスアナライザ analyzer(1) によるデバッグのために、追加のシンボルテーブル情報を生成します。
-xO3 以下の最適化レベルで -g を指定すると、ほとんど完全な最適化と可能なかぎりのシンボル情報を取得することができます。末尾呼び出しの最適化とバックエンドのインライン化は無効です。
-xO4 以下の最適化レベルで -g を指定すると、完全な最適化と可能なかぎりのシンボル情報が得られます。
-g オプションでコンパイルすると、パフォーマンスアナライザの機能をフルに利用できます。 一部のパフォーマンス分析機能は -g を必要としませんが、注釈付きのソースコード、一部の関数レベルの情報、およびコンパイラの注釈メッセージを確認するには、-g でコンパイルする必要があります。詳細は、analyzer(1) のマニュアルページおよび『プログラムのパフォーマンス解析』のマニュアルを参照してください。
-g オプションで生成される注釈メッセージは、プログラムのコンパイル時にコンパイラが実行した最適化と変換について説明します。メッセージを表示するには、er_src(1) コマンドを使用します。これらのメッセージはソースコードでインタリーブされます。
注 - プログラムを個別の手順でコンパイルしてリンクする場合、—g オプションを一方の手順に含め、もう一方の手順から除外してもプログラムの正確さには影響しませんが、プログラムのデバッグ機能に影響します。—g (または —g0) を付けてコンパイルしないけれども、—g (または —g0) を付けてリンクされるモジュールは、デバッグのために適切に準備されません。関数 main を含むモジュールを —g オプション (または —g0 オプション) 付きでコンパイルすることは通常、デバッグのために必要です。
デバッグの詳細は、『dbx コマンドによるデバッグ』を参照してください。
—g3 オプションは —g と同じですが、追加のデバッグシンボルテーブル情報によって dbx がソースコード内のマクロの展開を表示できるようにします。この追加のシンボルテーブル情報により、—g 付きのコンパイルと比較して、結果の .o および実行可能ファイルのサイズが増える可能性があります。
現在のコンパイルでインクルードされたファイルのパス名を 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 オプションが指定された場合は、指定された順序でディレクトリが調べられます。
コンパイラの検索パターンの詳細については、「2.16.1 -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 を使用してください。
詳細は、「B.2.91 -xcode[= v]」 を参照してください。「A.1.14 廃止オプション」に、廃止のオプションの全一覧をまとめています。
(SPARC) 廃止。このオプションは使わないでください。代わりに -xcode=pic13 を使用してください。詳細は、「B.2.91 -xcode[= v]」 を参照してください。「A.1.14 廃止オプション」に、廃止のオプションの全一覧をまとめています。
(x86) 位置独立コードを生成します。このオプションは、共有ライブラリを構築するためにソースファイルをコンパイルするときに使用します。大域データへの各参照は、大域オフセットテーブルにおけるポインタの間接参照として生成されます。各関数呼び出しは、手続きリンケージテーブルを通して PC 相対アドレス指定モードで生成されます。
コンパイル中に作成される一時ファイルを自動的に削除しないで保持します。
ld(1) がライブラリを検索するディレクトリのリストに dir を付け加えます。このオプションとその引数は ld(1) に渡されます。
注 - コンパイラインストール領域 (/usr/include、/lib、または /usr/lib) を検索ディレクトリとして指定しないでください。
オブジェクトライブラリ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 を指定してリンクする必要があります。「A.1.2 コンパイル時とリンク時のオプション」に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの一覧をまとめています。
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 オプションを使ってください。詳細は、「B.2.124 -xmemalign=ab」を参照してください。「A.1.14 廃止オプション」に、廃止のオプションの全一覧をまとめています。
(SPARC) 廃止。このオプションは使わないでください。代わりに -xmemalign=2i オプションを使ってください。詳細は、「B.2.124 -xmemalign=ab」を参照してください。「A.1.14 廃止オプション」に、廃止のオプションの全一覧をまとめています。
-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 のどちらも自動的には含められません。共有ライブラリを構築する場合は、これらのライブラリを明示的にリストする必要があります。
(OpenMP 共有メモリー並列化 API を使用するための) —xopenmp オプションには、—mt=yes が自動的に含まれます。
-mt=yes を指定してコンパイルを実行し、リンクを個別の手順でリンクする場合は、コンパイル手順と同様にリンク手順でも -mt=yes オプションを使用する必要があります。-mt=yes を使用して 1 つの変換ユニットをコンパイルおよびリンクする場合は、-mt=yes を指定してプログラムのすべてのユニットをコンパイルおよびリンクする必要があります。
-mt=yes は、コンパイラのデフォルトの動作です。この動作が望ましくない場合は、-mt=no でコンパイルします。
オプション —mt は —mt=yes と同じです。
「B.2.126 -xnolib」 と、Oracle Solaris の『Multithreaded Programming Guide』および『リンカーとライブラリガイド』も参照してください。
このオプションは、-xtarget=native と同義です。
(x86) 浮動小数点式または関数が変数に代入されるか、より短い浮動小数点型にキャストされるときに、その式または関数の値を代入の左辺の型に変換しません。代わりに、値をレジスタに残します。「B.2.31 -fstore」も参照してください。
デフォルトの最適化レベルの -xO3 を使ってください。-O マクロは -xO3 に展開されます。
-xO3 最適化レベルがより高い実行時パフォーマンスを生み出します。ただし、あらゆる変数が自動的に volatile と見なされることに依存するプログラムの場合、これは不適切なことがあります。この前提を持つ典型的なプログラムは、独自の同期処理プリミティブを実装するデバイスドライバや古いマルチスレッドアプリケーションです。回避策は、-O ではなく、-xO2 でコンパイルすることです。
デフォルトの a.out ではなく、出力ファイル filename を指定します。コンパイラはソースファイルを上書きしないため、filename を入力ソースファイルと同じにできません。
filename は適切な接尾辞を持つ必要があります。—c とともに使用すると、filename はターゲット .o オブジェクトファイルを指定します。—G とともに使用すると、ターゲット .so ライブラリファイルを指定します。このオプションとその引数はリンカー ld に渡されます。
ソースファイルのプリプロセッサ処理のみを行います。.i 接尾辞の付いたファイルに結果を出力します。-E オプションと異なり、出力ファイルに C のプリプロセッサ行番号付け情報は含まれません。-E オプションも参照してください。
このオプションは廃止されました。代わりに 「B.2.140 -xpg」を使用してください。
複数のオプションを渡すには、コンマで区切って指定します。-Qopton でコンポーネントに渡されるオプションは、順序が変更されることがあります。ドライバが認識するオプションは、正しい順序に保持されます。ドライバがすでに認識しているオプションに、-Qoption は使わないでください。
phase は、次のリスト内のいずれかの値にできます。
コンパイラ
コードジェネレータ (SPARC)
プリプロセッサ (前処理系)
cc ドライバ
アセンブラ
相互手続きオプティマイザ
中間コードトランスレータ (x86)
オプティマイザ
リンクエディタ (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) に渡します。
実行時に重大エラーが発生した場合にスタックトレースを発行します。
-traceback オプションを指定すると、プログラムによって特定のシグナルが生成された場合に、実行可能ファイルで stderr へのスタックトレースが発行されて、コアダンプが実行され、終了します。複数のスレッドが 1 つのシグナルを生成すると、スタックトレースは最初のスレッドに対してのみ生成されます。
追跡表示を使用するには、リンク時に -traceback オプションをコンパイラコマンド行に追加します。このオプションはコンパイル時にも使用できますが、実行可能バイナリが生成されない場合無視されます。-traceback を -G とともに使用して共有ライブラリを作成すると、エラーが発生します。
表 B-11 -traceback オプション
|
このオプションを指定しない場合、デフォルトは -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)
定義済みシンボルのリストについては、「B.2.7 -Dname[(arg[,arg])][=expasion]」 を参照してください。
コンパイラの実行時に 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 を渡します。コンポーネントのリストについては、表 1-1 を参照してください。
引数は前の引数からコンマでのみ区切る必要があります。すべての -W 引数は、残りのコマンド行引数のあとに渡されます。コンマを引数の一部として含めるには、コンマの直前にエスケープ文字 \ (バックスラッシュ) を使用します。すべての -W arg は、通常のコマンド行引数のあとに渡されます。
たとえば、-Wa,-o,objfile は、-o と objfile をこの順番でアセンブラに渡します。また、-Wl,-I,name; を指定すると、リンク段階で動的リンカー /usr/lib/ld.so.1 のデフォルト名が無効になります。
引数がツールに渡される順序は、ほかに指定されるコマンド行オプションとの関係で、今後のコンパイラリリースで変更される可能性があります。
c に使用できる値の一覧を次の表に示します
表 B-12 -W のフラグ
|
-Wd を使用して cc のオプションを c コンパイラに渡すことはできません。
このオプションは error_messages プラグマを無効にします。
-X (大文字の X である点に注意) オプションでは ISO C に準拠する度合いを指定します。-xc99 の値により、-X オプションが適用される ISO C 規格のバージョンが異なります。-xc99 オプションは、デフォルトでは -xc99=all になっています。この場合は、1999 ISO/IEC C 規格のサブセットをサポートします。-xc99=none を指定した場合は、1990 ISO/IEC C 規格をサポートします。サポートされている 1999 ISO/IEC の機能については、表 C-6 を参照してください。ISO/IEC C と K&R C との相違点については、「G.1 libfast.a ライブラリ (SPARC)」を参照してください。
-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 = 遷移) このオプションでは、ISO C で求められる意味処理の変更を行わずに ISO C と K&R 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 を使用してください。「A.1.14 廃止オプション」に、廃止のオプションの全一覧をまとめています。
(x86) 廃止。このオプションは使わないでください。代わりに、-xchip=generic を使用してください。「A.1.14 廃止オプション」に、廃止のオプションの全一覧をまとめています。
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 を次の表のいずれかの用語で置き換えます。
表 B-13 別名明確化のレベル
ソースコードの静的分析を生成します。Oracle Solaris Studio コードアナライザを使用して表示できます。
—xanalyze=code を指定してコンパイルし、別の手順でリンクするときは、リンク手順でも —xanalyze=code を含めてください。
デフォルトは —xanalyze=no です。詳細は、Oracle Solaris Studio コードアナライザのドキュメントを参照してください。
(Solaris のみ) あとで最適化および監視ツール binopt(1)、code-analyzer(1)、discover(1)、collect(1)、および uncover(1) で使用できるバイナリを作成します。
デフォルトは -xannotate=yes です。値なしで -xannotate を指定することは、-xannotate=yes と同義です。
最適化および監視ツールを最適に使用するためには、コンパイル時とリンク時の両方で -xannotate=yes が有効である必要があります。最適化および監視ツールを使用しないときは、-xannotate=no を指定してコンパイルおよびリンクすると、バイナリとライブラリが若干小さくなります。
Linux システムでは、このオプションはありません。
対象となる命令セットアーキテクチャー (ISA) を指定します。
このオプションは、コンパイラが生成するコードを、指定した命令セットアーキテクチャーの命令だけに制限します。このオプションは、すべてのターゲットを対象とするような命令としての使用は保証しません。ただし、このオプションを使用するとバイナリプログラムの移植性に影響を与える可能性があります。
注 - 意図するメモリーモデルとして LP64 (64 ビット) または ILP32 (32 ビット) を指定するには、それぞれ -m64 または -m32 オプションを使用してください。次に示すように以前のリリースとの互換性を保つ場合を除いて、-xarch オプションでメモリーモデルを指定できなくなりました。
別々の手順でコンパイルしてリンクする場合は、両方の手順に同じ -xarch の値を指定してください。
_asm 文を指定するときや、アーキテクチャー固有の命令を使用する .il インラインテンプレートファイルを使ってコンパイルするときは、コンパイルエラーを避けるために適切な -xarch 値を指定することが必要な場合があります。
次の表は、SPARC プラットフォームと x86 プラットフォームの両方に共通する -xarch キーワードの一覧です。
表 B-14 SPARC および x86 プラットフォームに共通のフラグ
|
次の表は、SPARC プラットフォームでの -xarch キーワードの説明です。
表 B-15 SPARC プラットフォーム用の -xarch フラグ
|
また、次のことにも注意してください。
generic、sparc、sparcvis2、sparcvis3、sparcfmaf、sparcima でコンパイルされたオブジェクトライブラリファイル (.o) をリンクして、一度に実行できます。ただし、リンクされているすべての命令セットをサポートしているプロセッサでのみ実行できます。
特定の選択の場合に、生成された実行可能ファイルが実行されなかったり、従来のアーキテクチャーよりもかなり遅く実行されたりする場合があります。また、4 倍精度 (REAL*16 および long double) 浮動小数点命令は、これらの命令セットアーキテクチャーのいずれにも実装されないため、コンパイラは、そのコンパイラが生成したコードではそれらの命令を使用しません。
次の表に、x86 プラットフォームでの -xarch フラグを示します。
表 B-16 x86 での -xarch のフラグ
|
x86 プラットフォームで、プログラムの一部が —m64 を使用してコンパイルまたはリンクされる場合は、プログラムのすべての部分もこれらのオプションのいずれかを使用してコンパイルされる必要があります。各種 Intel 命令セットアーキテクチャー (SSE、SSE2、SSE3、SSSE3 など) の詳細は、Intel-64 および IA-32 の『Intel Architecture Software Developer's Manual』を参照してください。
「1.2 x86 の特記事項」および 「1.3 バイナリの互換性の妥当性検査」も参照してください。
このオプションは単体でも使用できますが、-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 の値を指定してください。
注 - このオプションは OpenMP の並列化命令を有効にしません。
マルチプロセッサ用に自動並列化を有効にします。依存性の解析 (ループの繰り返し内部でのデータ依存性の解析) およびループ再構成を実行します。最適化が -xO3 以上でない場合、最適化は -xO3 に引き上げられ、警告が出されます。
独自のスレッド管理を行なっている場合には、-xautopar を使用しないでください。
実行速度を上げるには、マルチプロセッサシステムが必要です。シングルプロセッサシステムでは、通常、生成されたバイナリの実行速度は低下します。
並列化されたプログラムをマルチスレッド環境で実行するには、実行前に環境変数 OMP_NUM_THREADS を 1 より大きな値に設定する必要があります。設定しない場合は、デフォルトは 2 です。より多くのスレッドを使用するには、OMP_NUM_THREADS をより高い値に設定します。1 つのスレッドだけで実行する場合は、OMP_NUM_THREADS を 1 に設定します。一般に、OMP_NUM_THREADS には、実行中のシステムで使用可能な仮想プロセッサ数を設定します。Oracle Solaris の psrinfo(1) コマンドを使用して判断できます。
-xautopar を使用してコンパイルとリンクを 1 度に実行する場合、リンクには自動的にマイクロタスキングライブラリおよびスレッドに対して安全な C 実行時ライブラリが含まれます。-xautopar を使用してコンパイルとリンクを別々に実行する場合、リンクにも -xautopar を指定しなければいけません。表 A-2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。
(SPARC) このオプションは廃止されており、コンパイラの将来のリリースで削除される予定です。「B.2.78 -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 の値に依存している場合、このオプションの使用は避けてください。「2.13 errno の値の保持」も参照してください。
-xbuiltin=%default は、errno を設定しない関数のみをインライン化します。errno の値はどの最適化レベルでも常に正確であり、高い信頼度でチェックできます。-xbuiltin=%default が -xO3 以下の場合、コンパイラはどの呼び出しをインライン化すると役立つかを判断し、ほかのものはインライン化しません。-xbuiltin=%none オプションは、ライブラリ関数のすべての置換を無効にします。
-xbuiltin を指定しない場合、デフォルトは、最適化レベル -xO1 以上でコンパイルするときは -xbuiltin=%default、 -xO0 のときは -xbuiltin=%none です。引数なしで -xbuiltin を指定する場合、デフォルトは -xbuiltin=%all で、コンパイラはより積極的に組み込み関数を置き換えたり、標準ライブラリ関数をインライン化したりします。
-fast を指定してコンパイルする場合は、-xbuiltin は %all になります。
注 - -xbuiltin は、システムヘッダーファイルで定義された大域関数のみをインライン化し、ユーザーが定義した静的関数はインライン化しません。
-xc99=none および -xCC を指定した場合は、コンパイラで C++ 形式のコメントが認識されます。このオプションを使用すると、// を使用してコメントの始まりを示すことができます。
-xc99 オプションは、C99 規格 (『Programming Language - C (ISO/IEC 9899:1999)』) からの実装機能に対するコンパイラの認識状況を制御します。
次の表に、o の許容値の一覧を示します。複数の値はコンマで区切ることができます。
表 B-17 -xc99 のフラグ
|
-xc99 を指定しない場合は、コンパイラではデフォルトで -xc99=all,no_lib が設定されます。値を指定しないで -xc99 を指定すると、オプションは -xc99=all に設定されます。
オプティマイザ用のキャッシュ特性を定義します。この定義によって、特定のキャッシュが使用されるわけではありません。
注 - このオプションは単独で指定できますが、-xtarget オプションのマクロ展開の一部です。-xtarget オプションによって指定された値を変更するのが主な目的です。
オプションのプロパティー [/ti ] は、キャッシュを共有できるスレッド数を設定します。t の値を指定しない場合のデフォルトは 1 です。
c には次のいずれかを指定します。
generic
native
s1/ l1/a 1[/t1]
s1/l1/a 1[/t1]:s2/l 2/a2[ /t2]
s1/l1/a 1[/t1]:s2/l 2/a2[ /t2]:s3/l 3/a3[ /t3]
s、l、a、t の各特性の定義は次のとおりです。
レベル i のデータキャッシュのサイズ (キロバイト単位)
レベル i のデータキャッシュのラインサイズ (バイト単位)
レベル i のデータキャッシュの結合特性
レベル i でキャッシュを共有するハードウェアスレッドの数
次に、-xcache の値を示します。
表 B-18 -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 の許容値の一覧を示します。
表 B-19 -xchar のフラグ
|
-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) で決定された順に配置します。詳細は、「2.1.2 文字定数」および 「B.2.71 -X[c| a|t|s]」を参照してください。
スタックオーバーフローに関する実行時検査を追加し、ローカル変数を初期化します。
次の表に、o の値の一覧を示します。
表 B-20 -xcheck のフラグ
|
-xcheck を指定しない場合は、コンパイラではデフォルトで -xcheck=%none が指定されます。引数を指定せずに xcheck を使用した場合は、コンパイラではデフォルトで -xcheck=%all が指定されます。
-xcheck オプションは、コマンド行で累積されません。コンパイラは、コマンドで最後に指定したものに従ってフラグを設定します。
-xcheck=init_local では、次の表に示すように、コンパイラは初期化子なしで宣言されたローカル変数を事前定義された値に初期化します。(これらの値は変更される可能性があるため、信頼しないでください)。
表 B-21 基本型の init_local の初期化
|
計算された goto で使用するために宣言されたローカル変数 (単純な void * ポインタ) は、表中のポインタの説明に従って初期化されます。
次のローカル変数型は初期化されません: 修飾された const、register、計算された goto のラベル番号、ローカルラベル。
初期化されていない参照が可視エラーを生成する可能性を最大化するために、struct 内の基本型であるフィールドは、表で説明されているとおりに初期化されます。union 内で最初に宣言された pointer または float フィールドも同様です。
配列要素も表で説明されているとおりに初期化されます。
入れ子の struct、union、および配列フィールドは、ビットフィールドを含む struct、pointer または float フィールドのない union、または完全に初期化できない型の配列を除いて、表で説明されているとおりに初期化されます。これらの例外は、型 double のローカル変数に使用される値で初期化されます。
このオプションは単独でも使用できますが、-xtarget オプションの展開の一部です。その主な使用方法は、-xtarget オプションで提供される値を上書きすることです。
このオプションは、処理対象となるプロセッサを指定することによって、タイミング特性を指定します。いくつかの影響があります。
命令の順序 (スケジューリング)
コンパイラが分岐を使用する方法
意味が同じもので代用できる場合に使用する命令
次の表は、SPARC プラットフォーム向けの c の -xchip 値の一覧です。
表 B-22 SPARC -xchip のフラグ
|
次の表は、x86 プラットフォーム向けの -xchip の値をまとめています。
表 B-23 x86 -xchip のフラグ
|
注 - -xcode=pic13 または -xcode=pic32 を指定することで、共有オブジェクトを構築します。-m64 -xcode=abs64 でも作業可能な共有オブジェクトを構築できますが、それらは効率的ではありません。-m64, -xcode=abs32 または -m64, -xcode=abs44 を指定して構築された共有オブジェクトは動作しません。
次の表に、v の値の一覧を示します。
表 B-24 -xcode のフラグ
|
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 標準形式を使用してデバッグ情報を生成します。これがデフォルトです。
表 B-25 -xdebugformat のフラグ
|
-xdebugformat を指定しない場合は、コンパイラでは -xdebugformat=dwarf が指定されます。このオプションには引数が必要です。
このオプションは、-g オプションによって記録されるデータの形式に影響します。-g を指定しなくても、一部のデバッグ情報が記録されますが、その情報の形式もこのオプションによって制御されます。したがって、-g を使用しなくても、-xdebugformat は効果があります。
dbx とパフォーマンスアナライザソフトウェアは、STABS 形式と DWARF 形式を両方とも理解するので、このオプションを使用しても、いずれかのツールの機能に対する影響はありません。
詳細は、dumpstabs(1) および dwarfdump(1) のマニュアルページを参照してください。
ループの繰り返し内部でのデータ依存性を解析し、ループの交換、ループの融合、スカラー置換など、ループの再構成を行います。
最適化レベルが -xO3 かそれ以上に設定されている場合はすべて、-xdepend のデフォルトは -xdepend=on です。-xdepend の明示的な設定を指定すると、デフォルト設定は上書きされます。
引数なしで -xdepend を指定すると、-xdepend=yes と同等であることを意味します。
依存性の解析はシングルプロセッサシステムで役立つことがあります。ただし、シングルプロセッサシステムで -xdepend を使用する場合は、-xautopar も指定するべきではありません。-xdepend 最適化は、マルチプロセッサシステムのために行われるためです。
プログラム内でマクロがどのように動作しているかを確認するときは、このオプションを使用します。このオプションは、定義済みマクロ、解除済みマクロ、実際の使用状況といった情報を提供します。マクロの処理順序に基づいて、標準エラー (stderr) への出力が出力されます。-xdumpmacros オプションは、ファイルの終わりまで、または dumpmacros プラグマまたは end_dumpmacros プラグマによって上書きされるまで有効です。「2.11.6 dumpmacros」を参照してください。
次の表に、value の有効な引数の一覧を示します。接頭辞 no% は関連付けられた値を無効にします。
表 B-26 -xdumpmacros の値
|
オプションの値は累積されるので、-xdumpmacros=sys -xdumpmacros=undefs を指定することは、-xdumpmacros=undefs,sys と同じ効果があります。
注 - サブオプション loc、conds、sys は、オプション defs、undefs、use の修飾子です。loc、conds、sys は、単独では効果はありません。たとえば -xdumpmacros=loc,conds,sys は、まったく効果を持ちません。
引数なしで -xdumpmacros を指定するときのデフォルトは、-xdumpmacros=defs,undefs,sys です。-xdumpmacros を指定しないときのデフォルトは、-xdumpmacros=%none です。
-xdumpmacros=use,no%loc オプションを使用すると、使用した各マクロの名前が一度だけ出力されます。より詳しい情報が必要であれば、-xdumpmacros=use,loc オプションを使用します。マクロを使用するたびに、そのマクロの名前と位置が印刷されます。
次のファイル t.c を考慮します。
example% cat t.c #ifdef FOO #undef FOO #define COMPUTE(a, b) a+b #else #define COMPUTE(a,b) a-b #endif int n = COMPUTE(5,2); int j = COMPUTE(7,1); #if COMPUTE(8,3) + NN + MM int k = 0; #endif
次の例は、defs、undefs、sys、および loc の引数に基づいた、ファイル t.c の出力を示しています。
example% cc -c -xdumpmacros -DFOO t.c #define __SunOS_5_9 1 #define __SUNPRO_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 の値の一覧を示します。
表 B-27 -xF の値
|
サブオプションを無効にするには、(%all および %none を除いた) 値の前に no% を置きます。例: no%func。
-xF を指定しない場合のデフォルトは、-xF=%none です。引数を指定しないで -xF を指定した場合のデフォルトは、-xF=%none,func です。
-xF=lcldata を使用するとアドレス計算最適化が一部禁止されるので、このフラグは試験によって正しいと認められた場合にのみ使用してください。
analyzer(1)、および ld(1) のマニュアルページを参照してください。
-xhelp=flags は、コンパイラオプションの要約を表示します。
(SPARC) コンパイラのハードウェアカウンタによるプロファイリングのサポートを有効にします。
-xhwcprof を有効にすると、コンパイラは、プロファイル対象のロード命令およびストア命令と、それらが参照するデータ型および構造体メンバーをツールが関連付けるのに役立つ情報を、-g で生成されたシンボル情報と組み合わせて生成します。プロファイルデータを、命令領域ではなくターゲットのデータ領域に関連付けます。これにより、命令プロファイリングだけからは簡単には得られない、動作に対する洞察が提供されます。
指定した一連のオブジェクトファイルは、-xhwcprof を指定してコンパイルできます。ただし、-xhwcprof は、アプリケーション内のすべてのオブジェクトファイルに適用されたときに、もっとも役立ちます。アプリケーションのオブジェクトファイルに分散しているすべてのメモリー参照が洗い出され、相互に関連付けられます。
コンパイルとリンクを別々に行う場合は、-xhwcprof をリンク時にも使用してくだ さい。-xhwcprof への今後の拡張により、リンク時にこれを使用することが必要になる可能性があります。表 A-2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。
-xhwcprof=enable または -xhwcprof=disable のインスタンスは、同じコマンド行にある以前の -xhwcprof のインスタンスをすべて無効にします。
-xhwcprof はデフォルトでは無効です。引数を指定せずに -xhwcprof と指定することは、-xhwcprof=enable と指定することと同じです。
-xhwcprof では、最適化を有効にして、デバッグデータ形式を DWARF (-xdebugformat=dwarf) に設定する必要があります。
-xhwcprof と -g を組み合わせて使用すると、コンパイラに必要な一時ファイル記憶領域は、-xhwcprof と -g を単独で指定することによって増える量の合計を超えて大きくなります。
次のコマンドは example.c をコンパイルし、ハードウェアカウンタによるプロファイリングのサポートを指定し、DWARF シンボルを使用してデータ型と構造体メンバーのシンボリック解析を指定します。
example% cc -c -O -xhwcprof -g -xdebugformat=dwarf example.c
ハードウェアカウンタベースのプロファイリングの詳細は、『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 以上でにのみ効果を持ちます。
表 B-28 -xinline のフラグ
|
値のリストは、左から右に累積されます。-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 も参照してください。
スレッドアナライザで分析するためにプログラムをコンパイルして計測するには、このオプションを指定します。スレッドアナライザの詳細は、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 は、コンパイル時とリンク時の両方で指定する必要があります。表 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 を指定してコンパイルするケースを考えてみましょう。-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 の値の一覧を示します。
表 B-29 -xipo_archive のフラグ
|
-xipo_archive の値が指定されない場合、-xipo_archive=none に設定されます。
-xipo_archive= を値付きで指定する必要があります。
#pragma ivdep プラグマの解釈を無効化または設定します (ベクトル依存を無視)。
ivdep プラグマは、最適化の目的でループ内で検出された、配列参照へのループがもたらす依存関係の一部またはすべてを無視するようにコンパイラに指示します。これによってコンパイラは、マイクロベクトル化、分散、ソフトウェアパイプラインなど、それ以外の場合は不可能なさまざまなループ最適化を実行できます。これは、依存関係が重要ではない、または依存関係が実際に発生しないことをユーザーが把握している場合に使用されます。
#pragma ivdep 指令の解釈は、—xivdep オプションの値に応じて異なります。
次のリストは、p の値とそれらの意味です。
ループキャリーのベクトル依存と想定されるものを無視
ループキャリーのベクトル依存をすべて無視
逆方向のループキャリーのベクトル依存と想定されるものを無視
逆方向のループキャリーのベクトル依存をすべて無視
依存を無視しない (ivdep プラグマの無効化)
これらの解釈は、ほかのベンダーの ivdep プラグマの解釈との互換性のために提供されます。
コンパイラが作業を完了するために作成するプロセス数を設定するときは、-xjobs オプションを指定します。このオプションは、マルチ CPU マシン上での構築時間を短縮できます。現時点では、-xipo オプションは、-xjobs が一緒に指定されているときにだけ機能します。-xjobs=n を指定すると、内部手続きオプティマイザは、さまざまなファイルをコンパイルするために呼び出すことができるコードジェネレータインスタンスの最大数として、n を使用します。
一般に、n に指定する確実な値は、使用できるプロセッサ数に 1.5 を掛けた数です。生成されたジョブ間のコンテキスト切り替えにより生じるオーバーヘッドのため、使用できるプロセッサ数の何倍もの値を指定すると、パフォーマンスが低下することがあります。また、あまり大きな数を使用すると、スワップ領域などシステムリソースの限界を超える場合があります。
-xjobs には必ず値を指定する必要があります。そうでない場合は、エラー診断が発行され、コンパイルは停止します。
コマンド行に複数の -xjobs のインスタンスがある場合、一番右にあるインスタンスが実行されるまで相互に上書きします。
次の例に示すコマンドは 2 つのプロセッサを持つシステム上で、-xjobs オプションを指定しないで実行された同じコマンドよりも高速にコンパイルを実行します。
example% cc -xipo -xO4 -xjobs=3 t1.c t2.c t3.c
-xipo_archive= を値付きで指定する必要があります。
指定した機能 (name) のスタック関連の最適化を禁止します。
すべてのコードのスタック関連最適化を禁止します。
すべてのコードのスタック関連最適化を許可します。
このオプションは累積的で、コマンド行で複数回指定できます。たとえば、—xkeepframe=%all —xkeepframe=no%func1 は、func1 を除くすべての関数のスタックフレームが保持されるはずであることを示します。また、—xkeepframe は —xregs=frameptr より優先されます。たとえば、—xkeepframe=%all —xregs=frameptr は、すべての関数のスタックが保持されるはずですが、—xregs=frameptr の最適化は無視されることを示します。
このオプションがコマンド行で指定されていないと、コンパイラはデフォルトの -xkeepframe=%none を使用します。このオプションが値なしで指定されると、コンパイラは -xkeepframe=%all を使用します。
extern シンボルの定義に対するデフォルトのリンカースコープを変更するには、-xldscope オプションを指定します。デフォルトを変更すると、実装がよりうまく隠されるので、より早く、より安全に共有ライブラリを使用できます。
v には、次のいずれかを指定します。
表 B-30 -xldscope のフラグ
|
-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 指示子で宣言されたライブラリ関数は、ライブラリの構築時にインラインで生成することができます。これらの関数がユーザーによって無効にされることは想定されていません。詳細は、「2.2 リンカースコープ指示子」を参照してください。
__global 指示子で宣言されたライブラリ関数はインラインで宣言しないでください。また、-xinline コンパイラオプションを使用してインライン化することから保護されるようにしてください。
-xinline、-xO、-xipo 、 #pragma inline も参照してください。
例外が起きた場合の数学ルーチンの戻り値を強制的に IEEE 754 形式にします。この場合、例外メッセージは表示されないので、errno には依存しないでください。
実行速度を上げるため、一部のライブラリルーチンをインライン化します。オプションによって浮動小数点演算用オプションとプラットフォームに適したアセンブリ言語のインラインテンプレートが選択されます。
-xlibmil は、-xinline フラグで関数を指定しているかどうかに関係なく、関数をインライン化します。
ただし、こうした置換によって errno の値の信頼性が失われることがあります。プログラムが errno の値に依存している場合、このオプションの使用は避けてください。「2.13 errno の値の保持」も参照してください。
このオプションによって、コンパイラは最適化された数学ルーチンのライブラリを利用できます。このオプションを使用するときは -fround=nearest を指定することによって、デフォルトの丸めモードを使用する必要があります。
数学ルーチンライブラリは最高のパフォーマンスが得られるように最適化されており、通常、高速なコードを生成します。この結果は、通常の数学ライブラリが生成する結果と少し異なることがあります。その場合、通常、異なるのは最後のビットです。
これらの置換によって、errno の設定の信頼性が失われる可能性があります。プログラムが errno の値に依存している場合、このオプションの使用は避けてください。詳細は、「2.13 errno の値の保持」を参照してください。
このライブラリオプションをコマンド行に指定する順序は重要ではありません。
このオプションは -fast オプションを指定した場合にも設定されます。
-fast および -xnolibmopt も参照してください。
(廃止) Sun Performance Library とリンクするときは、-library=sunperf を使用してください。
このオプションは、コンパイル時には暗黙的に無視されます。
(SPARC) 再配置可能なオブジェクトファイルのリンク時の最適化を実行するようコンパイラに指示します。このような最適化は、リンク時にオブジェクトのバイナリコードを解析することによって実行されます。オブジェクトファイルは書き換えられませんが、結果の実行可能コードは元のオブジェクトコードとは異なる場合があります。
-xlinkopt をリンク時に有効にするには、少なくともコンパイルコマンドで -xlinkopt を使用する必要があります。-xlinkopt を指定しないでコンパイルされたオブジェクトバイナリについても、オプティマイザは限定的な最適化を実行できます。
-xlinkopt は、コンパイラのコマンド行にある静的ライブラリのコードは最適化しますが、コマンド行にある共有 (動的) ライブラリのコードは最適化しません。共有ライブラリを構築 (-G でコンパイル) するときに、-xlinkopt も使用できます。
level には、実行する最適化のレベルを 0、1、2 のいずれかで設定します。次の表に、最適化レベルの一覧を示します。
表 B-31 -xlinkopt のフラグ
|
別の手順でコンパイルする場合は、コンパイルとリンクの両方の手順で -xlinkopt を指定する必要があります。
example% cc -c -xlinkopt a.c b.c example% cc -o myprog -xlinkopt=2 a.o
表 A-2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。
レベルパラメータは、コンパイラのリンク時にだけ使用されます。例では、オブジェクトバイナリが暗黙のレベル 1 でコンパイルされた場合でも、使用される最適化後レベルは 2 です。
レベルパラメータなしで -xlinkopt を使用することは、-xlinkopt=1 を指定することと同じです。
このオプションは、プログラム全体のコンパイル時に、プロファイルのフィードバックとともに使用されると、もっとも効果的です。プロファイリングによって、コードでもっともよく使用される部分と、もっとも使用されない部分が明らかになるので、構築はオプティマイザに対してそれに基づいて作業を集中するように指示します。このオプションは、リンク時に実行されるコードの最適な配置が命令キャッシュミスを低減できるような、大きなアプリケーションにとって特に重要です。通常、このオプションは次のように使用します。
example% cc -o progt -xO5 -xprofile=collect:prog file.c example% progt example% cc -o prog -xO5 -xprofile=use:prog -xlinkopt file.c
プロファイルフィードバックの使用方法についての詳細は、「B.2.144 -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 でコンパイルすることは許可されず、エラーが生成されます。依存関係ファイルがすでに存在する場合は上書きされます。
メイクファイルの依存関係の出力先ファイルを指定するには、このオプションを使用します。1 つのコマンド行の -xMF で、複数の入力ファイルに個々の filename を指定することはできません。複数のソースファイルで -xMD -xMF または -xMMD -xMF を使用してコンパイルすることはできず、エラーが生成されます。依存関係ファイルがすでに存在する場合は上書きされます。
システムヘッダーファイルを除き、メイクファイルの依存関係を生成するには、このオプションを使用します。このオプションは -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-32 -xmemalign の境界整列と動作のフラグ
|
b を i か f のいずれかに設定してコンパイルしたオブジェクトファイルにリンクする場合は、必ず、-xmemalign を指定する必要があります。表 A-2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。
コンパイル時に境界整列が判別できるメモリーへのアクセスの場合、コンパイラはそのデータの境界整列に適したロードおよびストア命令を生成します。
境界整列がコンパイル時に決定できないメモリーアクセスの場合、コンパイラは、境界整列を想定して、必要なロード/ストア命令のシーケンスを生成します。-xmemalign オプションは、これらの状況のときにコンパイラが想定するデータの最大メモリー境界整列を指定できます。-xmemalign オプションは、境界整列に失敗したメモリーへのアクセスが実行時に発生した場合に行われるエラー動作 (処理) についても指定できます。
実行時の実際のデータ境界整列が指定された整列に達しない場合、境界整列に失敗したアクセス (メモリー読み取りまたは書き込み) が行われると、トラップが発生します。このトラップに対して可能な応答は 2 つあります。
OS がトラップを SIGBUS シグナルに変換します。プログラムがこのシグナルを捕捉しない場合、プログラムは停止します。プログラムがシグナルを捕捉しても、境界整列に失敗したアクセスが成功するわけではありません。
境界整列に失敗したアクセスが正常に成功したかのように OS がアクセスを解釈し、プログラムに制御を戻すことによってトラップを処理します。
次のデフォルトの値は、-xmemalign オプションがまったく指定されていない場合にのみ適用されます。
すべての 32 ビットプラットフォーム (-m32) で -xmemalgin=8i。
すべての 64 ビットプラットフォーム (-m64) で -xmemalign=8s。
-xmemalign オプションが指定されているけれども値が与えられていないときのデフォルトは、すべてのプラットフォームで -xmemalign=1i です。
次の表は、さまざまな境界整列状況を扱うために -xmemalign をどのように使用できるかについての説明です。
表 B-33 -xmemalign の例
|
(x86) -xmodel オプションは、コンパイラが Oracle Solaris x86 プラットフォームのために 64 ビットオブジェクトの形式を変更することを許可します。そのようなオブジェクトのコンパイルにのみ指定するようにしてください。
このオプションは、64 ビット対応の x64 プロセッサで -m64 も指定した場合にのみ有効です。
次の表に、a の値の一覧を示します。
表 B-34 -xmodel のフラグ
|
このオプションは累積的ではないため、コンパイラはコマンド行でもっとも右側の -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 プラットフォームでの最適化レベルの一覧です。
表 B-35 SPARC プラットフォームでの -xO のフラグ
|
次の表は、x86 プラットフォームでの最適化レベルの一覧です。
表 B-36 x86 プラットフォームでの -xO のフラグ
|
デバッグの詳細は、『『Oracle Solaris Studio: dbx コマンドによるデバッグ』』を参照してください。ｗ最適化の詳細は、『『Oracle Solaris Studio パフォーマンスアナライザ』』マニュアルを参照してください。
-xldscope および -xmaxopt も参照してください。
OpenMP 指令で明示的な並列化を有効にするには、-xopenmp オプションを使用します。並列化されたプログラムをマルチスレッド環境で実行するには、実行前に環境変数 OMP_NUM_THREADS を 1 より大きな値に設定する必要があります。設定しない場合は、デフォルトは 2 です。より多くのスレッドを使用するには、OMP_NUM_THREADS をより高い値に設定します。1 つのスレッドだけで実行する場合は、OMP_NUM_THREADS を 1 に設定します。一般に、OMP_NUM_THREADS には、実行中のシステムで使用可能な仮想プロセッサ数を設定します。Oracle Solaris の psrinfo(1) コマンドを使用することで判断できます。
入れ子並列を有効にするには、OMP_NESTED 環境変数を TRUE に設定する必要があります。入れ子並列は、デフォルトでは無効です。
次の表に i の値を示します。
表 B-37 -xopenmp のフラグ
|
-xopenmp を指定するけれども値を含めない場合、コンパイラは -xopenmp=parallel を想定します。-xopenmp を指定しない場合、コンパイラは -xopenmp=none を仮定します。
dbx を指定して OpenMP プログラムをデバッグする場合、-g と -xopenmp=noopt を指定してコンパイルすれば、並列化部分にブレークポイントを設定して変数の内容を表示することができます。
-xopenmp のデフォルトは、将来変更される可能性があります。警告メッセージを出力しないようにするには、適切な最適化を明示的に指定します。
so ライブラリの構築中に -xopenmp を使用する場合、実行可能ファイルをリンクするときに -xopenmp を使用する必要があります。実行可能ファイルのコンパイラは、-xopenmp を指定して .so を構築するコンパイラよりも古いものであってはなりません。この要件は、OpenMP 指令を含むライブラリをコンパイルするときに特に重要です。表 A-2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。
最良のパフォーマンスを得るには、OpenMP 実行時ライブラリ libmtsk.so の最新パッチが、システムにインストールされていることを確認してください。
OpenMP の C の実装に固有の情報については、「3.2 OpenMP に対する並列化」を参照してください。
OpenMP の詳細は、『Oracle Solaris Studio OpenMP API ユーザーズガイド』を参照してください。
すべての 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。
有効なページサイズを指定しない場合は、要求は実行時にサイレントに無視されます。ターゲットプラットフォームに対して有効なページサイズを指定する必要があります。
Oracle Solaris オペレーティングシステムでページのバイト数を判断するには、getpagesize(3C) コマンドを使用します。Oracle Solaris オペレーティングシステムは、ページサイズ要求に従うという保証は提供されません。ターゲットプラットフォームのページサイズを判断するために、pmap(1) または meminfo(2) を使用できます。
-xpagesize オプションは、コンパイル時とリンク時に使用しないかぎり無効です。表 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 オプションは、コンパイル時とリンク時に使用しないかぎり無効です。表 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 オプションは、コンパイル時とリンク時に使用しないかぎり無効 です。表 A-2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。
このコンパイラオプションは、プリコンパイル済みヘッダー機能を起動します。v には、auto、autofirst、collect:pch_filename、use:pch_filename のいずれかを指定できます。この機能は、-xpch と -xpchstop オプションを、#pragma hdrstop 指令と組み合わせることで利用できます。
-xpch オプションは、プリコンパイル済みヘッダーファイルを作成して、コンパイル時間を短縮するときに使用します。プリコンパイル済みヘッダーファイルは、大量のソースコードを含む一連の共通インクルードファイルセットをソースファイルが共有しているアプリケーションの、コンパイル時間を短縮します。プリコンパイル済みヘッダーを使用することによって、1 つのソースファイルから一連のヘッダーファイルに関する情報を収集し、そのソースファイルを再コンパイルする場合や、同じ一連のヘッダーを持つほかのソースファイルをコンパイルする場合に、その情報を使用することができます。コンパイラが収集する情報は、プリコンパイル済みヘッダーファイルに格納されます。
詳細は、次を参照してください。
コンパイラは、2 つの方法のいずれかでプリコンパイル済みヘッダーファイルを自動的に生成できます。1 つは、ソースファイルで検出された最初のインクルードファイルからプリコンパイル済みヘッダーファイルを作成する方法、もう 1 つの方法は、コンパイラが、ソースファイルで検出されたインクルードファイルのセット (最初のインクルードファイルから始めて、どのインクルードファイルが最後のものであるかを判断するためのよく定義されたポイントまで) から選択する方法です。プリコンパイル済みヘッダーを自動的に生成するためにコンパイラがどの方法を使用するかを判断するには、次の表で説明するフラグのいずれかを使用します。
表 B-38 -xpch のフラグ
|
プリコンパイル済みヘッダーファイルを手動で作成するには、最初に -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 が指定された場合)
注 - プリプロセッサ条件コンパイル文内に終点がある場合は、警告が生成され、プリコンパイル済みヘッダーファイルの自動作成は無効になります。また、#pragma hdrstop と -xpchstop オプションの両方が指定された場合、コンパイラは 2 つの停止点のうちの早い方を使用して、活性文字列を終了します。
-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ファイルを作成します。
注 - -xprofile とともに使用される場合、—xpg は追加の利点を提供しません。これら 2 つのオプションは、他方で提供されるデータを準備または使用しません。
プロファイルは、64 ビット Oracle Solaris プラットフォームでは prof(1) または gprof (1) を使用して、32 ビット OracleSolaris プラットフォームでは 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 を指定した場合は、リンク時にも指定する必要があります。「A.1.2 コンパイル時とリンク時のオプション」に、コンパイル時とリンク時の両方に指定する必要があるオプションの全一覧をまとめています。
注 - gprof プロファイリングのために -xpg でコンパイルされたバイナリは、binopt(1) では使用しないでください。互換性がないため、内部エラーになる可能性があります。
先読みをサポートするそれらのアーキテクチャーで先読み命令を有効にします。
明示的な先読みは、測定方法によってサポートされる特殊な環境でのみ使用してください。
次の表に、val の値の一覧を示します。
表 B-39 -xprefetch のフラグ
|
デフォルトは -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、generic64、native64) 用のコードを生成します。
-xprefetch_level=1 は、先読み命令の自動生成を有効にします。-xprefetch_level=2 は、レベル 1 を上回る追加生成を有効にします。-xprefetch_level=3 は、レベル 2 を上回る追加生成を有効にします。
デフォルトは、-xprefetch=auto を指定した場合は -xprefetch_level=1 になります。
プロファイルのデータを収集したり、プロファイルを使用して最適化したりします。
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 オプションを除き、ソースファイルおよびコンパイラのほかのオプションは、フィードバックファイルを生成したコンパイル済みプログラムのコンパイルに使用したものと完全に同一のものを指定する必要があります。同じバージョンのコンパイラは、収集構築と使用構築の両方に使用する必要があります。
-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_pathmap= コマンドも指定する場合は、-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 がオブジェクトファイルパス名と一致しないことが確認されるまで、オブジェクトファイルパス名と比較されます。
自動並列化中に、縮約の認識を有効にします。-xreduction でのコンパイルには -xautopar が必要で、そうでない場合、コンパイラは警告を発行します。
縮約の認識が有効な場合、コンパイラは内積、最大値検索、最小値検索などの縮約を並列化します。これらの縮約によって非並列化コードの場合とは、四捨五入の結果が異なります。
r には、appl、float、frameptr サブオプションのいずれか 1 つ以上をコンマで区切って指定します。
サブオプションの前に no% を付けるとそのサブオプションは無効になります。
—xregs サブオプションは、特定のハードウェアプラットフォームでしか使用できません。
例: -xregs=appl,no%float
表 B-40 -xregs のサブオプション
|
SPARC のデフォルトは -xregs=appl,float です。
x86 のデフォルトは -xregs=no%frameptr です。
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 ファイル全体のすべてのポインタパラメータが制限付きとして扱われます。詳細は、「3.7.2 制限付きポインタ」を参照してください。
このコマンド行オプションは独立して使用できますが、最適化時に使用するのがもっとも適しています。たとえば、このコマンドは、ファイル prog.c 内のすべてのポインタパラメータを制限付きポインタとして扱います。
%cc -xO3 -xrestrict=%all prog.c
このコマンドは、ファイル prog.c 内の関数 agc 内のすべてのポインタパラメータを制限付きポインタとして扱います。
%cc -xO3 -xrestrict=agc prog.c
デフォルトは %none です。-xrestrict を指定することは、-xrestrict=%all を指定することと同義です。
オブジェクトファイルなしに dbx でデバッグできるようにします。
このオプションを指定すると、すべてのデバッグ情報が実行可能ファイルにコピーされます。このオプションは、dbx のパフォーマンスやプログラムの実行時パフォーマンスにはほとんど影響しませんが、より多くのディスク容量を使用します。
(SPARC) コンパイラが記憶域保護違反が発生した場合を前提とできるようにします。
このオプションを使用すると、コンパイラでは SPARC V9 アーキテクチャーで違反のないロード命令を使用できます。
注 - アドレスの位置合わせが合わない、またはセグメンテーション侵害などの違反が発生した場合は違反のないロードはトラップを引き起こさないので、このオプションはこのような違反が起こる可能性のないプログラムでしか使用しないでください。ほとんどのプログラムではメモリーに関するトラップは起こらないので、大多数のプログラムでこのオプションを安全に使用できます。例外条件の処理にメモリーベースのトラップを明示的に使用するプログラムでは、このオプションは使用しないでください。
このオプションは、最適化レベルの -xO5 と、次のいずれかの値の -xarch を組み合わせた場合にだけ有効です。m32 と m64 の両方で sparc、sparcvis、-sparcvis2、または -sparcvis3。
接尾辞のない浮動小数点定数を、デフォルトの倍精度モードではなく、単精度として表します。-Xc と併用することはできません。
例: コードサイズが増える場合は、ループの展開や並列化は行われません。
このオプションは非推奨であり、将来のリリースで削除される可能性があります。—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 と同義です。
注 - 特定のホストプラットフォームで -xtarget を展開した場合、そのプラットフォームでコンパイルすると -xtarget=native と同じ -xarch、-xchip、または -xcache 設定にならない場合があります。
表 B-41 すべてのプラットフォームでの -xtarget の値
|
対象となるハードウェア (コンピュータ) の正式な名前をコンパイラに指定した方がパフォーマンスが優れているプログラムもあります。プログラムパフォーマンスがクリティカルな場合、ターゲットハードウェアの適切な指定は、より新しい SPARC プロセッサ上での実行時は特に、非常に重要である可能性があります。しかし、ほとんどのプログラムおよび旧式の SPARC システムではパフォーマンスの向上はわずかであるため、汎用的な指定方法で十分です。
SPARC または UltraSPARC V9 で 64 ビット Oracle Solaris ソフトウェアをコンパイルすることは、-m64 オプションで示されます。native64 または generic64 以外のフラグで -xtarget を指定する場合は、-m64 オプションも次のように指定する必要があります: -xtarget=ultra... -m64。そうでない場合は、コンパイラは 32 ビットメモリーモデルを使用します。
表 B-42 SPARC での -xtarget 展開
|
64 ビット x86 プラットフォームで 64 ビット Oracle Solaris ソフトウェアをコンパイルすることは、-m64 オプションで示されます。native64 または generic64 以外のフラグで -xtarget を指定する場合は、-m64 オプションも次のように指定する必要があります: -xtarget=opteron ... -m64。そうでない場合は、コンパイラは 32 ビットメモリーモデルを使用します。
表 B-43 x86 での -xtarget の展開
|
cc が使用する一時ファイルのディレクトリを dir に設定します。このオプション文字列の中にはスペースを入れてはいけません。このオプションを指定しない場合、一時ファイルは /tmp に配置されます。-xtemp は TMPDIR 環境変数より優先します。
スレッドローカルな変数の実装を制御するには -xthreadvar を指定します。コンパイラのスレッドローカルな記憶領域機能を利用するには、このオプションを __thread 宣言指示子と組み合わせて使用します。__thread 指示子を使用してスレッド変数を宣言したあとは、-xthreadvar を指定して動的 (共有) ライブラリの位置に依存しないコード (PIC 以外のコード) でスレッド固有の記憶領域を使用できるようにします。__thread の使用方法についての詳細は、「2.3 スレッドローカルな記憶領域指示子」を参照してください。
o は dynamic または no%dynamic である必要があります。
表 B-44 -xthreadvar のフラグ
|
-xthreadvar を指定しない場合、コンパイラが使用するデフォルトは位置独立コード (PIC) が有効になっているかどうかによって決まります。位置独立コードが有効になっている場合、オプションは -xthreadvar=dynamic に設定されます。位置独立コードが無効になっている場合、オプションは -xthreadvar=no%dynamic に設定されます。
-xthreadvar を指定するけれども値を指定しない場合は、オプションは -xthreadvar=dynamic に設定されます。
位置独立ではないコードが動的ライブラリに含まれる場合、-xthreadvar を指定する必要があります。
リンカーは、動的ライブラリ内の位置依存コード (非 PIC) スレッド変数と同等のスレッド変数はサポートできません。PIC でないスレッド変数は非常に高速なため、実行可能ファイルのデフォルトにするべきです。
-xcode、-KPIC、および -Kpic の説明も参照してください。
コンパイルの各構成要素が占有した実行時間と資源を報告します。
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
semantics of operator change in ISO C; use explicit cast
-xtrigraphs オプションは、コンパイラが ISO 規格で定義されている三文字表記シーケンスを認識するかどうかを決定します。
デフォルトにより、コンパイラは -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 (??)
ループを 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" 文字列リテラルを一緒に指定しなくても指定できます。
すべてのファイルを、このオプションによってコンパイルしなければならないわけではありません。
次の例では、前に 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% 接頭辞は関連付けられたサブオプションを無効にします。
表 B-45 -xvector のフラグ
|
デフォルトは、x86 では -xvector=simd で、SPARC プラットフォームでは -xvector=%none です。サブオプションなしで -xvector を指定する場合、コンパイラは、x86 Solaris では -xvector=simd,lib、SPARC Solaris では -xvector=lib、Linux プラットフォームでは -xvector=simd を想定します。
—xvector オプションを指定するには、最適化レベルが —xO3 かそれ以上に設定されていることが必要です。最適化レベルが指定されていない場合や —xO3 よりも低い場合はコンパイルは続行されず、メッセージが表示されます。
注 - x86 プラットフォーム向けの Oracle Solaris カーネルコードをコンパイルするときは、-xvector=%none を指定してコンパイルします。
コンパイラは、リンク時に 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
注 - Oracle Solaris Studio コンパイラは OpenMP API 並列化をサポートします。そのため、MP プラグマ命令は非推奨で、サポートされません。OpenMP API への移植については、『OpenMP API ユーザーズガイド』を参照してください。
c を検索するための新しい dir を指定します。c は -W オプションで示したコンパイラ構成要素を表わす文字です。
構成要素の検索が指定されている場合、ツールのパス名は dir/tool になります。2 つ以上の -Y オプションが 1 つの項目に適用されている場合には、最後に現れたものが有効です。
コンパイラのすべての構成要素の検索場所にするディレクトリ dir を指定します。dir 内で構成要素が見つからない場合は、コンパイラがインストールされているディレクトリに戻って検索されます。
include ファイルを検索するデフォルトディレクトリを変更します。
ライブラリファイルを検索するデフォルトのディレクトリを変更します。
起動用のオブジェクトファイルを検索するデフォルトのディレクトリを変更します。
(SPARC) lock_lint 用にプログラムデータベースを作成しますが、実行可能コードは生成しません。詳細は、lock_lint(1) のマニュアルページを参照してください。
|