B.2 cc オプション

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

特定のプラットフォームに固有と表記されたオプションを別のプラットフォームで使用してもエラーは起きません。単に無視されます。オプションおよび引数で使用している表記方法については、「表記上の規則」を参照し てください。

B.2.1 -#

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

B.2.2 -###

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

B.2.3 -A<名前>[ (<トークン>)]

<名前> を述語として <トークン> と関連付けます。#assert 前処理指令を実行するのと同様です。事前表明 (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

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

B.2.7 -D<名前>[(<引数>[,<引数>])][=<展開>]

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

事前定義されているものは次のとおりです (-Xc モードでは無効)。

• sun

• unix

• sparc (SPARC)

• i386 (x86)

次の事前定義はあらゆるモードにおいて有効です。

• __BUILTIN_VA_ARG_INCR

• __SUNPRO_C=0x590

• __SVR4 (SPARC)

• __SunOS (Solaris オペレーティングシステム)

• __SunOS_n_n (Solaris オペレーティングシステム)

• __amd64 (-m64 オプションを使用した x86)

• __gnu__linux (linux)

• __i386 (x86)

• __linux (linux)

• __linux__ (linux)

• __sparc (SPARC)

• __sparcv9 (-xarch=v9, v9a, v9b)

• __sun (Solaris オペレーティングシステム)

• __unix

• __SunOS_n_n (Solaris オペレーティングシステム) (例: __SunOS_5_9)

次は -Xa モードおよび -Xt モードにおいてのみ事前定義されます。

• __RESTRICT

コンパイラでは、__PRAGMA_REDEFINE_EXTNAME のようなオブジェクト形式のマクロを定義しておくことにより、プラグマを認識させることができます。

B.2.8 -d[y|n]

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

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

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

このオプションと動的ライブラリを組み合わせると、致命的なエラーになります。大部分のシステムライブラリは、動的ライブラリとしてのみ使用できます。

B.2.9 -dalign

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

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 -erroff[= t]

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

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

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

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

B.2.13 -errshort[= i]

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

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

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

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

B.2.14 -errtags[= a]

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

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

B.2.15 -errwarn[= t]

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

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

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

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

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

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

B.2.16 -fast

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

-fast の展開内容に、-xlibmopt も含まれるようになっています。このオプションによって、コンパイラは最適化された数学ルーチンのライブラリを利用できます。詳細は、「B.2.99 -xlibmopt」を参照してください。

-fast オプションは、errno の値に影響します。詳細は、「2.10 errno の値」を参照してください。

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

-fast オプションは、特にコンパイルするマシンとは異なるターゲットで実行するプログラムでは使用できません。そのような場合は、-fast のあとに適切な -xtarget オプションを指定します。次に例を示します。

cc -fast -xtarget=ultra ...

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」の組み合わせでコンパイルすることと同じで、後ろの指定が優先されます。

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

B.2.17 -fd

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

B.2.18 -features=[[no%]extinl|%none]

extern インライン関数のコンパイラの処理は、デフォルトでは、ISO/IEC 9899:1999 C 規格に規定されている動作に準拠しています。version 5.5 またはそれ以前の C および C++ コンパイラで提供されているのと同じ extern インライン関数の処理を得るには、-features=no%extinl を付けて新しいコードをコンパイルしてください。

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

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

B.2.19 -flags

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

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

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

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

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

• -fprecision

• -nofstore

• -xarch=amd64

• -xarch=sse2

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

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

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

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

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

B.2.22 -fnonstd

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

B.2.23 -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.24 -fprecision=p

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

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

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

B.2.25 -fround=r

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

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

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

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

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

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

B.2.26 -fsimple[= n]

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

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

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

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

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

B.2.27 -fsingle

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

B.2.28 -fstore

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

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

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

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

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

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

-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.30 -G

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

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

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

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

B.2.31 -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.32 -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.33 -h <名前>

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

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

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

B.2.34 -I[-|<ディレクトリ>]

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

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

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

B.2.35 -i

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

B.2.36 -KPIC

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

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

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

B.2.37 -Kpic

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

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

B.2.38 -keeptmp

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

B.2.39 -L<ディレクトリ>

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

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

B.2.40 -l<名前>

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

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

B.2.41 -m32|-m64

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

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

Solaris プラットフォームおよび 64 ビットが有効にされていない Linux プラットフォームでは、デフォルトは ILP32 メモリーモデル (32 ビットの int、long、ポインタデータ型) です。64 ビットが有効にされている Linux プラットフォームでは、デフォルトは LP64 メモリーモデル (64-ビットの long、ポインタデータ型) です。-m64 は、LP64 モデルが有効であるプラットフォームだけで使用できます。

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

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

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

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

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

B.2.42 -mc

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

B.2.43 -misalign

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

B.2.44 -misalign2

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

B.2.45 -mr[, <文字列>]

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

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

B.2.46 -mt

マルチスレッド化したコードのコンパイルとリンクを行います。

このオプションを付けると、-D_REENTRANT がプリプロセッサに渡され、-lthread が ld に正しい順番で渡されます。

アプリケーションやライブラリがマルチスレッド化されている場合は、-mt オプションが必要です。

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

POSIX スレッドを使用している場合は、-mt -lpthread を使用してリンクする必要があります。マルチスレッドアプリケーションの場合は libC および libCrun に libthread が必要であるため、-mt オプションが必要です。

コンパイルとリンクを個別の手順で実行し、-mt を使用してコンパイルすると、予期せぬ結果が生じる場合があります。-mt を使用して変換ユニットをコンパイルする場合は、プログラムのすべてのユニットを -mt を使用してコンパイルしてください。

「B.2.113 -xnolib」も参照してください。

B.2.47 -native

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

B.2.48 -nofstore

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

B.2.49 -O

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

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

B.2.50 -o <出力ファイル>

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

B.2.51 -P

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

B.2.52 -p

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

B.2.53 -Q[y|n]

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

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

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

B.2.54 -qp

-p と同じです。

B.2.55 -R<ディレクトリ>[ :<ディレクトリ>]

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

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

B.2.56 -S

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

B.2.57 -s

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

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

B.2.58 -U<名前>

プリプロセッサシンボル <名前> の定義を削除します。このオプションは、コマンド行ドライバで配置された要素も含む同一コマンド行において -D で作成されたプリプロセッサシンボル <名前> の初期定義を削除します。

-U は、ソースファイルのプリプロセッサ指令に影響しません。コマンド行に複数の -U オプションを配置できます。

コマンド行の -D と -U に同じ <名前> が指定された場合、オプションの配置順に関係なく、<名前> の定義が削除されます。次の図で、-U は __sun の定義のを削除します。

cc -U__sun text.c

test.c の次の書式のプリプロセッサ文は、 __sun の定義が削除されているために有効になりません。

#ifdef(__sun)

定義済みシンボルのリストについては、「B.2.7 -D<名前>[(<引数>[,<引数>])][=<展開>]」を参照してください。

B.2.59 -V

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

B.2.60 -v

より厳しい意味検査およびほかの lint に似た検査を行います。次は

#include <stdio.h>
main(void)
{
     printf("Hello World.\n");
}

支障なくコンパイルと実行ができるコードです。-v を使用すると、コンパイルは行われますが次の警告が表示されます。

"hello.c", 5 行目: 警告: 関数中に return 文がありません:
 main

-v は lint(1) が発する警告をすべて表示するわけではありません。lint で前述の例を実行すると確認することができます。

B.2.61 -Wc,<引数>

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

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

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

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

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

B.2.62 -w

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

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

B.2.63 -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.2 libfast.a ライブラリ」を参照してください。

デフォルトのモードは -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 = transition) ISO C に K&R C との拡張互換性を持たせます。ISO C に従うように意味処理の変更は行いません。 同じ言語構造に対して ISO C と K&R 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.64 -x386

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

B.2.65 -x486

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

B.2.66 -xa

旧式。このオプションは使わないでください。代わりに、-xprofile=tcov を使ってください。「A.1.15 旧式のオプション」に、旧式のオプションとフラグの全一覧をまとめています。

B.2.67 -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.68 -xarch=isa

命令セットアーキテクチャー (Instruction Set Architecture、ISA) を指定します。このオプションを最適化と併せて使用する場合、適切なアーキテクチャーを選択すると、そのアーキテクチャー上での実行パフォーマンスを向上させることができます。不適切なアーキテクチャーを選択すると、バイナリプログラムがその対象プラットフォーム上で実行できなくなることがあります。

-m64 または -m32 オプションを使用して、目的のメモリーモデルを LP64 (64 ビット) または ILP32 (32 ビット) から指定します。次に示すように、-xarch オプションは以前のリリースとの互換性を保つために使用する以外に、メモリーモデルを示すものではありません。

-xarch は単独で使用できますが、本来は -xtarget オプションの展開の一部です。特定の -xtarget オプションで設定されている -xarch の値を上書きするために使用することもできます。次に例を示します。

% cc -xtarget=ultra2 -xarch=v8plusb ...

この例では、-xtarget=ultra2 によって設定されている -xarch=v8 が -xarch=v8plusb によって上書きされます。

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

次の表は、指定された -xarch オプションでコンパイルされたあと、さまざまな SPARC プロセッサで実行される実行可能ファイルのパフォーマンスを示しています。この表は、特定の対象マシン上の実行可能ファイルにもっとも適した -xarch オプションを調べるために利用してください。初めにマシンの範囲を決め、続いて複数のバイナリを管理する手間と、より新しいマシンから最大限のパフォーマンスを引き出す効果を比較してみるとよいでしょう。

• N は、「仕様どおりのパフォーマンス」を意味します。プロセッサの命令セットを十分に利用してプログラムの実行が行われます。

• S は、「十分なパフォーマンス」を意味します。プログラムは実行されますが、提供されているプロセッサ命令の一部を利用できない場合があります。

• PD は、「パフォーマンスの低下」を意味します。プログラムは実行されますが、使用されている命令によってはパフォーマンスの低下が発生する場合があります (低下の程度はさまざま)。このパフォーマンス低下は、プロセッサが実装していない命令がカーネルでエミュレートされる場合に起きます。

• NE は、「実行不可能」を意味します。カーネルがプロセッサが実装していない命令をエミュレートしないため、プログラムは実行されません。

v8plus または v8plusa 命令セットを使用して実行可能ファイルをコンパイルしようと考えている場合は、代わりに v9 または v9a によるコンパイルを考慮してください。v8plus と v8plusa オプションは、64 ビットプログラム対応の Solaris 8 がリリースされる以前に、プログラムで SPARC V9 と UltraSPARC 機能の一部が利用できるように提供されたものです。v8plus または v8plusa オプションでコンパイルされたプログラムは、SPARC V8 以前のマシンには移植できません。これらのプログラムは、v9 または v9a でそれぞれコンパイルし直すと、SPARC V9 と UltraSPARC の全機能を十分利用できるようになります。v8plus と v8plusa の制限については、ホワイトペーパー『 The V8+ Technical Specification』(Part No.: 802-7447-10。購入先から入手可能) で説明されています。

• SPARC 命令セットアーキテクチャー V8 および V8a はバイナリ互換です。

• v8plus と v8plusa でそれぞれコンパイルされたオブジェクトバイナリファイル (.o) は、一緒にリンクおよび実行できます。 ただし、SPARC V8plusa 互換プラットフォーム上で実行する場合に限られます。

• v8plus、v8plusa、および v8plusb でそれぞれコンパイルされたオブジェクトバイナリ (.o) ファイルは、一緒にリンクおよび実行できます。ただし、SPARC V8plusb 互換プラットフォーム上で実行する場合に限られます。

• -xarch の値、v9、v9a、および v9b は、UltraSPARC 64 ビット Solaris オペレーティングシステムにしか使用できません。

• v9 と v9a でそれぞれコンパイルされたオブジェクトバイナリファイル (.o) は、一緒にリンクおよび実行できます。ただし、SPARC V9a 互換プラットフォーム上で実行する場合に限られます。

• v9、v9a、および v9b でそれぞれコンパイルされたオブジェクトバイナリファイル (.o) は、一緒にリンクおよび実行できます。 ただし、SPARC V9b 互換プラットフォーム上で実行する場合に限られます。

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

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

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

次の表は、x86 アーキテクチャーでの -xarch のフラグをまとめています。

x86 の特記事項

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

従来の Sun 形式の並列化プラグマは、x86 上では使用できません。この代わりに OpenMP を使用してください。従来の並列化指令から OpenMP への変換に関する詳細は、『Sun Studio 12: OpenMP API ユーザーズガイド』を参照してください。

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

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

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

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

たとえば sin(x) など、組み込みの数学ライブラリが同じではないため、Solaris と Linux で数値演算結果が異なる場合があります。

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

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

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

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

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

B.2.68.3 SPARC 用のデフォルト

C コンパイラがコードを生成するときのデフォルトのアーキテクチャーが、 v8plus (UltraSPARC) になりました。今後のリリースで、v7 のサポートは廃止される予定です。

新しいデフォルトでは、現在使用されているほぼあらゆるマシンで実行時のパフォーマンスが向上します。ただし、UltraSPARC 以前のコンピュータへの配備を意図したアプリケーションは、そうしたコンピュータ上ではデフォルトで動作しなくなります。アプリケーションがそうしたコンピュータで動作するようにするには、-xarch=v8 でコンパイルしてください。

v8 システムに配備する場合は、各コンパイラコマンド行ばかりでなく、すべてのリンク時コマンドでも -xarch=v8 オプションを明示的に指定する必要があります。提供のシステムライブラリは v8 アーキテクチャーで動作します。

v7 システムに配備する場合は、あらゆるコンパイラコマンド行だけでなく、どのリンク時コマンドでも -xarch=v7 オプションを明示的に指定する必要があります。提供のシステムライブラリは、v8 命令セットを利用します。このリリースの場合、v7 がサポートされているオペレーティングシステムは Solaris 8 ソフトウェアだけです。v8 命令が検出された場合、Solaris 8 オペレーティングシステムはソフトウェアでその命令を解釈します。このためプログラムは実行されますが、パフォーマンスは低下します。

B.2.68.4 x86 用のデフォルト

x86 の場合、-xarch デフォルトでは generic になります。また、x86 では、-fast は -xarch=native に展開されることに注意してください。このオプションは、コンパイラが生成するコードを、指定した命令セットアーキテクチャーの命令だけに制限します。このオプションは、すべてのターゲットを対象とするような命令としての使用は保証しません。ただし、このオプションを使用するとバイナリプログラムの移植性に影響を与える可能性があります。

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

B.2.69 -xautopar

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

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

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

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

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

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

B.2.70 -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.71 -xbuiltin[=( %all|%none)]

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

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

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

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

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

B.2.72 -xCC

-xc99=none および -xCC を指定した場合は、コンパイラで C++ 形式のコメントが認識されます。// がコメントの開始を示すために使えるようになります。

B.2.73 -xc99[= o]

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

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.74 -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.75 -xcg[89| 92]

(SPARC) 旧式。このオプションは使わないでください。最新の Solaris オペレーティングシステムは、SPARC V7 アーキテクチャーをサポートしません。このオプションを付けてコンパイルしたプログラムは、最新の SPARC プラットフォームで実行速度が低下します。-O を使用して、-xarch、-xchip、および -xcache のコンパイラのデフォルトを利用します。

B.2.76 -xchar[= o]

オプションこのオプションは、char 型が符号なしで定義されているシステムからのコード移植を簡単にするためのものです。そのようなシステムからの移植以外では、このオプションは使用しないでください。符号付きまたは符号なしを明示的に示すように記述し直す必要があるのは、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.77 -xchar_byte_order[= o]

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

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

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

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

B.2.78 -xcheck[= o]

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

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

-xcheck を指定しない場合は、コンパイラでは -xcheck=%none が指定されます。引数を指定せずに -xcheck を使用した場合は、コンパイラでは -xcheck=%all がデフォルトで指定されます。この場合は、スタックオーバーフローの実行時チェックがオンになります。

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

B.2.79 -xchip[= c]

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

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

このオプションは単独で指定できますが、-xtarget オプションのマクロ展開の一部です。-xtarget オプションによって指定された値を変更するのが主な目的です。

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

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

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

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

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

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

B.2.80 -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 です。

動的共有ライブラリの構築では、デフォルトの -xcode 値の abs44 および abs32 は 64 ビットアーキテクチャーでは機能しません。代わりに -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 ファイル名.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) を探して、大域オフセットテーブル (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.81 -xcrossfile[= n]

最適化とインライン化を複数のソースファイルに渡って有効にします。n を指定する場合は、0 か 1 のいずれかです。

デフォルトは、-xcrossfile=0 で、ファイル間の最適化は行われません。-xcrossfile は -xcrossfile=1 と同義です。

次にコマンド行の例を示します。

example% cc -xcrossfile -xO4 -c f1.c f2.c
example% cc -xcrossfile -xO4 -c f3.c f4.c

f1.c ファイルと f2.c ファイルの間、および f3.c ファイルと f4.c ファイルの間でクロスモジュールの最適化が行われます。f1.cと f3.c または f4.c の間では最適化は行われません。

通常、コンパイラの解析のスコープは、コマンド行上の各ファイルに制限されます。たとえば、-xO4 の自動インライン化は、同じソースファイル内で定義および参照されるサブプログラムに制限されます。

-xcrossfile を指定すると、コンパイラは、コマンド行に指定したすべてのファイルを (1 つのソースファイルに連結したように) 解析します。-xcrossfile は、-xO4 または -xO5 と併用したときだけ有効です。

ただし、-S オプションを指定することによってアセンブリソースを生成するようコンパイラに指示している場合、このオプションは何の働きもしません。アセンブリ ( .s) ファイルは、ソースファイルにまたがる最適化およびインライン化に関係しません。

このオプションを使ってコンパイルされたファイルは、インライン化されたコードを 含む可能性があるため、相互に依存しています。したがって、プログラムにリンクす るときは、1 つの単位として使用しなければいけません。あるルーチンを変更したために、関連するファイルを再コンパイルした場合は、すべてのファイルを再コンパイルする必要があります。つまり、このオプションを使用すると、メイクファイルの構成にも影響があります。

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

B.2.82 -xcsi

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

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

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

B.2.83 -xdebugformat=[stabs|dwarf]

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

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

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

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

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

B.2.84 -xdepend=[yes| no]

(SPARC) ループの繰り返し内部でのデータ依存性の解析およびループ再構成を実行します。

ループの再構成には、ループの交換、ループの融合、スカラーの置換、無意味な配列への代入の除去が含まれます。最適化が -xO3 以上でない場合、-xO3 に上げられ、警告が出されます。

-xdepend を指定しない場合、デフォルトは -xdepend=no で、コンパイラはデータ依存関係についてループを分析しません。引数を指定しないで、-xdepend を指定すると、オプションは -xdepend=yes に設定され、コンパイラはデータ依存関係についてループを分析します。

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

依存性の解析はシングルプロセッサシステムで役立つことがあります。ただし、シングルプロセッサシステムに -xdepend を試みる場合は、-xautopar または -xexplicitpar を使用しないでください。これらのいずれかが有効になっていると、-xdepend の最適化はマルチプロセッサシステムについて実行されます。

B.2.85 -xdryrun

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

B.2.86 -xe

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

B.2.87 -xexplicitpar

(SPARC) 旧式。使わないでください。この代わりに -xopenmp を使用してください。

-xexplicitpar は、OpenMP の並列化命令を受け付けません。ただし、Sun 固有の MP プラグマは推奨されず、サポートされません。代わりに、OpenMP 2.5 規格で規定された API をサポートします。標準命令への移植については、『Sun Studio 12: OpenMP API ユーザーズガイド』を参照してください。

(SPARC) #pragma MP 指令の指定に基づいて並列化コードを生成します。ユーザー自身が、依存性の解析を行い、ループの繰り返し内部でのデータの依存性を解析および指定します。ソフトウェアは指定されたループを並列化します。最適化が -xO3 以上でない場合、-xO3 に上げられ、警告が出されます。独自のスレッド管理を行なっている場合には、-xexplicitpar を使用しないでください。

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

ユーザーが指定したループに依存関係が含まれていると、正しい結果が得られないことがあります。しかも、結果が実行するごとに異なることがあります。なお、警告は出力されません。縮約ループには、明示的な並列プラグマは適用しないでください。明示された並列化は行われますが、ループの縮約は適用されないため、誤った結果が生じる場合があります。

要約すると、明示的な並列化には次の操作を実行します。

• ループを解析して、安全に並列化できるループを見つける。

• #pragma MPを挿入してループを並列化する。詳細は、「3.8.3 明示的な並列化およびプラグマ」を参照してください。

• -xexplicitpar オプションを使用します。

ループの直前に並列プラグマを挿入する例を示します。

#pragma MP taskloop
  for (j=0; j<1000; j++){
  ...
  }

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

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

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

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

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

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

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

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

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

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

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

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

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

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

B.2.88.1 値

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

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

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

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

B.2.89 -xhelp=f

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

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

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

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

B.2.90 -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.91 -xinline=<リスト>

-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.92 -xinstrument=[ no%]datarace

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

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

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

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

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

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

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

B.2.93 -xipo[= a]

(SPARC) a を 0、 1、または 2 と置き換えます。引数をとらない -xipo は、-xipo=1 と同じ働きをします。-xipo=0 はデフォルトの設定であり、-xipo をオフにします。-xipo=1 を指定した場合は、すべてのソースファイルでインライン化が実行されます。

-xipo=2 を指定した場合は、コンパイラは内部手続きの別名解析と、メモリーの割り当ておよび配置の最適化を実行し、キャッシュ性能を向上させます。

このコンパイラは、内部手続き解析コンポーネントを呼び出すことにより、プログラムの一部の最適化を実行します。-xcrossfile と異なり、-xipo は、リンク段階ですべてのオブジェクトファイルを介して最適化を実行し、最適化の対象をコンパイルコマンドのソースファイルだけに限定しません。ただし、-xcrossfile 同様、-xipo によるプログラム全体の最適化には、アセンブリ (.s) ソースファイルは含まれません。

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

-xipo オプションは、ファイルを介して最適化を実行する際に必要な情報を追加するため、非常に大きなオブジェクトファイルを生成します。ただし、この補足情報は最終的な実行可能バイナリファイルの一部にはいけません。実行可能プログラムのサイズが拡大するのは、最適化が追加実行されるためです。このコンパイル段階で作成されたオブジェクトファイルには、内部でコンパイルされた追加の分析情報が含まれているため、リンク段階でファイル相互の最適化を実行できます。

-xipo は、大きなマルチファイルアプリケーションをコンパイルおよびリンクする際に便利です。このフラグでコンパイルされたオブジェクトファイルは、それらのファイル内でコンパイルされた解析情報を保持します。これらの解析情報は、ソースおよびコンパイル前のプログラムファイルで内部手続き解析を可能にします。

ただし、解析と最適化は -xipo を指定してコンパイルされたオブジェクトファイルに限定され、オブジェクトファイルまたはライブラリは対象外です。

-xipoは複数の段階に分かれているため、コンパイルとリンクを個別に実行する場合、各ステップで -xipo を指定する必要があります。

-xipo に関するそのほかの重要な情報を次に示します。

• 少なくとも最適化レベル -xO4 を必要とします。

• -xcrossfile と競合します。両方を使用した場合、コンパイルエラーが発生します。

• -xipo なしでコンパイルされたオブジェクトは、-xipo でコンパイルされたオブジェクトと自由にリンクできます。

B.2.93.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.93.2 -xipo=2 による内部手続き解析を行うべきでないケース

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

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

• オブジェクトファイル群内のルーチンからの foo() 呼び出しが、そのオブジェクトファイル群の外部に定義されている別のバージョンの foo() からの割り込みを受けない。

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

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

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

B.2.94 -xipo_archive=[a]

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

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

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

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

B.2.95 -xjobs=n

(SPARC) コンパイラが処理を行うために生成するプロセスの数を設定するには、 -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.96 -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.97 -xlibmieee

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

B.2.98 -xlibmil

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

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

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

B.2.99 -xlibmopt

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

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

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

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

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

関連項目: -fast -xnolibmopt

B.2.100 -xlic_lib=sunperf

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

B.2.101 -xlicinfo

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

B.2.102 -xlinkopt[= レベル]

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

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

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

レベルには、実行される最適化レベルを 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.131 -xprofile=p」を参照してください。

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

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

B.2.103 -xloopinfo

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

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

B.2.104 -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

B.2.105 -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.106 -xMD

-xM と同様にメイクファイルの依存関係を生成しますが、コンパイルも含みます。 -xMD は、入力ファイルに .d の接尾辞を付けた名前で、メイクファイルの依存関係情報を含むファイルを生成します。 -xMD と -xMF を両方指定すると、プリプロセッサはメイクファイルのすべての依存関係の情報を -xMF で指定されたファイルに追加します。

B.2.107 -xMF <ファイル名>

このオプションは、 メイクファイルの依存関係を出力するファイルを指定するために使用します。複数の入力ファイルがある場合に、-xMF を使って 1 つのコマンド行で、それぞれのファイルについて個別のファイル名を指定することはできません。

B.2.108 -xMMD

このオプションは、 システムヘッダーファイルを除外したメイクファイルの依存関係を生成するために使用します。 これは -xM1 と同じ機能ですが、コンパイルを含みます。 -xMMD は、入力ファイルに .d の接尾辞を付けた名前で、メイクファイルの依存関係情報を含むファイルを生成します。-xMF を使用すると、コンパイラは代わりに指定されたファイル名を使用します。

B.2.109 -xMerge

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

B.2.110 -xmaxopt[=v]

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

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

B.2.111 -xmemalign=ab

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

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

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

コンパイル時に境界整列が判別できないメモリーへのアクセスの場合、コンパイラは必要なロードおよびストア命令を生成するための境界整列を想定する必要があります。

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

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

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

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

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

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

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

B.2.112 -xmodel=[a]

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

このオプションは、64 ビットが有効である x64 プロセッサで、-m64 も指定されている場合にのみ有効です。

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

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

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

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

すべての Linux システムがミディアムモデルをサポートしているわけではないことに注意してください。

B.2.113 -xnolib

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

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

B.2.114 -xnolibmil

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

% cc -fast -xnolibmil....

B.2.115 -xnolibmopt

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

% cc -fast -xnolibmopt ...

B.2.116 -xnorunpath

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

通常 cc は、リンカーに -R パスを渡しません。リンカーに -R パスを渡すオプションには、-xliclib=sunperf や -xopenmp などがあります。これを行わないようにするには、-xnorunpath オプションを使用できます。

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

B.2.117 -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.117.1 SPARC での最適化について

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

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

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

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

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

B.2.118 -xopenmp[= i]

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

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

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

-xopenmp を指定しても値を設定しない場合、コンパイラは -xopenmp=parallel を仮定します。-xopenmp を指定しない場合、コンパイラは -xopenmp=none を仮定します。

dbx を指定して OpenMP プログラムをデバッグする場合、-g と -xopenmp=noopt を指定してコンパイルすれば、並列化部分にブレークポイントを設定して変数の内容を表示することができます。

-xopenmp を -xexplicitpar または -xparallel と同時に指定しないでください。

-xopenmp のデフォルトは、将来変更される可能性があります。警告メッセージを出力しないようにするには、適切な最適化を明示的に指定します。

-xopenmp を使用して、.so を構築する場合は、実行可能ファイルのリンクでも -xopenmp を使用する必要があります。このときの実行可能ファイルのコンパイラは、-xopenmp を付けて .so を構築したコンパイラより古くてはいけません。これは、OpenMP 指令を含むライブラリをコンパイルする場合に特に重要です。表 A–2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。

最高のパフォーマンスを得るには、システムに OpenMP 実行時ライブラリ libmtsk.so の最新のパッチがインストールされていることを確認します。

OpenMP の C の実装に固有の情報については、「3.2 OpenMP に対する並列化」を参照してください。

OpenMP の詳細については、『Sun Studio 12: OpenMP API ユーザーズガイド』を参照してください。

B.2.119 -xP

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

f()
{
}

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

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

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

B.2.120 -xpagesize=n

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

n には、4K、8K、64K、512K、2M、 4M、32M、256M、2G、16G、default のいずれかを指定します。有効なページサイズを指定しないと、要求は実行時に暗黙的に無視されます。

ターゲットプラットフォームに対して有効なページサイズを指定する必要があります。

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

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

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

この機能は、Solaris 8 オペレーティングシステムでは利用できません。このオプションを指定してコンパイルされたプログラムは、Solaris 8 オペレーティングシステムではリンクしません。

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

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

このオプションは -xpagesize_heap と -xpagesize_stack のマクロです。これらの 2 つのオプションは -xpagesize と同じ次の引数を使用します。4K、8K、 64K、512K、2M、 4M、32M、256M、2G、16G、default のいずれかの値を指定します。両方に同じ値を設定するには -xpagesize を指定します。別々の値を指定するには個々に指定します。

B.2.121 -xpagesize_heap=n

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

n には、4K、8K、64K、512K、2M、 4M、32M、256M、2G、16G、default のいずれかを指定します。有効なページサイズを指定しないと、要求は実行時に暗黙的に無視されます。

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 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。

この機能は、Solaris 8 オペレーティングシステムでは利用できません。このオプションを指定してコンパイルされたプログラムは、Solaris 8 オペレーティングシステムではリンクしません。

B.2.122 -xpagesize_stack=n

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

n には、8K、64K、512K、4M、32M、256M、2G、16G、 default のいずれかを指定します。有効なページサイズを指定しないと、要求は実行時に暗黙的に無視されます。

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 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。

この機能は、Solaris 8 オペレーティングシステムでは利用できません。このオプションを指定してコンパイルされたプログラムは、Solaris 8 オペレーティングシステムではリンクしません。

B.2.123 -xparallel

(SPARC) 旧式。使わないでください。この代わりに -xopenmp を使用してください。

-xparallel は、OpenMP の並列化命令を受け付けません。ただし、Sun 固有の MP プラグマは推奨されず、サポートされません。推奨され、サポートされる並列化モデルは OpenMP API です。標準命令への移植については、『Sun Studio 12: OpenMP API ユーザーズガイド』を参照してください。

ループを、コンパイラで自動的に並列化するとともに、プログラマの指定によって明示的に並列化します。-xparallel オプションはマクロで、-xautopar、-xdepend、-xexplicitpar の 3 つをすべて指定することと同じです。ループの明示的な並列化では、誤った結果が生まれる危険性があります。最適化が -xO3 以上でない場合、-xO3 に上げられ、警告が出されます。

独自のスレッド管理を行なっている場合には、-xparallel を使用しないでください。-xparallel を発行する場合、-xopenmp を発行しないでください。-xparallel は、-xopenmpを指定する際に発行すべきでない -xexplicitpar を設定するからです。

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

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

B.2.124 -xpch=v

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

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

関連項目

• 「B.2.125 -xpchstop=[<ファイル>|<include>]」

• 「2.8.8 hdrstop」

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

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

B.2.124.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.124.3 既存のプリコンパイル済みヘッダーファイルの処理方法

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

B.2.124.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.124.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 が指定されていて、次のように定義されている場合、コンパイラは活性文字列の終点を自動的に特定します。-xpch=collect または -xpch=use の場合、活性文字列は #pragma hdrstop で終了します。

• 最初の宣言/定義文

• 最初の #line 指令

• #pragma hdrstop 指令

• 指定されたインクルードファイルのあと (-xpch=auto および -xpchstop が指定された場合)

• 最初のインクルードファイル ( -xpch=autofirst が指定された場合)

  ---

  注 –

  条件文内に終点がある場合は、警告が生成され、プリコンパイル済みヘッダーファイルの自動作成は無効になります。また、#pragma hdrstop と -xpchstop オプションの両方が指定された場合、コンパイラは 2 つの停止点のうちの早い方を使用して、活性文字列を終了します。

  ---

プリコンパイル済みヘッダーファイルを共有する各ファイルの活性文字列内では、対応する各 #define 指令と #undef 指令は同じシンボルを参照する必要があります (#define の場合は、各指令は同じ値を参照しなければいけません)。各活性文字列内での順序も同じである必要があります。対応する各プラグマも同じで、その順序もプリコンパイル済みヘッダーを共有するすべてのファイルで同じでなければいけません。

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

ヘッダーファイルがプリコンパイル可能となる条件。それは、複数のソースファイルに渡ってヘッダーファイルの一貫した解釈ができることです。具体的には、完全な宣言だけが含まれていることです。すなわち、どのファイルの宣言も有効な宣言として独立している必要があります。struct S; などの不完全な型宣言は有効な型宣言です。完全な型宣言がほかのファイルに存在している可能性があります。次のヘッダーファイルの例を考えてみてください。

file a.h
struct S {
#include "x.h" /* 許されない */
};

file b.h
struct T; // ok、完全な宣言
struct S {
   int i;
[ファイルの終わり、別のファイルに続く] /* 許されない*/

プリコンパイル済みヘッダーファイルに組み込まれるヘッダーファイルは、次の項目に違反しないようにしてください。これらの制限に違反するプログラムをコンパイルした場合、結果は予測できません。

• ヘッダーファイルに、__DATE__ や __TIME__ が含まれていてはならない。

• ヘッダーファイルに、#pragma hdrstopが含まれていてはならない。

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

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

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

B.2.124.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.124.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.125 -xpchstop=[<ファイル>|<include>]

-xpchstop=<ファイル> オプションは、プリコンパイル済みヘッダーファイル用の活性文字列の最後のインクルードファイルを指定するときに使用します。コマンド行で -xpchstop を使用するのは、 cc コマンドで指定する各ソースファイルの <ファイル> を参照する最初のインクルード指令のあとに 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.126 -xpentium

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

B.2.127 -xpg

gprof(1) によるプロファイルの準備として、データを収集するためのオブジェクトコードを生成します。-xpg はプログラム実行時に記録機構を起動します。この記録機構は実行が正常終了すると、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) を使用することで作成できます。

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

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

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

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

明示的な先読み命令の使用は、パフォーマンスが実際に向上する特別な場合に限定してください。

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

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

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

B.2.128.1 先読み応答率

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

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

コンパイラでは、先読み命令と先読みしたデータを使用するロード命令やストア命令の間隔を決める先読み応答時間の値が使用されます。先読み命令とロード命令との間の使用応答時間は、先読み命令とストア命令との間の使用応答時間と異なる場合があります。

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

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

latx:factor サブオプションを使用するには、1.0 程度の係数から順にアプリケーションの性能テストを実行します。そのあとで係数を増減して、パフォーマンスを再度実施します。こうして最高のパフォーマンスが得られるまで係数を調整しながらパフォーマンステストを継続します。係数を小刻みに増減すると、ほんの数刻み増減しただけではパフォーマンスに違いは見られませんが、突然パフォーマンスが大きく変わり、その後再度横這い状態になります。

B.2.129 -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.130 -xprefetch_level=l

(SPARC) -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 では、レベル 2 よりも多くの先読み命令が生成されます。

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

B.2.131 -xprofile=p

このオプションを使用して実行頻度データを収集して保存すると、後続の実行ではそのデータを使用してパフォーマンスを向上させることができます。このオプションは、-xO2 以上の最適化のレベルを指定した場合にのみ有効です。

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

高い最適化レベル (-xO5 など) を指定したコンパイルは、コンパイラに実行時のパフォーマンスフィードバックを提供することで拡張されます。実行時のパフォーマンスフィードバックを生成させるためには、-xprofile=collect を指定してコンパイルし、標準的なデータセットで実行可能ファイルを実行し、次に最高の最適化レベルと -xprofile=use を指定して再コンパイルします。

プロファイルの収集は、マルチスレッド対応のアプリケーションにとって安全です。すなわち、独自のマルチタスク (-mt) を実行するプログラムをプロファイリングすることで、正確な結果が得られます。

p には、collect[:<名前>]、use[:<名前>]、または tcov のいずれか 1 つを指定します。

• collect[:<名前>]

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

  ---

  注 –

  Linux で共有ライブラリを構築する場合は、-xprofile=collect を指定しないでください。

  ---

  <名前> には分析するプログラム名を指定します。この名前はオプションです。<名前> の指定を省略すると、a.out が実行可能ファイルの名前とみなされます。

  環境変数 SUN_PROFDATA および SUN_PROFDATA_DIR を設定すると、-xprofile=collect でコンパイルされたプログラムがプロファイルデータを格納する場所を制御できます。これらの環境変数を設定すると、-xprofile=collect データが SUN_PROFDATA_DIR/SUN_PROFDATA に書き込まれます。

  これらの環境変数は、tcov で書き込まれたプロファイルデータファイルのパスと名前も指定します。tcov(1) マニュアルページを参照してください。

  これらの環境変数を設定しない場合、プロファイルデータは現在のディレクトリの <名前> profile/feedback に書き込まれます。ここで <名前> には、実行可能ファイルの名前、または -xprofile=collect:<名前> フラグで指定された名前が入ります。 <名前> に拡張子 .profile がすでに含まれている場合、<名前> に .profile は付加されません。プログラムを複数回実行する場合、実行頻度のデータがフィードバック ファイルに蓄積されます。つまり、過去のプログラム実行の出力が失われることはありません。

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

• use[:<名前>]

  -xprofile=collect でコンパイルしたプログラムを前回実行したときに作成されたフィードバックファイルに保存された実行頻度のデータに基づいて、プログラムが最適化されます。

  <名前> には分析するプログラム名を指定します。この名前はオプションです。<名前> の指定を省略すると、a.out が実行可能ファイルの名前とみなされます。

  -xprofile オプション (-xprofile=collect から -xprofile=use に変わります) を除き、ソースファイルおよびコンパイラのほかのオプションは、フィードバックファイルを生成したコンパイル済みプログラムのコンパイルに使用したものと完全に同一のものを指定する必要があります。同じバージョンのコンパイラは、収集構築と使用構築の両方に使用する必要があります。-xprofile=collect:<名前> を使用してコンパイルする場合は、最適化コンパイルでも同じ名前 (<名前>) が使用されていなければいけません。-xprofile=use:<名前>

  オブジェクトファイルとそのプロファイルデータの関連付けは、-xprofile=collect を指定してコンパイルしたときのオブジェクトファイルの UNIX パス名に基づいています。場合によっては、コンパイラはオブジェクトファイルとそのプロファイルデータの関連付けを行いません。これは、前回 -xprofile=collect を指定してコンパイルされなかったためオブジェクトファイルにプロファイルデータがない場合、オブジェクトファイルが -xprofile=collect でプログラムにリンクされていない場合、プログラムが一度も実行されていない場合などです。

  さらに、オブジェクトファイルが前回異なるディレクトリ内で -xprofile=collect を指定してコンパイルされ、-xprofile=collect でコンパイルされたほかのオブジェクトファイルと共通ベース名を共有しているが、それらのファイルを格納しているディレクトリの名前によって一意に識別できない場合も、コンパイラは正しく処理できなくなります。この場合、オブジェクトファイルにプロファイルデータがあっても、オブジェクトファイルが -xprofile=use で再コンパイルされたときに、コンパイラはフィードバックディレクトリ内でそのプロファイルデータを見つけることができません。

  このようなあらゆる状況によって、コンパイラはオブジェクトファイルとプロファイルデータの関連付けを失います。したがって、オブジェクトファイルがプロファイルデータを持っているのに、-xprofile=use を指定したときにコンパイラがプロファイルデータをオブジェクトファイルのパス名に関連付けできない場合は、-xprofile_pathmap オプションを使用して正しいディレクトリを特定します。詳細は、「B.2.131 -xprofile=p」を参照してください。

• tcov

  「新しい」形式の tcov を使った基本ブロックカバレージ解析です。

  -xprofile=tcov オプションは、新しい形式の tcov 用基本ブロックプロファイリングです。機能は -xa オプションと類似していますが、ヘッダーファイルにソースコードがあるプログラムまたは C++ テンプレートを使用するプログラムのデータを正確に収集します。古い形式のプロファイリングについては、「B.2.66 -xa」、tcov(1) のマニュアルページ、および『プログラムのパフォーマンス解析』を参照してください。

  時間計測コードの組み込みは -xa オプションの場合と同様に実行されますが、.d ファイルは生成されません。その代わりにファイルが 1 つ生成されます。このファイルの名前は最終的な実行可能ファイルに基づきます。たとえば、プログラムが /foo/bar/myprog.profile から実行されると、データファイルは /foo/bar/myprog.profile/myprog.tcovd に格納されます。

  -xprofile=tcov と -xa オプションは、同じ実行可能ファイル内に指定することができます。すなわち、-xprofile=tcov でコンパイルされたファイルと-xa でコンパイルされたファイルが両方含まれたプログラムをリンクすることができます。1 つのファイルを両方のオプションでコンパイルすることはできません。

  tcov を実行する時点で、新しい形式のデータを使用させるように -x オプションを渡さなければいけません。これを渡さないと、古い .d ファイルがまだ存在する場合に、tcov はデフォルトで古いファイルからデータを使用するため、予想に反した出力が生成されます。

  -xa オプションの場合とは異なり、TCOVDIR 環境変数はコンパイル時には影響力を持ちません。ただし、TCOVDIR 環境変数の値はプログラムの実行時に使用されます。tcov(1) のマニュアルページおよび『プログラムのパフォーマンス解析』を参照してください。

  ---

  注 –

  -xO4 または -xinline によるルーチンのインライン化が存在する場合、tcov カバレージ解析のデータが不正確になることがあります。

  ---

-xprofile=collect を指定してプロファイルの収集用にコンパイルを行い、-xprofile=use を指定してプロファイルのフィードバック用にコンパイルを行う場合は、ソースファイルおよび -xprofile=collect と -xprofile=use 以外のコンパイラオプションが両方のコンパイルで同一である必要があります。

-xprofile=use:<名前> オプションで指定するプロファイルのフィードバックのディレクトリ名を複数指定した場合は、コンパイラの 1 回の呼び出しですべて使用できます。たとえば、プロファイル対象のバイナリ a、b、c を実行した結果、プロファイルのディレクトリa.profile、b.profile、 c.profile が生成されたとします。

cc -O -c foo.c -xprofile=use:a -xprofile=use:b -xprofile=use:c
 

このとき、3 つのプロファイルのディレクトリがすべて使用されます。特定のオブジェクトファイルに関係する有効なプロファイルのフィードバックデータは、オブジェクトファイルのコンパイル時に、指定したフィードバックのディレクトリから累積されます。

-xprofile=collect と -xprofile=use の両方を同一のコマンド行で指定した場合は、コマンド行で一番右側の -xprofile オプションは次のように適用されます。

• 一番右側の -xprofile オプションが -xprofile=use の場合は、-xprofile=use で指定したすべてのプロファイルフィードバックディレクトリ名がフィードバック指定の最適化で使用され、このオプションよりも前の -xprofile=collect オプションは無視されます。

• 一番右側の -xprofile オプションが -xprofile=collect の場合は -xprofile=use で指定したすべてのプロファイルフィードバックディレクトリ名は無視され、プロファイル生成の計測が有効になります。

関連項目: -xhwcprof、-xprofile_ircache、-xprofile_pathmap

B.2.132 -xprofile_ircache[=<パス名>]

(SPARC) collect 段階で保存されたコンパイルデータを再利用して use 段階のコンパイル時間を向上するには、-xprofile=collect|use で -xprofile_ircache[=<パス名>] を使用します。

大きなプログラムでは、中間データが保存されるため、use 段階のコンパイル時間の効率を大幅に向上させることができます。保存されたデータが必要なディスク容量を相当増やすことがある点に注意してください。

-xprofile_ircache[=<パス名>] を使用すると、<パス名> はキャッシュファイルが保存されているディレクトリを上書きします。デフォルトでは、これらのファイルはオブジェクトファイルと同じディレクトリに保存されます。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.133 -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.134 -xreduction

(SPARC) 自動並列化の間に縮約の認識を有効にします。-xreduction オプションは、-xautopar または -xparallel のいずれかが指定されている場合にのみ有効です。指定されていない場合は、コンパイラから警告が発行されます。

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

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

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

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

例: -xregs=appl,no%float

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

x86 のデフォルトは -xregs=no%frameptr です。-fast の展開に含まれる場合は -xregs=frameptr です。

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

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

B.2.136 -xrestrict[= f]

(SPARC) ポインタ値の関数引数を制限付き (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.137 -xs

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

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

B.2.138 -xsafe=mem

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

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

ロードそのものが完了した場合は、アドレスの不正な整列やセグメンテーション違反などの障害が発生してもトラップが実行されないため、このような障害が発生することがないプログラムでは、このオプションを使用してください。ほとんどのプログラムではメモリーに関するトラップは起こらないので、大多数のプログラムでこのオプションを安全に使用できます。例外条件の処理にメモリーベースのトラップを明示的に使用するプログラムでは、このオプションは使用しないでください。

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

B.2.139 -xsb

このオプションを使用して、ソースブラウザ用の追加シンボルテーブル情報を生成します。このオプションは、コンパイラの -Xs モードと併用することはできません。

別々の手順でコンパイルしてリンクする場合は、コンパイル手順とリンク手順の両方で -xsb を指定してください。指定しないとリンカーからエラーメッセージが表示されます。表 A–2 に、コンパイル時とリンク時の両方に指定する必要があるコンパイラオプションの全一覧をまとめています。

-xsb でコンパイルされたオブジェクトを -xsb を使用してリンクしないと、ソースブラウザデータは、リンク手順で作成された実行可能ファイルが使用する参照だけに限定されます。また、別々に実行されるコンパイル手順とリンク手順で -xsb を指定しないと、ソースブラウザデータベース内の一部のシンボル参照は失われる可能性があります。

コンパイル手順と、コンパイル手順とは別に実行するリンク手順の両方に -xsb を使用することで、オブジェクトが同じディレクトリ内で別の手順でコンパイルされ、異なる実行可能ファイルとリンクされても、ソースブラウザは確実に両方のオブジェクト内のすべてのシンボル参照を認識できます。

B.2.140 -xsbfast

ソースブラウザ用のデータベースを作成します。ソースファイルはオブジェクトファイルにはコンパイルされません。このオプションは、コンパイラの -Xs モードと併用することはできません。

B.2.141 -xsfpconst

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

B.2.142 -xspace

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

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

B.2.143 -xstrconst

デフォルトのデータセグメントではなくテキストセグメントの読み出し専用データセクションに、文字列リテラルを挿入します。重複する文字列は削除され、それ以外の部分はコード中の参照間で共有されます。

B.2.144 -xtarget=t

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

t には次の値のいずれかを指定します。native、generic、native64、generic64、<システム名>。

-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.144.1 SPARC プラットフォームの -xtarget の値

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

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

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

B.2.145 -xtemp=<ディレクトリ>

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

B.2.146 -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.147 -xtime

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

B.2.148 -xtransition

K&R C と Sun ISO C との間の相違に対して警告を出します。

-xtransition オプションを、-Xa または -Xt オプションとともに使用すると警告を出します。異なる動作に関するすべての警告メッセージは適切なコーディングを行うことによって取り除くことができます。次の警告は、-xtransition オプション を使用していなければ表示されません。

• \a は ISO C の「警告」文字です

• \x は ISO C の 16 進エスケープです

• 無効な 8 進数

• 型の種類は実際には 型名です: 型名

• コメントが "##" で置き換えられます

• コメントがトークンを連結していません

• ISO C では新しい型で置き換えてしまう型の宣言です: 型名

• 文字定数中のマクロ置換

• 文字列リテラル中のマクロ置換

• 文字定数中のマクロ置換は行われません

• 文字列リテラル中のマクロ置換は行われません

• オペランドが符号なしとして処理されました

• 3 文字表記シーケンスが置き換えられました

• ISO C は定数を unsigned 型として扱います: 演算子

• ISO C では演算子の意味が変わります。明示的なキャストを使用してください。

B.2.149 -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.150 -xunroll=n

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

B.2.151 -xustr={ascii_utf16_ushort|no}

ISO10646 UTF-16 文字列リテラルを使用する国際化アプリケーションをサポートする必要がある場合は、このオプション使用します。言い替えれば、このオプションは、オブジェクトファイル内で UTF-16 文字列に変換したい文字列リテラルがコードに含まれる場合に使用します。このオプションを指定しないと、C コンパイラは 16 ビット文字列リテラルの生成、認識を行いません。このオプションは、U"ASCII_<文字列>" という書式の文字列リテラルを unsigned short int 型の配列として認識できるようにします。このような文字列は標準として規定されていないので、このオプションは標準に準拠しない C++ の認識を可能にします。

U"ASCII_<文字列>" 文字列リテラルのコンパイラによる認識を無効にすることができます。コマンド行に指定された、このオプションのもっとも右側のインスタンスがそれより左のインスタンスすべてに優先します。

デフォルトは -xustr=no です。引数を指定しないで -xustr を指定した場合、コンパイラはこの指定を受け付けず、警告を出力します。C または C++ 規格で構文の意味が定義されると、デフォルト値が変わることがあります。

-xustr=ascii_utf16_ushort を指定して U"ASCII_<文字列>" 文字列リテラルを指定しなくても、エラーにはなりません。

すべてのファイルを、このオプションによってコンパイルしなければならないわけではありません。

次の例は、U が先頭に付いた、引用符に入った文字列リテラルを示しています。-xustr を指定するコマンドも示しています。

example% cat file.c
const unsigned short *foo = U"foo";
const unsigned short bar[] = U"bar";
const unsigned short *fun() { return
example% cc -xustr=ascii_utf16_ushort file.c -c

B.2.152 -xvector[= a]

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