付録 B C コンパイラオプションリファレンス

この章では、C コンパイラオプションについてアルファベット順に説明します。機能別のオプションは、付録 A 機能別コンパイラオプションを参照してください。たとえば、表 A–1 には、最適化とパフォーマンスのすべてのオプションがまとめられています。

C コンパイラは、デフォルトでは 1999 ISO/IEC C 規格の構文の一部を認識します。特に、サポートされている機能については、付録 D C99 でサポートされている機能を参照してください。コンパイラで 1990 ISO/IEC C 規格の機能だけを使用する場合は、-xc99=none コマンドを使用します。

K&R (Kernighan と Ritchie) C プログラムを ISO C に移植する場合、互換性フラグに関する節、「B.2.68 -X[c|a|t|s]」をよく参照してください。それらのオプションを使用することで、ISO C への移行が容易になります。また、「5.4 メモリー参照の制限の例」の移行に関する説明も参照してください。

B.1 オプションの構文

cc コマンドの構文を次に示します。

% cc [options] filenames [libraries]...

ここで

• options は、表 A–15 で説明している各種のオプションで、複数指定可能です。

• 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) を参照してください。

B.2 cc オプション

この節では、cc オプションについてアルファベット順に説明します。これらの説明は cc(1) のマニュアルページでも見ることができます。1 行に要約した説明が必要な場合は、cc -flags オプションを使用してください。

特定のプラットフォームに固有と表記されたオプションを別のプラットフォームで使用してもエラーは起きません。単に無視されます。

B.2.1 -#

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

B.2.2 -###

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

B.2.3 --Aname[(tokens)]

#assert 前処理指令に似せて、指定の tokens を使用し name を述語として関連付けます。事前表明 (preassertion) は次のとおりです。

• system(unix)

• machine(sparc) (SPARC)

• machine(i386) (x86)

• cpu(sparc) (SPARC)

• cpu(i386) (x86)

-Xc モードの場合、これらの事前表明は有効になりません。

-A のあとに続く文字がハイフン (-) だけの場合は、事前定義のマクロ ( __ から始まる以外のマクロ) および事前定義の表明はすべて失われます。

B.2.4 -B[static| dynamic]

リンク時に結合するライブラリを静的と動的のどちらにするかを指定します。static (静的) と指定するとライブラリが非共有ライブラリであることを示し、dynamic (動的) と指定すると共有ライブラリであることを示します。

-Bdynamic を指定すると、-lx オプションが指定されていれば、リンカーは libx.so というファイルを探し、次に libx.a というファイルを探します。

-Bstatic を指定すると、リンカーは libx.a というファイルだけを探します。このオプションは、コマンド行中で何度も指定して、切り替えることができます。このオプションと引数は ld(1) に渡されます。

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

このオプションと引数はリンカーに渡されます。

B.2.5 -C

C プリプロセッサがコメントを削除しないようにします。ただし前処理指令の行にあるコメントは削除されます。

B.2.6 -c

C コンパイラ ld(1) によるリンクを行わず、ソースファイルごとに o ファイルを作成します。-o オプションを使用すると、1 つのオブジェクトファイルを明示的に指定することができます。コンパイラが .i または .c の各入力ファイルに対応するオブジェクトコードを生成する場合は、現在の作業ディレクトリにオブジェクト (.o) ファイルを作成します。リンクを行わないと、オブジェクトファイルの削除も行われません。

B.2.7 -Dname[(arg[,arg])][=expasion]

#define 前処理マクロが指令によって定義されるのと同様に、オプションの引数を使用してマクロを定義します。=expansion が指定されていない場合は、コンパイラは 1 であると仮定します。

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

B.2.8 -d[y|n]

-dy はリンクエディタに動的なリンクを指定します (デフォルト)。

-dn はリンクエディタに静的なリンクを指定します。

このオプションとその引数は ld(1) に渡されます。

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

B.2.9 -dalign

(SPARC) 廃止。このオプションは使わないでください。代わりに -xmemalign=8s を使用してください。詳細は、「B.2.116 -xmemalign=ab」 を参照してください。廃止オプションの全一覧は、「A.1.15 廃止オプション」を参照してください。x86 プラットフォームでは、このオプションはメッセージを表示せずに無視されます。

B.2.10 -E

プリプロセッサのみでソースファイルを処理し、出力を stdout に送ります。プリプロセッサはコンパイラ内部に直接組み込まれます。/usr/ccs/lib/cpp が直接呼び出される -Xs モードの場合は除きます。プリプロセッサの行番号付け情報も含みます。-P オプションも参照してください。

B.2.11 -errfmt[=[ no%]error]

このオプションは、エラーメッセージの最初に「error:」という接頭辞を追加して、警告メッセージと区別しやすくする場合に使用します。接頭辞は、-errwarn によってエラーに変換された警告にも追加されます。

このオプションを指定しない場合は、-errfmt=no%errorに設定されます。-errfmt を値なしで指定した場合は、コンパイラでは -errfmt=error が指定されます。

B.2.12 -errhdr=h]

ヘッダーファイルからの警告を、次のフラグによって示されたヘッダーファイルグループに限定します。

B.2.13 -erroff[= t]

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

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

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

-erroff オプションで無効にできるのは、C コンパイラのフロントエンドで -errtags オプションを指定したときにタグを表示する警告メッセージだけです。無効にするエラーメッセージをさらに詳細に設定することができます。「2.11.6 error_messages」を参照してください。

B.2.14 -errshort[= i]

このオプションは、コンパイラで型の不一致が検出されたときに生成されるエラーメッセージの詳細さを設定する場合に使用します。大きな集合体が関係する型の不一致がコンパイラで検出される場合にこのオプションを使用すると特に便利です。

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

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

このオプションは累積されず、コマンド行で最後に指定した値が有効になります。

B.2.15 -errtags[= a]

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

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

B.2.16 -errwarn[= t]

指定した警告メッセージが生成された場合に、重大なエラーを出力して 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 を指定したことと同じになります。

B.2.17 -fast

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

-fast の展開には、コンパイラが最適化済み数学ルーチンのライブラリを使用できるようにする -xlibmopt オプションが含まれます。詳細は、「B.2.104 -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 により指定されるオプションをプラットフォームごとに示します。

一部の最適化では、プログラムの動作が特定の動作になることを想定しています。プログラムの動作がその想定に適合していない場合は、アプリケーションがクラッシュする、または誤った結果が生成されることがあります。プログラムが -fast を指定したコンパイルに適しているかどうかを特定するには、各オプションの説明を参照してください。

これらのオプションにより最適化を実行した場合は、プログラムの動作が ISO C および IEEE の規格での定義と異なることがあります。詳細については、各オプションの説明を参照してください。

-fast はコマンド行でマクロ展開のように動作します。したがって、最適化レベルとコード生成の内容を -fast のあとに指定したオプションで指定した場合は、-fast での指定は無視されます。「-fast -xO4」でコンパイルすることは「-xO2 -xO4」の組み合わせでコンパイルすることと同じで、後ろの指定が優先されます。

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

このオプションは、IEEE 規格例外処理に依存するプログラムには使用しないでください。数値結果が異なったり、プログラムが途中で終了したり、予想外の SIGFPE シグナルが発生する可能性があります。

実行中のプラットフォームで -fast の実際の展開を表示するには、次のものを使用します。

% cc -fast -xdryrun

B.2.18 -fd

K&R 形式の関数の宣言や定義を報告します。

B.2.19 -features=[v]

次の表に、v の代わりに使用できる値を示します。

古い C および C++ オブジェクト (このリリースより前の Solaris Studio コンパイラで作成されたオブジェクト) は、そのオブジェクトの動作変更なしに、新しい C および C++ オブジェクトとリンクできます。規格に適合した動作を実現するには、最新のコンパイラを使って古いコードをコンパイルする必要があります。

-features に値を指定しない場合は、-features=extinl に設定されます。

B.2.20 -flags

使用できる各コンパイラオプションの要約を出力します。

B.2.21 -flteval[={any|2}]

(x86) このオプションは、浮動小数点式の評価方法の制御に使用します。

-flteval が指定されない場合は、-flteval=any に設定されます。値を付けずに -flteval が指定された場合は、-flteval=2 に設定されます。

-flteval=2 を指定する場合、次のオプションは指定してはいけません。

• -fprecision

• -nofstore

• -xarch=amd64

• -xarch=sse2

「D.1.1 浮動小数点評価における精度」も参照してください。

B.2.22 -fma[={none| fused}]

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

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

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

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

B.2.23 -fnonstd

(SPARC) このオプションは、-fns および -ftrap=common 用のマクロです。

B.2.24 -fns[={no|yes}]

• (SPARC) SPARC の非標準の浮動小数点モードに切り替えます。

  デフォルトは -fns=no であり、SPARC 標準の符号小数点モードと同じです。 -fns は、-fns=yes と同じことを意味します。

  オプションの =yes または =no を使用すると、-fast のように、-fns を含むほかのマクロフラグに続く -fns フラグを切り替えることができます。

  一部の SPARC システムでは、非標準の浮動小数点モードは「段階的アンダーフロー」を無効にします。つまり、小さな結果は、非正規数にはならず、ゼロに切り捨てられます。また、非正規オペランドはメッセージなしにゼロに変更されます。このような SPARC システムでは、ハードウェアの段階的アンダーフローや非正規数がサポートされておらず、このオプションを使用するとプログラムのパフォーマンスを著しく改善することができます。

  非標準モードを有効にすると、浮動小数点演算は IEEE 754 規格に準拠しない結果を生成する場合があります。詳細は、『数値計算ガイド』を参照してください。

  このオプションは、SPARC システム上だけで有効であり、さらに、メインプログラムをコンパイルするときに使用する場合だけ有効です。x86 システムでは、このオプションは無視されます。

• (x86) SSE flush-to-zero モードを選択します。利用可能な場合には、denormals-are-zero モードが選択されます。

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

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

B.2.25 -fPIC

-KPIC と同義です。

B.2.26 -fpic

-Kpic と同義です。

B.2.27 -fprecision=p

(x86) -fprecision={single, double, extended}

浮動小数点制御ワードの丸め精度モードのビットを、単精度 (24 ビット)、倍精度 (53 ビット) または拡張精度 (64 ビット) に設定します。デフォルトの浮動小数点丸め精度モードは拡張モードです。

x86 では、浮動小数点丸め精度モードの設定は精度に対してのみ影響します。指数の有効範囲に対しては影響しません。

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

B.2.28 -fround=r

プログラム初期化中に、実行時に確立される IEEE 754 丸めモードを設定します。

r は、nearest、 tozero、negative、positive のいずれかです。

デフォルトは、-fround=nearest です。

ieee_flags サブルーチンと同等です。

r を tozero、negative、positive のいずれかにすると、プログラムが実行を開始するときに、丸め方向モードがそれぞれ、ゼロの方向に丸める、負の無限の方向に丸める、正の無限の方向に丸めるに設定されます。r が nearest のとき、あるいは -fround フラグを使用しないとき、丸め方向モードは初期値から変更されません (デフォルトは nearest)。

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

B.2.29 -fsimple[= n]

オプティマイザが浮動小数点演算に関する前提事項を単純化できるようにします。

デフォルトは -fsimple=0 です。-fsimple は -fsimple=1 と同義です。

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

本来浮動小数点例外を発生しないプログラムならば、-fsimple=2 を指定してもオプティマイザが浮動小数点例外を発生させることはありません。

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

B.2.30 -fsingle

-Xt モードまたは -Xs モードの場合にかぎり、float 式を倍精度ではなく単精度で評価します。-Xa モードまたは -Xc モードを使用している場合、 float 式はすでに単精度として評価されているのでこのオプションは無効です。

B.2.31 -fstore

(x86) 浮動小数点式または関数が、ある変数に代入されるか、より小さい型の浮動小数点にキャストされる場合に、コンパイラがその値をレジスタに残さないで、代入値の左側に表記される型に変換するようにします。小数点の丸めおよび切り上げを行うため、結果はレジスタの値から生成される数値と異なる可能性があります。これは、デフォルトのモードです。

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

B.2.32 -ftrap=t[,t...]

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

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

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

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

たとえば、-ftrap=%all,no%inexact は、inexact 以外のすべてのトラップを設定することを意味します。

1 つのルーチンを -ftrap=t オプションでコンパイルした場合は、そのプログラムのルーチンすべてを、-ftrap=t オプションを使用してコンパイルしてください。途中から異なるオプションを使用すると、予想に反した結果が生じることがあります。

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

x = 1.0 / 3.0;

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

B.2.33 -G

動的にリンクされた実行可能ファイルではなく、共有オブジェクトを生成します。このオプションは ld(1) に渡されます。このオプションは -dn オプションと併用することはできません。

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

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

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

B.2.34 -g

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

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

-xO4 以下の最適化レベルで -g を指定すると、完全な最適化と可能なかぎりのシンボル情報が得られます。

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

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

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

デバッグの詳細については、『dbx コマンドによるデバッグ』を参照してください。

B.2.35 -H

現在のコンパイルでインクルードされたファイルのパス名を 1 行に 1 つずつ標準エラーに出力します。字下げして表示されるので、ファイルがさらにファイルをインクルードする様子を見ることができます。

次で、sample.c は stdio.h ファイルと math.h ファイルをインクルードします。math.h は floatingpoint.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

B.2.36 -h name;

共有動的ライブラリに名前を付けます。これによって、異なったバージョンのライブラリを作成できます。一般に -h のあとの name; は、-o オプションのあとに指定するファイル名と同じです。-h と name; の間の空白は任意です。

リンカーは指定された name; をライブラリに割り当て、この名前をライブラリのイントリンシック名としてライブラリファイルに記録します。-hname; オプションがない場合、イントリンシック名はライブラリファイルに記録されません。

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

B.2.37 -I[-|dir]

-I dir は、相対ファイル名、つまり、/ (スラッシュ) から始まらないディレクトリパスを持つ #include ファイルを検索するディレクトリのリスト内の /usr/include の前に dir を追加します。

複数の -I オプションが指定された場合は、指定された順序でディレクトリが調べられます。

コンパイラの検索パターンの詳細については、「2.16.1 -I- オプションによる検索アルゴリズムの変更」を参照してください。

B.2.38 -i

オプションをリンカーへ渡して、LD_LIBRARY_PATH または LD_LIBRARY_PATH_64 の設定を無視します。

B.2.39 -include filename;

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

main()
{
   ...
}

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

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

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

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

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

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

B.2.40 -KPIC

(SPARC) 廃止。このオプションは使わないでください。代わりに -xcode=pic32 を使用してください。

詳細は、「B.2.86 -xcode[= v]」 を参照してください。「A.1.15 廃止オプション」に、廃止のオプションの全一覧をまとめています。

(x86) -KPIC は -Kpic と同じです。

B.2.41 -Kpic

(SPARC) 廃止。このオプションは使わないでください。代わりに -xcode=pic13 を使用してください。詳細は、「B.2.86 -xcode[= v]」を参照してください。「A.1.15 廃止オプション」に、廃止のオプションの全一覧をまとめています。

(x86) 共用ライブラリ (小型モデル) で使用するための位置に依存しないコードを生成します。最大 2**11 個の独自の外部シンボルを参照できます。

B.2.42 -keeptmp

コンパイル中に作成される一時ファイルを自動的に削除しないで保持します。

B.2.43 -Ldir

ld(1) がライブラリを検索するディレクトリのリストに dir を付け加えます。このオプションとその引数は ld(1) に渡されます。

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

B.2.44 -lname;

オブジェクトライブラリlib name.so または libname .a をリンクの対象とします。シンボルは左から右へ解決されるため、コマンド行でのライブラリの指定順が重要になります。

このオプションはソースファイル引数のあとに指定してください。

B.2.45 -m32|-m64

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

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

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

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

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

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

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

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

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

B.2.46 -mc

オブジェクトファイルの .comment セクションから重複している文字列を削除します。-mc フラグを使用すると、mcs -c が起動されます。

B.2.47 -misalign

(SPARC) 廃止。このオプションは使わないでください。代わりに -xmemalign=1i オプションを使ってください。詳細は、「B.2.116 -xmemalign=ab」を参照してください。「A.1.15 廃止オプション」に、廃止のオプションの全一覧をまとめています。

B.2.48 -misalign2

(SPARC) 廃止。このオプションは使わないでください。代わりに -xmemalign=2i オプションを使ってください。詳細は、「B.2.116 -xmemalign=ab」を参照してください。「A.1.15 廃止オプション」に、廃止のオプションの全一覧をまとめています。

B.2.49 -mr[, string]

-mr は、.comment セクションからすべての文字を削除します。このフラグを使用すると、mcs -d -a が呼び出されます。

-mr, string はオブジェクトファイルの .comment セクションからすべての文字列を削除して、string を挿入します。string に空白が含まれている場合は二重引用筆囲みます。string がなければ .comment セクションは空になります。このオプションは -d -string として mcs に渡されます。

B.2.50 -mt[={ yes|no}]

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

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

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

Linux プラットフォーム上では、POSIX スレッドの API のみが使用できます (Linux プラットフォームには libthread はありません)。したがって、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.50.1 関連項目

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

B.2.51 -native

このオプションは、-xtarget=native と同義です。

B.2.52 -nofstore

(x86)浮動小数点式または関数がある変数に代入されるか、より小さい型の浮動小数点にキャストされる場合に、代入値の左側に表記される型に変換せずに、コンパイラがその値をレジスタに残すようにします。「B.2.31 -fstore」も参照してください。

B.2.53 -O

デフォルトの最適化レベルの -xO3 を使ってください。このリリースでは、-O は、-xO2 ではなく、-xO3 に展開されます。

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

B.2.54 -o filename

出力ファイルに、デフォルトの a.out の代わりに filename という名前を付けます。cc はソースファイルに上書きしないので、filename には ソースファイル と同じ名前は使用できません。このオプションとその引数は ld(1) に渡されます。

B.2.55 -P

ソースファイルのプリプロセッサ処理のみを行います。.i 接尾辞の付いたファイルに結果を出力します。-E オプションと異なり、出力ファイルに C のプリプロセッサ行番号付け情報は含まれません。-E オプションも参照してください。

B.2.56 -p

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

B.2.57 -Q[y|n]

出力ファイルに識別情報を入れるかどうかを設定します。デフォルトは -Qy です。

-Qy を指定すると、起動した各コンパイラツールの識別情報が出力ファイルの .comment 部分に追加され、mcs でのアクセスが可能になります。これはソフトウェア管理に役立ちます。

-Qn を指定すると、この情報が抑制されます。

B.2.58 -qp

-pと同じです。

B.2.59 -Rdir[:dir]

コロンで区切られたディレクトリのリストを、ライブラリ検索ディレクトリとして、実行時リンカーに渡します。リストが空でなければ、出力オブジェクトファイルに記録され、実行時リンカーに渡されます。

LD_RUN_PATH と -R オプションの両方が指定されたときは、この -R オプションが優先されます。

B.2.60 -S

cc to アセンブリソースファイルを作成しますが、アセンブルは行いません。

B.2.61 -s

出力されるオブジェクトファイルからシンボリックデバッグのための情報をすべて削除します。このオプションは、-g とともに指定することはできません。

ld(1) へ引き渡します。

B.2.62 -traceback[={ %none|common|signals_list}]

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

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

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

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

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

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

% limit coredumpsize 0            

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

B.2.63 -Uname;

プリプロセッサシンボル 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]」 を参照してください。

B.2.64 -V

コンパイラの実行時に cc によって各構成要素の名前とバージョン番号を表示します。

B.2.65 -v

より厳しい意味検査およびほかの 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 で前述の例を実行すると確認することができます。

B.2.66 -Wc,arg

指定されたコンパイラ構成要素 c に、arg を渡します。コンポーネントのリストについては、表 1–1 を参照してください。

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

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

そのほかのコマンド行オプションで引数がツールに渡される順番は、変更されることがあります。

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

B.2.67 -w

コンパイラからの警告メッセージを出力しません。

このオプションは error_messages プラグマを無効にします。

B.2.68 -X[c|a|t|s]

-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 Library (SPARC)」を参照してください。

デフォルトのモードは -Xa です。

-Xc

(c = conformance) ISO C にない言語構造を使用しているプログラムに対してエラーや警告を発行します。このオプションは ISO C に最大限に準拠するもので、K&R C との拡張互換性はありません。--Xc オプションを指定すると事前定義されたマクロ _ _STDC_ _ の値は 1 になります。

-Xa

これは、コンパイラのデフォルトのモードです。ISO C に K&R C との拡張互換性を持たせます。ISO C に従うように意味処理を変更します。同じ言語構造に対して ISO C と K&R 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__ は定義されません。

B.2.69 -x386

(x86) 廃止。このオプションは使わないでください。代わりに、-xchip=generic を使用してください。「A.1.15 廃止オプション」に、廃止のオプションの全一覧をまとめています。

B.2.70 -x486

(x86) 廃止。このオプションは使わないでください。代わりに、-xchip=generic を使用してください。「A.1.15 廃止オプション」に、廃止のオプションの全一覧をまとめています。

B.2.71 -xaddr32[=yes|no]

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

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

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

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

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

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

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

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

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

B.2.72 -xalias_level[= l]

コンパイラで -xalias_level オプションを使用して、型に基づく別名の解析による最適化でのレベルを指定します。このオプションは、コンパイル対象の変換ユニットで、指定した別名レベルを有効にします。

-xalias_level コマンドを発行しない場合、コンパイラは -xalias_level=any を仮定します。値を設定しないで -xalias_level を指定する場合、デフォルトは -xalias_level=layout になります。

-xalias_level オプションを使用するには、-xO3 以上の最適化レベルが必要です。最適化がこれよりも低く設定されている場合は、警告が表示され、-xalias_level オプションは無視されます。

-xalias_level オプションを発行しても、別名レベルごとに記述されている規則と制限を遵守しない場合、プログラムが未定義の動作をします。

l を次の表のいずれかの用語で置き換えます。

B.2.73 - xannotate[=yes|no]

(Solaris) binopt(1) のようなバイナリ変更ツールを使用してあとで変換できるバイナリを作成するようコンパイラに指示します。これらのツールによるバイナリファイルの変更を防止するには、-xannotate=no オプションを使用します。-xannotate=yes オプションを有効にするには、最適化レベル -xO1 以上で使用する必要があります。

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

B.2.74 -xarch=isa

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

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

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

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

B.2.74.1 SPARC での -xarch のフラグ

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

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

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

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

B.2.74.2 x86 での -xarch のフラグ

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

B.2.74.3 x86 の特記事項

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

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

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

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

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

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

B.2.74.4 バイナリの互換性の妥当性検査

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

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

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

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

B.2.74.5 相互の関連性

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

B.2.74.6 警告

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

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

B.2.75 -xautopar

このオプションは OpenMP の並列化命令を有効にしません。

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

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

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

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

-xautopar を使用してコンパイルとリンクを 1 度に実行する場合、リンクには自動的にマイクロタスキングライブラリおよびスレッドに対して安全な C 実行時ライブラリが含まれます。-xautopar を使用してコンパイルとリンクを別々に実行する場合、リンクにも -xautopar を指定しなければいけません。表 A–2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。

B.2.76 -xbinopt={prepare| off}

(SPARC) あとで最適化、変換、分析を行うために、バイナリを準備します。binopt(1) を参照してください。このオプションは、実行可能ファイルまたは共有オブジェクトの構築に使用できます。このオプションを有効にするには、最適化レベル -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 です。

B.2.77 -xbuiltin[=( %all|%none)]

標準ライブラリ関数を呼び出すコードをさらに最適化する場合、-xbuiltin[=(%all| %none)] コマンドを使用します。多くの標準ライブラリ関数 (math.h、stdio.h で定義された関数など) は、さまざまなプログラムで一般的に使用されます。このコマンドを使用すると、コンパイラは、パフォーマンス向上の見込める場所で組み込み関数またはインラインシステム関数を代用します。オブジェクトファイル内のコンパイラのコメントからコンパイラが実際に置換を行う関数を特定する方法については、er_src(1) のマニュアルページを参照してください。

ただし、こうした置換によって errno の値の信頼性が失われることがあります。プログラムが errno の値に依存している場合、このオプションの使用は避けてください。「2.13 errno の値の保持」も参照してください。

-xbuiltin を指定しない場合は、デフォルトは -xbuiltin=%none になります。この場合は、標準ライブラリの関数の代替やインライン化は行われません。-xbuiltin を引数なしで指定した場合は、デフォルトは -xbuiltin%all になります。この場合は、最適化に有効と判断されるときには、組込型関数の代替や標準ライブラリの関数のインライン化が実行されます。

-fast を指定してコンパイルする場合は、-xbuiltin は %all になります。

-xbuiltin は、システムのヘッダーファイルで定義された大域関数だけをインライン化します。ユーザー定義の静的関数はインライン化しません。

B.2.78 -xCC

-xc99=none および -xCC を指定した場合は、コンパイラで C++ 形式のコメントが認識されます。このオプションを使用すると、// を使用してコメントの始まりを示すことができます。

B.2.79 -xc99[= o]

-xc99 オプションは、C99 規格 (『Programming Language - C (ISO/IEC 9899:1999)』) からの実装機能に対するコンパイラの認識状況を制御します。

o には、次の項目をコンマで区切って指定します。

-xc99 を指定しない場合は、コンパイラではデフォルトで -xc99=all,no_lib が設定されます。値を指定しないで -xc99 を指定すると、オプションは -xc99=all に設定されます。

コンパイラのサポートレベルは、デフォルトでは C99 規格の言語機能になりますが、Solaris 8 および Solaris 9 オペレーティングシステムが提供している標準のヘッダーファイル (/usr/include にある) は、1999 ISO/IEC C 規格に準拠していません。エラーメッセージが生成される場合は、-xc99=none を指定して、前述のヘッダー用に 1990 ISO/IEC C 規格を使用してみてください。

1990 C 規格と 1999 C 規格の両方にあるルーチンの 1999 C 標準ライブラリ意味処理は、Solaris 8 および Solaris 9 ソフトウェアで使用できず、このため有効にすることはできません。Solaris 8 または 9 で直接または間接に -xc99=lib が指定された場合は、エラーメッセージが発行されます。

B.2.80 -xcache[= c]

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

このオプションは単独で指定できますが、-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 の各特性の定義は次のとおりです。

次に、-xcache の値を示します。

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

B.2.81 –xcg[89|92]

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

B.2.82 -xchar[= o]

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

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

B.2.83 -xchar_byte_order[= o]

複数文字からなる定数である文字を指定されたバイト順序で配置することにより、整定数を生成します。o には、次のいずれかを指定します。

• low: 複数文字定数の文字を低いバイトから順に配置する

• high: 複数文字定数の文字を高いバイトから順に配置する

• default: 複数文字定数の文字を、コンパイルモード 「B.2.68 -X[c|a|t|s]」 で決定された順に配置する。詳細は、「2.1.2 文字定数」を参照してください。

B.2.84 -xcheck[= o]

スタックオーバーフローに関する実行時検査を追加し、ローカル変数を初期化します。

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

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

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

B.2.84.1 —xcheck=init_local の初期化値

—xcheck=init_local を指定すると、次の表に示すように、コンパイラは初期設定子を指定しないで宣言されたローカル変数を事前定義された値に初期化します (これらの値は変更される可能性があるため、信頼しないでください)。

基本型

計算された goto で使用するために宣言されたローカル変数 (単純な void * ポインタ) は、上の表に示されたポインタの説明に従って初期化されます。

ローカル変数の型である修飾された const、register、計算された goto のラベル番号、ローカルラベル、可変長配列 (VLA) は初期化されません。

構造体、共用体、配列の初期化

基本型である struct のフィールドは、union の最初に宣言された pointer または float フィールドのように、上の表で説明されているとおりに初期化されます。この結果、未初期化の参照により目に見えるエラーが生成される可能性が最大になります。

配列要素も上の表で説明されているとおりに初期化されます。

入れ子の struct、union、配列フィールドは、ビットフィールドを含む struct、pointer または float フィールドのない union、または完全に初期化できない型の配列を除いて、上で説明されているとおりに初期化されます。これらは、double 型のローカル変数に使用される値を使用して初期化されます。可変長配列は初期化されません。

B.2.85 -xchip[= c]

オプティマイザ用のプロセッサを指定します。

c には次のいずれかを指定します。generic、old、super、super2、micro、micro2、hyper、hyper2、powerup、ultra、 ultra2、ultra2e、ultra2i、ultra3、ultra3cu、pentium、pentium_pro

このオプションは単独でも使用できますが、-xtarget オプションが展開されたものの一部です。このオプションの主な目的は、-xtarget オプションにより指定される値を変更することです。

このオプションは、処理対象となるプロセッサを指定することによって、タイミング特性を指定します。xchip=c は次のものに影響を与えます。

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

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

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

次の表は、SPARC プラットフォーム向けの -xchip の値をまとめています。

次の表は、x86 プラットフォーム向けの -xchip の値をまとめています。

B.2.86 -xcode[= v]

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

-xcode=pic13 または -xcode=pic32 を指定して共有オブジェクトを構築することを推奨します。-xarch=v9 -xcode=abs64 と -xarch=v8 -xcode=abs32 を指定して有効な共有オブジェクトを構築することは可能ですが、効率は悪くなります。-xarch=v9 や -xcode=abs32 または -xarch=v9、-xcode=abs44 を指定して構築した共有オブジェクトは機能しません。

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

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

• 実行可能ファイルを構築する場合は、-xcode=pic13 と -xcode=pic32 のどちらも使わない。

• 実行可能ファイルへのリンク専用のアーカイブライブラリを構築する場合は、-xcode=pic13 と -xcode=pic32 のどちらも使わない。

• 共有ライブラリを構築する場合は、-xcode=pic13 からスタートし、GOT のサイズが 8,192 バイトを超えたら、-xcode=pic32 を使用する。

• 共有ライブラリへのリンク用のアーカイブライブラリを構築する場合は、-xcode=pic32 のみ使用する。

B.2.87 -xcrossfile

廃止。使用しないでください。代わりに -xipo を使用します。—xcrossfile は —xipo=1 の別名です。

B.2.88 -xcsi

C コンパイラが ISO C ソース文字コードの要件に準拠しないロケールで記述されたソースコードを受け付けられるようにします。これらのロケールには、 ja_JP.PCK があります。

コンパイラの翻訳段階でこのようなロケールの処理が必要になると、コンパイルの時間が非常に長くなることがあります。そのため、このオプションを使用するのは、前述のロケールのソース文字を含むソースファイルをコンパイルする場合に限定すべきです。

コンパイラは、-xcsi が発行されないかぎり、ISO C ソース文字コードの要件に準拠しないロケールで記述されたソースコードを認識しません。

B.2.89 -xdebugformat=[stabs|dwarf]

dwarf 形式のデバッグ情報を読み取るソフトウェアを保守している場合は、-xdebugformat=dwarf を指定します。このオプションを使用すると、コンパイラは dwarf 標準形式を使用してデバッグ情報を生成します。これがデフォルトです。

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

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

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

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

B.2.90 -xdepend=[yes| no]

ループの繰り返し内部でのデータ依存性を解析し、ループの交換、ループの融合、スカラー置換などの再構成をループします。

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

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

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

B.2.91 -xdryrun

このオプションは -### のマクロです。

B.2.92 -xe

ソースファイル上で構文および意味検査のみを行います。オブジェクトコードや実行可能コードは生成しません。

B.2.93 -xF[=v[, v...]]

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

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

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

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

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

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

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

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

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

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

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

B.2.93.1 値

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

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

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

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

B.2.94 -xhelp=f

オンラインヘルプ情報を表示します。

f には、flags または readme を指定してください。

-xhelp=flags は、コンパイラオプションの要約を表示します。

-xhelp=readme は、README ファイルを表示します。

B.2.95 -xhwcprof

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

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

指定した一連のオブジェクトファイルは、-xhwcprof を指定してコンパイルできます。ただし、-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

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

B.2.96 -xinline=list

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= だけを指定した場合は、ソースファイル中のルーチンはいずれもインライン化されません。リストで func_name および no%func_name を %auto なしで指定した場合は、リストで指定した関数のオンラインオプションだけが試行されます。最適化レベルが -xO4 以上のときに、-xinline オプションのリストで %auto を指定した場合は、no%func_name で明示的に除外していない関数がすべてインライン化されます。

次のいずれかの条件に該当する場合、ルーチンはインライン化されません。警告は出力されませんので注意してください。

• 最適化のレベルが -xO3 未満である。

• ルーチンが見つからない。

• iropt がルーチンのインライン化を実行できない。

• ルーチンのソースが、コンパイル対象のファイルにない (-xcrossfile を参照)。

コマンド行で -xinline を複数指定した場合は、それらは累積されません。コマンド行で最後に指定した -xinline によって、コンパイラがインライン化する関数が決定されます。

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

B.2.97 -xinstrument=[ no%]datarace

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

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

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

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

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

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

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

B.2.98 -xipo[= a]

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 でコンパイルされたオブジェクトと自由にリンクできます。

B.2.98.1 例

次の例では、コンパイルとリンクが単一ステップで実行されます。

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 のルーチン間では実行されません。最初のコンパイルは未定義のシンボルに関する警告を生成する場合がありますが、内部手続きの最適化は、コンパイル手順でありしかもリンク手順であるために実行されます。

B.2.98.2 -xipo=2 による内部手続き解析を行うべきでないケース

内部手続き解析では、コンパイラは、リンクステップでオブジェクトファイル群を操作しながら、プログラム全体の解析と最適化を試みます。このとき、コンパイラは、このオブジェクトファイル群に定義されているすべての 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() 内にインライン化され、不正な結果になる可能性があります。

B.2.99 -xipo_archive=[a]

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

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

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

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

B.2.100 -xjobs=n

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

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

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

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

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

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

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

B.2.101 -xldscope={v}

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 を独自の allocator と置き換える場合、置き換えられた allocator は ABC_allocator を呼び出したライブラリ構成要素内では実行されません。最終的なプログラムには、この関数の相異なるバージョンが含まれることになります。

__hidden 指示子または __symbolic 指示子で宣言されたライブラリ関数は、ライブラリの構築時にインラインで生成することができます。これらの関数がクライアントからオーバーライドされることは、サポートされていません。「2.2 リンカースコープ指示子」を参照してください。

__global 指示子で宣言されたライブラリ関数はインラインで宣言しないでください。また、-xinline コンパイラオプションを使用することによってインライン化されることがないようにしてください。

-xinline、-xO、-xcrossfile、#pragma inline も参照してください。

B.2.102 -xlibmieee

例外が起きた場合の数学ルーチンの戻り値を強制的に IEEE 754 形式にします。この場合、例外メッセージは表示されないので、errno には依存しないでください。

B.2.103 -xlibmil

実行速度を上げるため、一部のライブラリルーチンをインライン化します。オプションによって浮動小数点演算用オプションとプラットフォームに適したアセンブリ言語のインラインテンプレートが選択されます。

-xlibmil は、-xinline フラグで関数を指定しているかどうかに関係なく、関数をインライン化します。

ただし、こうした置換によって errno の値の信頼性が失われることがあります。プログラムが errno の値に依存している場合、このオプションの使用は避けてください。「2.13 errno の値の保持」も参照してください。

B.2.104 -xlibmopt

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

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

ただし、こうした置換によって errno の値の信頼性が失われることがあります。プログラムが errno の値に依存している場合、このオプションの使用は避けてください。「2.13 errno の値の保持」も参照してください。

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

このオプションは -fast オプションを指定した場合にも設定されます。

関連項目: -fast -xnolibmopt

B.2.105 -xlic_lib=sunperf

指定された Solaris Studio 提供のパフォーマンスライブラリにリンクします。

B.2.106 -xlicinfo

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

B.2.107 -xlinkopt[= レベル]

(SPARC) 再配置可能なオブジェクトファイルのリンク時の最適化を実行するようコンパイラに指示します。このような最適化は、リンク時にオブジェクトのバイナリコードを解析することによって実行されます。オブジェクトファイルは書き換えられませんが、最適化された実行可能コードは元のオブジェクトコードとは異なる場合があります。

-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

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

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

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

B.2.108 -xloopinfo

並列化されているループとされていないループを示します。また、ループを並列化しない理由を簡単に説明します。-xloopinfo オプションは、-xautopar が指定されている場合にのみ有効です。指定されていない場合は、コンパイラによって警告が表示されます。

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

B.2.109 -xM

指定した 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 で指定したファイルに、コンパイラはすべてのメイクファイルの依存関係情報を追加します。

B.2.110 -xM1

-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 で指定したファイルに、コンパイラはすべてのメイクファイルの依存関係情報を追加します。

B.2.111 -xMD

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

B.2.112 -xMF filename

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

B.2.113 -xMMD

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

B.2.114 -xMerge

データセグメントをテキストセグメントにマージします。このコンパイルで生成するオブジェクトファイルで初期化されるデータは読み取り専用なので、ld -N でリンクしていないかぎり、プロセスどうしで共有することができます。

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

B.2.115 -xmaxopt[=v]

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

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

B.2.116 -xmemalign=ab

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

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

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

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

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

-xmemalign オプションを使用すると、このような判別不可能な状況の時にコンパイラが想定するデータの最大メモリー境界整列を指定できます。-xmemalign オプションは、境界整列に失敗したメモリーへのアクセスが実行時に発生した場合に行われるエラー動作 (処理) についても指定できます。

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

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

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

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

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

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

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

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

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

B.2.117 -xmodel=[a]

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

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

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

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

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

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

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

B.2.118 -xnolib

デフォルトのライブラリリンクを行いません。つまり ld(1) に -l オプションを渡しません。通常は、cc ドライバが -lc を ld に渡します。

-xnolib を使用する場合、すべての -l オプションをユーザーが渡さなければいけません。

B.2.119 -xnolibmil

数学ライブラリのルーチンをインライン化しません。このオプションは -fast オプションのあとに指定してください。次に例を示します。

% cc– fast– xnolibmil....

B.2.120 -xnolibmopt

前に -xlibmopt オプションが指定されている場合にその指定を無効にして、最適化された数学ライブラリをコンパイラが使用しないようにします。このオプションは、-xlibmopt を設定することによって最適化された数学ライブラリを使用可能にする -fast のあとで使用してください。

% cc -fast -xnolibmopt ...

B.2.121 -xnorunpath

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

通常、cc は -R パスをリンカーにまったく渡しません。オプションの中には、-xliclib=sunperf および -xopenmp のように、-R パスをリンカーに渡すものがあります。-xnorunpath を使用すると、パスが渡されなくなります。

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

B.2.122 -xO[1|2| 3|4|5]

オブジェクトコードを最適化します。大文字 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 つの関数内のコードが数千行になるような) 大きな関数を最適化する場合、膨大な量の仮想メモリーが必要になり、マシンのパフォーマンスが低下することがあります。

B.2.122.1 SPARC での最適化について

次の表は、SPARC プラットフォームでの最適化処理について説明しています。

B.2.122.2 x86 での最適化について

次の表は、x86 プラットフォームでの最適化処理について説明しています。

デバッグについての詳細は、『『Solaris Studio: dbx コマンドによるデバッグ』』を参照してください。最適化についての詳細は、『『Solaris Studio 12: パフォーマンスアナライザ』』マニュアルを参照してください。

-xldscope および -xmaxopt も参照してください。

B.2.123 -xopenmp[= i]

OpenMP 指令で明示的な並列化を有効にするには、-xopenmp オプションを使用します。並列化されたプログラムをマルチスレッド環境で実行するには、実行前に OMP_NUM_THREADS 環境変数を設定しておく必要があります。

入れ子並列を有効にするには、OMP_NESTED 環境変数を TRUE に設定する必要があります。入れ子並列は、デフォルトでは無効です。

次の表に i の値を示します。

-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 の詳細は、『Solaris Studio OpenMP API ユーザーズガイド』を参照してください。

B.2.124 -xP

すべての K&R C 関数のプロトタイプを出力する際、コンパイラはソースファイルに対して構文および意味検査のみ行います。このオプションは、オブジェクトコードや実行可能コードを生成しません。たとえば次のソースファイルに -xP を指定したと仮定します。

f()
{
}

main(argc,argv)
int argc;
char *argv[];
{
}

この例に対しては、次のとおりに出力します。

int f(void);
int main(int, char **);

B.2.125 -xpagesize=n

スタックとヒープ用の優先ページサイズを設定します。

SPARC では、次の値が有効です。4k、8K、64K 、512K、2M、4M、 32M、256M、2G、16G、または default。

次の値は、86/x で有効です。4K、2M、4M、1G、または default。

有効なページサイズを指定しないと、要求は実行時に暗黙的に無視されます。ターゲットプラットフォームに対して有効なページサイズを指定する必要があります。

Solaris オペレーティングシステムでページのバイト数を調べるには、getpagesize(3C) コマンドを使用します。Solaris オペレーティングシステムでは、ページサイズ要求に従うという保証はありません。ターゲットプラットフォームのページサイズを判断するには、pmap(1) または meminfo(2) を使用します。

ターゲットプラットフォームのページサイズを判断するには、 pmap(1) または meminfo(2) を使用します。

-xpagesize オプションは、コンパイル時とリンク時に使用しないかぎり無効です。表 A–2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。

-xpagesize=default を指定すると、Solaris オペレーティングシステムがページサイズを設定します。

このオプションを指定してコンパイルするのは、LD_PRELOAD 環境変数を同等のオプションで mpss.so.1 に設定するか、またはプログラムを実行する前に同等のオプションを指定して Solaris コマンドの ppgsz(1) を実行するのと同じことです。詳細は Solaris のマニュアルページを参照してください。

このオプションは -xpagesize_heap と -xpagesize_stack のマクロです。これらの 2 つのオプションは -xpagesize と同じ次の引数を使用します。両方に同じ値を設定するには -xpagesize を指定します。別々の値を指定するには個々に指定します。

B.2.126 -xpagesize_heap=n

ヒープ用のメモリーページサイズを設定します。

このオプションは、—xpagesize と同じ値を受け入れます。有効なページサイズを指定しないと、要求は実行時に暗黙的に無視されます。

Solaris オペレーティングシステムでページのバイト数を調べるには、getpagesize(3C) コマンドを使用します。Solaris オペレーティングシステムでは、ページサイズ要求に従うという保証はありません。ターゲットプラットフォームのページサイズを判断するには、pmap(1) または meminfo(2) を使用します。

ターゲットプラットフォームのページサイズを判断するには、pmap(1) または meminfo(2) を使用します。

-xpagesize_heap=default を指定すると、Solaris オペレーティングシステムはページサイズを設定します。

このオプションを指定してコンパイルするのは、LD_PRELOAD 環境変数を同等のオプションで mpss.so.1 に設定するか、またはプログラムを実行する前に同等のオプションを指定して Solaris コマンドの ppgsz(1) を実行するのと同じことです。詳細は Solaris のマニュアルページを参照してください。

-xpagesize_heap オプションは、コンパイル時とリンク時に使用しないかぎり無効です。表 A–2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。

B.2.127 -xpagesize_stack=n

スタック用のメモリーページサイズを設定します。

このオプションは、—xpagesize と同じ値を受け入れます。有効なページサイズを指定しないと、要求は実行時に暗黙的に無視されます。

Solaris オペレーティングシステムでページのバイト数を調べるには、getpagesize(3C) コマンドを使用します。Solaris オペレーティングシステムでは、ページサイズ要求に従うという保証はありません。ターゲットプラットフォームのページサイズを判断するには、pmap(1) または meminfo(2) を使用します。

-xpagesize_stack=default を指定すると、Solaris オペレーティングシステムはページサイズを設定します。

このオプションを指定してコンパイルするのは、LD_PRELOAD 環境変数を同等のオプションで mpss.so.1 に設定するか、またはプログラムを実行する前に同等のオプションを指定して Solaris コマンドの ppgsz(1) を実行するのと同じことです。詳細は Solaris のマニュアルページを参照してください。

-xpagesize_stack オプションは、コンパイル時とリンク時に使用しないかぎり無効 です。表 A–2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。

B.2.128 -xpch=v

このコンパイラオプションは、プリコンパイル済みヘッダー機能を起動します。v には、auto、autofirst、collect:pch_filename、use:pch_filename のいずれかを指定できます。この機能は、-xpch (「B.2.128 -xpch=v」 で詳述) と -xpchstop (「B.2.129 -xpchstop=[file|<include>]」 で詳述) オプションで、#pragma hdrstop 指令 (「2.11.8 hdrstop」 で詳述) と組み合わせて利用できます。

-xpch オプションは、プリコンパイル済みヘッダーファイルを作成して、コンパイル時間を短縮するときに使用します。プリコンパイル済みヘッダーファイルは、ソースファイルが大量のソースコードを含む共通のインクルードファイル群を共有しているようなアプリケーションのコンパイル時間を低減するよう設計されています。プリコンパイル済みヘッダーを使用することによって、1 つのソースファイルから一連のヘッダーファイルに関する情報を収集し、そのソースファイルを再コンパイルする場合や、同じ一連のヘッダーを持つほかのソースファイルをコンパイルする場合に、その情報を使用することができます。コンパイラが収集する情報は、プリコンパイル済みヘッダーファイルに格納されます。

関連項目

• 「B.2.129 -xpchstop=[file|<include>]」

• 「2.11.8 hdrstop」

B.2.128.1 プリコンパイル済みヘッダーファイルの自動作成

プリコンパイル済みヘッダーファイルをコンパイラに自動的に生成させることができます。このためには、次のいずれかの方法を選択します。1 つは、ソースファイルで検出された最初のインクルードファイルからプリコンパイル済みヘッダーファイルを作成する方法、もう 1 つは、最初のインクルードファイルから、最後のインクルードファイルを特定する綿密に定義された地点までの間にソースファイルで検出されたインクルードファイル群から選択してプリコンパイル済みヘッダーファイルを作成する方法です。次の 2 つのフラグのいずれかを使用して、プリコンパイル済みヘッダーの自動生成にコンパイラが使用すべき方法を指示します。

B.2.128.2 プリコンパイル済みヘッダーファイルの手動作成

プリコンパイル済みヘッダーファイルを手動で作成する場合は、最初に -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 という名前が付けられます。

B.2.128.3 既存のプリコンパイル済みヘッダーファイルの処理方法

-xpch=auto または -xpch=autofirst のときにプリコンパイル済みヘッダーファイルを使用できない場合、コンパイラは新しいプリコンパイル済みヘッダーファイルを生成します。-xpch=use のときにプリコンパイル済みヘッダーファイルを使用できない場合は、警告が発行され、実際のヘッダーを使ってコンパイルが行われます。

B.2.128.4 特定のプリコンパイル済みヘッダーファイルの使用の指定

特定のプリコンパイル済みヘッダーファイルを使用するようコンパイラに指示することもできます。このためには、-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 で指定するファイル内の前処理指令のシーケンスと同じであること。

B.2.128.5 活性文字列 (Viable Prefix)

プリコンパイル済みヘッダーファイルを複数のソースファイル間で共有するために、これらのソースファイルには、最初のトークンの並びとして一連の同じインクルードファイルを使用していなければいけません。トークンはキーワードか名前、句読点のいずれかです。コンパイラは、コードおよび、#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 の場合は、各指令は同じ値を参照しなければいけません)。各活性文字列内での順序も同じである必要があります。対応する各プラグマも同じで、その順序もプリコンパイル済みヘッダーを共有するすべてのファイルで同じでなければいけません。

B.2.128.6 ヘッダーファイルの妥当性の判定

ヘッダーファイルがプリコンパイル可能となる条件。それは、複数のソースファイルに渡ってヘッダーファイルの一貫した解釈ができることです。具体的には、完全な宣言だけが含まれていることです。すなわち、どのファイルの宣言も有効な宣言として独立している必要があります。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が含まれていてはいけません。

ヘッダーに変数と関数の宣言が含まれている場合は、ヘッダーも同様にプリコンパイル可能です。

B.2.128.7 プリコンパイル済みヘッダーファイルのキャッシュ

プリコンパイル済みヘッダーファイルの自動作成では、コンパイラは、そのファイルを SunWS_cache ディレクトリに書き込みます。このディレクトリは常に、オブジェクトファイルが作成される場所に置かれます。dmake の下で適切に機能するように、ファイルの更新はロックして行われます。

強制的に再構築させる必要がある場合は、CCadmin ツールを使って、このプリコンパイル済みヘッダーファイルのキャッシュディレクトリをクリアすることができます。詳細は、CCadmin(1) のマニュアルページを参照してください。

B.2.128.8 警告

• 矛盾する -xpch フラグをコマンド行に指定しないでください。たとえば、-xpch=collect と -xpch=auto の両方を指定したり、-xpchstop=<include> を付けて -xpch=autofirst を指定したりすると、エラーになります。

• -xpch=autofirst を指定するか、-xpchstop なしで -xpch=auto を指定した場合、最初のインクルードファイル、あるいは -xpch=auto に -xpchstop を付けて指定したインクルードファイルの前に宣言や定義、#line 指令があると、エラーになり、プリコンパイル済みヘッダーファイルの自動生成が無効になります。

• -xpch=autofirst または -xpch=auto で、最初のインクルードファイルの前に #pragma hdrstop があると、プリコンパイル済みヘッダーファイルの自動生成が無効になります。

B.2.128.9 プリコンパイル済みヘッダーファイルの依存関係と make ファイル

-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 規則を作成する必要はありません。

B.2.129 -xpchstop=[file|<include>]

-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 も参照してください。

B.2.130 - xpec[={yes|no}]

移植可能な実行可能コード (Portable Executable Code、PEC) バイナリを生成します。PEC バイナリは、自動チューニングシステム (Automatic Tuning System、ATS) と組み合わせて使用できます。ATS はチューニングとトラブルシューティングの目的で、コンパイル済み PEC バイナリを再構築する方法で動作し、下のソースコードは必要ありません。ATS の詳細は、http://cooltools.sunsource.net/ を参照してください。

-xpec を指定して構築したバイナリは通常、-xpec なしで構築したバイナリより 5 ～ 10 倍の大きさになります。

-xpec を指定しない場合は、-xpec=no に設定されます。-xpec をフラグなしで指定した場合は、コンパイラでは -xpec=yes が指定されます。

B.2.131 -xpentium

(x86) Pentium プロセッサ用のコードを生成します。

B.2.132 -xpg

gprof(1) によるプロファイルの準備として、データを収集するためのオブジェクトコードを生成します。この記録機構は実行が正常終了すると、gmon.outファイルを作成します。

-xpg を指定した場合、-xprofile を使用する利点はありません。 これら 2 つは、他方で使用できるデータを生成せず、他方で生成されたデータを使用できません。

プロファイルは、64 ビット Solaris プラットフォームで prof(1) または gprof(1)、32 ビット Solaris プラットフォームで gprof を使用して生成され、おおよそのユーザー CPU 時間が含まれます。これらの時間は、メインの実行可能ファイルのルーチンと、実行可能ファイルをリンクするときにリンカー引数として指定した共有ライブラリのルーチンの PC サンプルデータ (pcsample(2) を参照) から導出されます。そのほかの共有ライブラリ (dlopen(3DL) を使用してプロセスの起動後に開かれたライブラリ) のプロファイルは作成されません。

32 ビット Solaris システムの場合、prof(1) を使用して生成されたプロファイルには、実行可能ファイルのルーチンだけが含まれます。32 ビット共有ライブラリのプロファイルは、-xpg で実行可能ファイルをリンクし、 gprof(1) を使用することで作成できます。

x86 システムでは、-xpg には -xregs=frameptr との互換性がないため、これらの 2 つのオプションは同時に使用できません。 -xregs=frameptr は -fast に含まれている点にも注意してください。

Solaris 10 ソフトウェアには、 -p でコンパイルされたシステムライブラリが含まれません。その結果、Solaris 10 プラットフォームで収集されたプロファイルには、システムライブラリルーチンの呼び出し回数が含まれません。

コンパイル時に -xpg を指定した場合は、リンク時にも指定する必要があります。「A.1.2 コンパイル時とリンク時のオプション」に、コンパイル時とリンク時の両方に指定する必要があるオプションの全一覧をまとめています。

B.2.133 -xprefetch[= val[,val]]

先読みをサポートするアーキテクチャーで先読み命令を有効にします。

明示的な先読みは、測定値によってサポートされた特殊な環境でのみ使用すべきです。

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

デフォルトは -xprefetch=auto,explicit です。基本的に非線形のメモリーアクセスパターンを持つアプリケーションには、このデフォルトが良くない影響をもたらします。デフォルトを無効にするには、-xprefetch=no%auto,no%explicit を指定します。

sun_prefetch.h ヘッダーファイルには、明示的な先読み命令を指定するためのマクロが含まれています。先読み命令は、実行コード中のマクロの位置にほぼ相当するところに挿入されます。

B.2.133.1 先読み応答率

先読みの応答時間とは、先読み命令を実行してから先読みされたデータがキャッシュで利用可能となるまでのハードウェアの遅延のことです。

係数には、n.n. という形式の正の数値を使用します。

コンパイラは、先読み命令と先読みされたデータを使用するロードまたはストア命令の距離を決定する際に先読み応答時間の値を想定します。先読みからロードまでのデフォルト応答時間は、先読みからストアまでのデフォルト応答時間と同じでない場合があります。

コンパイラは、幅広いマシンとアプリケーションで最適なパフォーマンスを得られるように先読み機構を調整します。しかし、コンパイラの調整作業が必ずしも最適であるとはかぎりません。メモリーに負担のかかるアプリケーション、特に大型のマルチプロセッサでの実行を意図したアプリケーションの場合、先読みの応答時間の値を引き上げることにより、パフォーマンスを向上できます。この値を増やすには、1 よりも大きい係数を使用します。.5 ～ 2.0 の値を指定すると、ほとんどの場合は最大のパフォーマンスが実現されます。

外部キャッシュの中に完全に常駐するデータセットを持つアプリケーションの場合は、先読み応答時間の値を減らすことでパフォーマンスを向上できる場合があります。値を小さくするには、1 よりも小さな係数を使用します。

latx:factor サブオプションを使用するには、1.0 程度の係数から順にアプリケーションの性能テストを実行します。そのあと、テストの結果に応じて係数を増減し、パフォーマンステストを再実行します。係数の調整を継続し、最適なパフォーマンスに到達するまでパフォーマンステストを実行します。係数を小刻みに増減すると、しばらくはパフォーマンスに変化がなく、突然変化し、再び平常に戻ります。

B.2.134 -xprefetch_auto_type=a

ここで a は、 [no%]indirect_array_access です。

このオプションは、直接メモリーアクセスに対して先読み命令が生成されるのと同じ方法で、-xprefetch_level オプションが指示するループに対して間接先読み命令を生成するかどうかを制御します。

-xprefetch_auto_type の値が指定されていない場合、-xprefetch_auto_type=no%indirect_array_access に設定されます。

-xalias_level などのオプションは、メモリー別名を明確化する情報の生成に役立つため、間接プリフェッチ候補の計算の積極性に影響し、このため、自動的な間接プリフェッチの挿入が促進されることがあります。

B.2.135 -xprefetch_level=l

-xprefetch_level オプションを使用して、-xprefetch=auto で定義した先読み命令の自動挿入を調整することができます。l には 1、2、3 のいずれかを指定します。-xprefetch_level が高くなるほど、コンパイラはより攻撃的に、つまりより多くの先読み命令を挿入します。

-xprefetch_level に適した値は、アプリケーションでのキャッシュミス数によって異なります。-xprefetch_level の値を高くするほど、アプリケーションのパフォーマンスが向上する可能性が高くなります。

このオプションは、-xprefetch=auto を指定し、最適化レベルを 3 以上に設定し て、先読みをサポートするプラットフォーム (v8plus、v8plusa、 v9、v9a、v9b、generic64、native64) 用にコードを生成した場合にだけ有効です。

-xprefetch_level=1 を指定すると、先読み命令の自動生成が有効になります。-xprefetch_level=2 を指定すると、レベル 1 を上回る追加の生成が行われ、-xprefetch_level=3 を指定すると、レベル 1 を上回る追加の生成が行われます。

デフォルトは、-xprefetch=auto を指定した場合は -xprefetch_level=1 になります。

B.2.136 –xprofile=p

プロファイルのデータを収集したり、プロファイルを使用して最適化したりします。

p には、collect[ :profdir]、use[ :profdir]、または tcov[ :profdir] を指定する必要があります。

このオプションを指定すると、実行頻度のデータが収集されて実行中に保存されます。このデータを以降の実行で使用すると、パフォーマンスを向上させることができます。プロファイルの収集は、マルチスレッド対応のアプリケーションにとって安全です。すなわち、独自のマルチタスク (-mt) を実行するプログラムをプロファイリングすることで、正確な結果が得られます。このオプションは、最適化レベルを -xO2 かそれ以上に指定するときにのみ有効になります。コンパイルとリンクを別々の手順で実行する場合は、リンク手順とコンパイル手順の両方で同じ -xprofile オプションを指定する必要があります。

collect[: profdir]

実行頻度のデータを集めて保存します。のちに -xprofile=use を指定した場合にオプティマイザがこれを使用します。コンパイラによって文の実行頻度を測定するためのコードが生成されます。

-xMerge、-ztext、および -xprofile=collect を一緒に使用しないでください。-xMerge を指定すると、静的に初期化されたデータを読み取り専用記憶領域に強制的に配置します。 -ztext を指定すると、位置に依存するシンボルを読み取り専用記憶領域内で再配置することを禁止します。-xprofile=collect を指定すると、書き込み可能記憶領域内で、静的に初期化された、位置に依存するシンボルの再配置を生成します。

プロファイルディレクトリ名として profdir を指定すると、この名前が、プロファイル化されたオブジェクトコードを含むプログラムまたは共有ライブラリの実行時にプロファイルデータが保存されるディレクトリのパス名になります。profdir パス名が絶対パスではない場合、プログラムがオプション -xprofile=use:profdir でコンパイルされるときの現在の作業用ディレクトリの相対パスとみなされます。プロファイルディレクトリ名を指定しないと、プロファイルデータは、program.profile という名前のディレクトリに保存されます (program はプロファイル化されたプロセスのメインプログラムのベース名)。

例 [1]: プログラムが構築されたディレクトリと同じディレクトリにある 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

例 [2]: ディレクトリ/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

環境変数の SUN_PROFDATA と SUN_PROFDATA_DIR を設定して、-xprofile=collect を指定してコンパイルされたプログラムがどこにプロファイルデータを入れるかを制御できます。これらの環境変数を設定すると、-xprofile=collect データが $SUN_PROFDATA_DIR/$SUN_PROFDATA に書き込まれます。

これらの環境変数は、tcov で書き込まれたプロファイルデータファイルのパスと名前を tcov(1) マニュアルページの説明どおり、同様に制御指定します。これらの環境変数をまだ設定していない場合、プロファイルデータは現作業ディレクトリの profdir .profile に書き込まれます (profdir は実行ファイルの名前または -xprofile=collect: profdir フラグで指定された名前)。 profdir が .profile ですでに終了している場合、-xprofile では、profile が profdir に追加されません。プログラムを複数回実行すると、実行頻度データは profdir.profile ディレクトリに蓄積されていくので、以前の実行頻度データは失われません。

別々の手順でコンパイルしてリンクする場合は、-xprofile=collect を指定してコンパイルしたオブジェクトファイルは、リンクでも必ず -xprofile=collect を指定してください。

use[: profdir]

-xprofile=collect[: profdir] でコンパイルされたコードから収集された実行頻度データを使用して、プロファイル化されたコードが実行されたときに実行された作業用の最適化が行えます。profdir は、-xprofile=collect[: profdir] でコンパイルされたプログラムを実行して収集されたプロファイルデータを含むディレクトリのパス名です。

profdir パス名は省略可能です。 profdir が指定されていない場合、実行可能バイナリの名前が使用されます。-o が指定されていない場合、a.out が使用されます。 profdir が指定されていない場合、コンパイラは、profdir .profile/feedback、または a.out.profile/feedback を探します。次に例を示します。

demo: cc -xprofile=collect -o myexe prog.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[: profdir]

tcov(1) を使用する基本のブロックカバレッジ分析用の命令オブジェクトファイル。

オプションの profdir 引数を指定すると、コンパイラは指定された場所にプロファイルディレクトリを作成します。プロファイルディレクトリに保存されたデータは、tcov(1) または -xprofile=use:profdir を付けたコンパイラで使用できます。オプションの profdir パス名を省略すると、プロファイル化されたプログラムの実行時にプロファイルディレクトリが作成されます。プロファイルディレクトリに保存されたデータは、tcov(1) でのみ使用できます。プロファイルディレクトリの場所は、環境変数 SUN_PROFDATA および SUN_PROFDATA_DIR を使用して指定できます。

profdir で指定された場所が絶対パス名ではない場合、コンパイル時に、現在のオブジェクトファイルが作成されたディレクトリの相対パスとみなされます。いずれかのオブジェクトファイルに profdir を指定する場合は、同じプログラムのすべてのオブジェクトファイルに対して同じ場所を指定する必要があります。場所が profdir で指定されているディレクトリには、プロファイル化されたプログラムを実行するときにすべてのマシンからアクセスできる必要があります。プロファイルディレクトリはその内容が必要なくなるまで削除できません。コンパイラでプロファイルディレクトリに保存されたデータは、再コンパイルする以外復元できません。

例 [1]: 1 つ以上のプログラムのオブジェクトファイルが -xprofile=tcov:/test/profdata でコンパイルされる場合、/test/profdata.profile という名前のディレクトリがコンパイラによって作成されて、プロファイル化されたオブジェクトファイルを表すデータの保存に使用されます。実行時に同じディレクトリを使用して、プロファイル化されたオブジェクトファイルに関連付けられた実行データを保存できます。

例 [2]: myprog という名前のプログラムが -xprofile=tcov でコンパイルされ、ディレクトリ /home/joe で実行されると、実行時にディレクトリ /home/joe/myprog.profile が作成されて、実行時プロファイルデータの保存に使用されます。

B.2.137 -xprofile_ircache[=path]

(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

B.2.138 -xprofile_pathmap

(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 がオブジェクトファイルのパス名と一致しないことが確認されるまで、オブジェクトファイルのパス名と比較されます。

B.2.139 -xreduction

自動的な並列化を実行するときに、縮約の認識を有効にします。-xreduction は、-xautopar とともに指定する必要があります。それ以外の場合は、コンパイラが警告を発行します。

縮約の認識が有効な場合、コンパイラは内積、最大値発見、最小値発見などの縮約を並列化します。これらの縮約によって非並列化コードの場合とは、四捨五入の結果が異なります。

B.2.140 -xregs=r[, r…]

生成コード用のレジスタの使用法を指定します。

r には、次の 1 つまたは複数の項目をコンマで区切って指定します。appl, float,frameptr

サブオプションの前に no% を付けるとそのサブオプションは無効になります。

—xregs サブオプションは、特定のハードウェアプラットフォームでしか使用できません。

例: -xregs=appl,no%float

SPARC のデフォルトは -xregs=appl,float です。

x86 のデフォルトは -xregs=no%frameptr です。

x86 システムでは、-xpg には -xregs=frameptr との互換性がないため、これらの 2 つのオプションは同時に使用できません。 -xregs=frameptr は -fast に含まれている点にも注意してください。

アプリケーションにリンクする共有ライブラリ用のコードは、-xregs=no%appl,float を指定してコンパイルすることをお勧めします。少なくとも、共有ライブラリとリンクするアプリケーションがこれらのレジスタの割り当てを認識するように、共有ライブラリがアプリケーションレジスタを使用する方法を明示的に示す必要があります。

たとえば、大局的な方法で (重要なデータ構造体を示すためにレジスタを使用するなど) レジスタを使用するアプリケーションは、ライブラリと確実にリンクするため、-xregs=no%appl なしでコンパイルされたコードを含むライブラリがアプリケーションレジスタをどのように使用するかを正確に特定する必要があります。

B.2.141 -xrestrict[= f]

ポインタ値の関数引数を制限付き (restricted) ポインタとして扱います。f には、%all、%none、あるいは 1 つまたは複数の関数名をコンマで区切ったリストを指定します。例: {%all| %none|fn[,fn...]

関数リストの指定にこのオプションを入れると、指定された関数内のポインタ引数は制限付きとして扱われます。-xrestrict=%all を指定すると、C ファイル全体のすべてのポインタ引数が制限付きとして扱われます。詳細については、「3.8.2 制限付きポインタ」を参照してください。

このコマンド行オプションは独立して使用できますが、最適化時に使用するのがもっとも適しています。たとえば、次のようなコマンドを使用します。

%cc -xO3 -xrestrict=%all prog.c

このコマンドでは、ファイル prog.c 内のすべてのポインタ引数を制限付きポインタとして扱います。次のようなコマンド行があるとします。

%cc -xO3 -xrestrict=agc prog.c

このコマンドでは、ファイル prog.c 内の関数 agc のすべてのポインタ引数を制限付きポインタとして扱います。

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

B.2.142 -xs

オブジェクトファイルなしに dbx でデバッグできるようにします。

このオプションを指定すると、すべてのデバッグ情報が実行可能ファイルにコピーされます。dbx のパフォーマンスやプログラムの実行時のパフォーマンスにはあまり影響はありませんが、より多くのディスク容量が必要となります。

B.2.143 -xsafe=mem

(SPARC) コンパイラが記憶域保護違反が発生した場合を前提とできるようにします。

このオプションを使用すると、コンパイラでは SPARC V9 アークテクチャーで違反のないロード命令を使用できます。

アドレスの位置合わせが合わない、またはセグメンテーション侵害などの違反が発生した場合は違反のないロードはトラップを引き起こさないので、このオプションはこのような違反が起こる可能性のないプログラムでしか使用しないでください。ほとんどのプログラムではメモリーに関するトラップは起こらないので、大多数のプログラムでこのオプションを安全に使用できます。例外条件の処理にメモリーベースのトラップを明示的に使用するプログラムでは、このオプションは使用しないでください。

このオプションは、最適化レベルの -xO5 と、次のいずれかの値の -xarch を組み合わせた場合にだけ有効です。m32 と m64 の両方で sparc、sparcvis、-sparcvis2、または -sparcvis3。

B.2.144 -xsb

廃止。使わないでください。ソースブラウザ機能はもうサポートされていません。

B.2.145 -xsbfast

廃止。使わないでください。ソースブラウザ機能はもうサポートされていません。

B.2.146 -xsfpconst

接尾辞のない浮動小数点定数を、デフォルトの倍精度モードではなく、単精度で表します。-Xc と併用することはできません。

B.2.147 -xspace

コードサイズを増やすループの最適化や並列化を行いません。

例: コードサイズが増える場合は、ループの展開や並列化は行われません。

B.2.148 -xstrconst

このオプションは非推奨であり、将来のリリースで削除される可能性があります。 —xstrconst は —features=conststrings の別名です。

B.2.149 -xtarget=t

最適化の対象となる命令セットとシステムを指定します。

t には次の値のいずれかを指定します。native、generic、native64、 generic64、system-name。

-xtarget に指定する値は、-xarch、-xchip、-xcache の各オプションの値に展開されます。実行中のシステムで -xtarget=native の展開を調べるには、-xdryrun コマンドを使用します。

たとえば、-xtarget=sun4/15 は次と同じです。-xarch=v8a -xchip=micro -xcache=2/16/1。

特定のホストプラットフォームで -xtarget を展開した場合、そのプラットフォームでコンパイルすると -xtarget=native と同じ -xarch、-xchip、または -xcache 設定にならない場合があります。

対象となるハードウェア (コンピュータ) の正式な名前をコンパイラに指定した方がパフォーマンスが優れているプログラムもあります。プログラムのパフォーマンスが重要な場合は、対象となるハードウェアを正確に指定してください。これは特に、新しい SPARC プロセッサ上でプログラムを実行する場合に当てはまります。しかし、ほとんどのプログラムおよび廃止の SPARC システムではパフォーマンスの向上はわずかであるため、汎用的な指定方法で十分です。

B.2.149.1 SPARC プラットフォームの -xtarget の値

SPARC または UltraSPARC V9 での 64 ビット Solaris ソフトウェアのコンパイルは、-m64 オプションで指定します。-xtarget を指定し、native64 または generic64 以外のフラグを付ける場合は、-m64 オプションも次のように指定する必要があります。-xtarget=ultra ... -m64。この指定を行わない場合は、コンパイラは 32 ビットメモリーモデルを使用します。

B.2.149.2 x86 プラットフォームの -xtarget の値

64 ビット x86 プラットフォームでの 64 ビット Solaris ソフトウェアのコンパイルは、-m64 オプションで指定します。-xtarget を指定し、native64 または generic64 以外のフラグを付ける場合は、-m64 オプションも次のように指定する必要があります。-xtarget=opteron ... -m64。この指定を行わない場合は、コンパイラは 32 ビットメモリーモデルを使用します。

B.2.150 -xtemp=dir

cc が使用する一時ファイルのディレクトリを dir に設定します。このオプション文字列の中にはスペースを入れてはいけません。このオプションを指定しない場合、一時ファイルは /tmp に配置されます。-xtemp は TMPDIR 環境変数より優先します。

B.2.151 -xthreadvar[= o]

スレッドローカルな変数の実装を制御するには -xthreadvar を指定します。コンパイラのスレッドローカルな記憶領域機能を利用するには、このオプションを __thread 宣言指示子と組み合わせて使用します。__thread 指示子を使用してスレッド変数を宣言したあとは、-xthreadvar を指定して動的 (共有) ライブラリの位置に依存しないコード (PIC 以外のコード) でスレッド固有の記憶領域を使用できるようにします。__thread の使用方法の詳細については、「2.3 スレッドローカルな記憶領域指示子」を参照してください。

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

-xthreadvar を指定しない場合、コンパイラが使用するデフォルトは位置独立コード (PIC) が有効になっているかどうかによって決まります。位置独立コードが有効になっている場合、オプションは -xthreadvar=dynamic に設定されます。位置独立コードが無効になっている場合、オプションは -xthreadvar=no%dynamic に設定されます。

値を指定しないで -xthreadvar を指定すると、オプションは -xthreadvar=dynamic に設定されます。

動的ライブラリ内に位置に依存するコードがある場合、-xthreadvar を指定する必要があります。

リンカーは、動的ライブラリ内の位置依存コード (非 PIC) スレッド変数と同等のスレッド変数はサポートできません。非 PIC スレッド変数は非常に高速なため、実行可能ファイルのデフォルトとして指定できます。

異なるバージョンの Solaris ソフトウェアでスレッド変数を使用するには、コマンド行で異なるオプションを指定する必要があります。

• Solaris 8 ソフトウェアでは、__thread を使用するオブジェクトは -mt を指定してコンパイルし、-mt -L/usr/lib/lwp -R/usr/lib/lwp を指定してリンクする必要があります。

• Solaris 9 ソフトウェアでは、__thread を使用するオブジェクトはコンパイルとリンクに -mt を指定する必要があります。

関連項目: -xcode、-KPIC、-Kpic

B.2.152 -xtime

コンパイルの各構成要素が占有した実行時間と資源を報告します。

B.2.153 -xtransition

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

B.2.154 -xtrigraphs

-xtrigraphs オプションは、コンパイラが ISO 規格で定義されている三文字表記シーケンスを認識するかどうかを決定します。

デフォルトにより、コンパイラは -xtrigraphs=yes を仮定し、コンパイル単位をとおしてすべての三文字表記シーケンスを認識します。

コンパイラが文字表記シーケンスとして解釈している疑問符 (?) の入ったリテラル文字列がソースコードにある場合は、-xtrigraph=no サブオプションを使用して文字表記シーケンスの認識をオフにすることができます。-xtrigraphs=no オプションは、コンパイル単位全体をとおしてすべての三文字表記シーケンスの認識をオフにします。

次の例は、ソースファイル 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 (??)

B.2.155 -xunroll=n

ループを n 回展開するようオプティマイザに指示します。n は正の整数です。n が 1 のときはコマンドとなり、コンパイラはループを展開しません。n が 2 以上のとき、-xunroll=n は n 回ループを展開することをコンパイラに知らせます。

B.2.156 -xustr={ascii_utf16_ushort|no}

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_utf16_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';

B.2.157 -xvector[= a]

ベクタライブラリ関数の呼び出しの自動生成や、SIMD (Single Instruction Multiple Data) 命令の生成ができます。このオプションを使用するときは -fround=nearest を指定することによって、デフォルトの丸めモードを使用する必要があります。

a は、次の指定と同じです。

デフォルトは、x86 では -xvector=simd で、SPARC プラットフォームでは -xvector=%none です。サブオプションなしで -xvector を指定すると、コンパイラでは、x86 では -xvector=simd,lib、SPARC (Solaris) では -xvector=lib、および -xvector=simd (Linux) が使用されます。

—xvector オプションを指定するには、最適化レベルが —xO3 かそれ以上に設定されていることが必要です。最適化レベルが指定されていない場合や —xO3 よりも低い場合はコンパイルは続行されず、メッセージが表示されます。

B.2.158 -xvis

(SPARC) VIS instruction-set Software Developers Kit (VSDK) に定義されているアセンブリ言語のテンプレートを使用する場合は、-xvis=[yes|no] コマンドを使用します。デフォルトは -xvis=no です。-xvis と指定すると -xvis=yes と指定した場合と同様の結果が得られます。

VIS 命令セットは、SPARC v9 命令セットの拡張です。UltraSPARC プロセッサは 64 ビットでも、多くの場合、特にマルチメディアアプリケーションではデータサイズが 8 ビットまたは 16 ビットに制限されています。VIS 命令では、1 命令で 4 つの 16 ビットデータを処理できるので、画像、線形代数、信号処理、オーディオ、ビデオ、ネットワーキングなどの新しいメディアを扱うアプリケーションのパフォーマンスが大幅に向上します。

VSDK の詳細については、http://www.sun.com/processors/vis/ を参照してください。

B.2.159 -xvpara

OpenMP を使用する場合に正しくない結果をもたらす可能性のある、並列プログラミングに関連する潜在的な問題に関して、警告を発行します。-xopenmp および OpenMP API 指令とともに使用します。

次の状況が検出された場合は、コンパイラは警告を発行します。

• 異なるループ繰り返し間でデータに依存関係がある場合に、MP 指令を使用して並列化されたループ。

• OpenMP データ共有属性節に問題がある場合。たとえば、「shared」と宣言された変数に、OpenMP 並列領域からアクセスするとデータ競合が発生する可能性がある場合や、並列領域の中に値を持つ変数を「private」と宣言し、並列領域よりあとでその変数を使用する場合です。

すべての並列化命令が問題なく処理される場合、警告は表示されません。

次に例を示します。

cc -xopenmp -vpara any.c

Solaris Studio のコンパイラは OpenMP 2.5 API の並列化をサポートします。そのため、MP プラグマ命令は非推奨で、サポートされません。OpenMP API への移植については、『OpenMP API ユーザーズガイド』を参照してください。

B.2.160 -Yc, dir

c を検索するための新しい dir を指定します。c は -W オプションで示したコンパイラ構成要素を表わす文字です。

構成要素の検索が指定されている場合、ツールのパス名は dir/tool になります。2 つ以上の -Y オプションが 1 つの項目に適用されている場合には、最後に現れたものが有効です。

B.2.161 -YA, dir

コンパイラのすべての構成要素の検索場所にするディレクトリ dir を指定します。dir 内で構成要素が見つからない場合は、コンパイラがインストールされているディレクトリに戻って検索されます。

B.2.162 -YI, dir

インクルードファイルを検索するデフォルトのディレクトリを変更します。

B.2.163 -YP, dir

ライブラリファイルを検索するデフォルトのディレクトリを変更します。

B.2.164 -YS, dir

起動用のオブジェクトファイルを検索するデフォルトのディレクトリを変更します。

B.2.165 -Zll

(SPARC) lock_lint 用にプログラムデータベースを作成しますが、実行可能なコードは生成しません。詳細は、lock_lint(1) のマニュアルページを参照してください。

B.3 リンカーに渡されるオプション

cc は -a、-e、-r、-t、-u、-z を認識し、これらのオプションとその引数を ld に渡します。cc は認識できないオプションを警告付きで ld に渡します。Solaris プラットフォームでは、-i オプションとその引数もリンカーに渡されます。