cc(1)

名前
cc - C コンパイラ

形式

cc  [-#] [-###] [-A<名前>[(<トークン>)]] [-B[static|dynamic]] [-C] [-c] [-D<名前>[=<トークン>]] [-d[y|n]] [-dalign] [-E] [-errfmt[=[no%]error]] [-erroff[=t[,t...]]] [-errshort[=i]] [-errtags=a] [-errwarn[=t[,t...]]] [-fast] [-fd] [-flags] [-fnonstd] [-fns=[yes|no]] [-fprecision=p] [-fround=r] [-fsimple[=n]] [-fsingle] [-fstore] [-ftrap[=t[,t...]]] [-G] [-g] [-H] [-h<名前>] [-I[-|<ディレクトリ>]] [-i] [-KPIC] [-Kpic] [-keeptmp] [-L<ディレクトリ>] [-l<名前>] [-mc] [-misalign] [-misalign2] [-mr[,<文字列>]] [-mt] [-native] [-nofstore] [-O] [-ofilename] [-P] [-p] [-Q[y|n]] [-qp] [-R<ディレクトリ>[:<ディレクトリ>...]] [-S] [-s] [-U<名前>] [-V] [-v] [-Wc,<引数>] [-w] [-X[c|a|t|s]] [-x386] [-x486] [-xa] [-xalias_level[=a]] [-xarch=a] [-xautopar] [-xbuiltin[=a]] [-xCC] [-xc99[=o]] [-xcache=c] [-xcg89] [-xcg92] [-xchar[=o]] [-xchar_byte_order[=o]] [-xcheck=n] [-xchip=c] [-xcode=v] [-xcrossfile[=n]] [-xcsi] [-xdebugformat=[stabs|dwarf]] [-xdepend=[yes|no]] [-xdryrun] [-xe] [-xexplicitpar] [-xF] [-xhelp=f] [-xhwcprof=[enable|disable]] [-xildoff] [-xildon] [-xinline=[v[,v...]]] [-xipo[=a]] [-xjobs=n] [-xldscope={v}] [-xlibmieee] [-xlibmil] [-xlic_lib=sunperf] [-xlicinfo] [-xlinkopt[=level]] [-xloopinfo] [-xM] [-xM1] [-xMerge] [-xmaxopt[=v]] [-xmemalign=ab] [-xnativeconnect[=a[,a]...]] [-xnolib] [-xnolibmil] [-xOn] [-xopenmp[=i]] [-xP] [-xpagesize=n] [-xpagesize_heap=n] [-xpagesize_stack=n] [-xparallel] [-xpch=v] [-xpchstop] [-xpentium] [-xpg] [-xprefetch[=val[,val]]] [-xprefetch_level=l] [-xprofile=p] [-xprofile_ircache[=path]] [-xprofile_pathmap=collect_prefix:use_prefix] [-xreduction] [-xregs=r[,r...]] [-xrestrict[=f]] [-xs] [-xsafe=mem] [-xsb] [-xsbfast] [-xsfpconst] [-xspace] [-xstrconst] [-xtarget=t] [-xtemp=<ディレクトリ>] [-xthreadvar[=o] [-xtime] [-xtransition] [-xtrigraphs[=[yes|no]] [-xunroll=n] [-xustr={ascii_utf16_ushort|no}] [-xvector[={yes|no}]] [-xvis] [-xvpara] [-Yc,<ディレクトリ>] [-YA,<ディレクトリ>] [-YI,<ディレクトリ>] [-YP,<ディレクトリ>] [-YS,<ディレクトリ>] [-Zll]

機能説明
Sun[tm] Open Network Environment (Sun ONE) Studio 8 C コンパイラ。

マニュアルページは、クイックリファレンスです。C コンパイラとそのオプションの詳細については、『C ユーザーズガイド』を参照してください。

プラットフォーム、環境、新機能、およびソフトウェア修正に関する最新の重要情報については、オンラインの readme
 ファイルを参照してください。このファイルは、

cc -xhelp=readme

を実行して表示できます。

すべての Sun Open Studio 8 Compiler Collection マニュアルの一覧は、このマニュアルページの最後にあります。

README ファイル、ユーザーズガイド、リファレンスマニュアルを含むすべてのインストール済み Sun Open Studio 8 マニュアルには、HTML ブラウザで

file:/opt/SUNWspro/docs/ja/index.html

を指定してアクセスできます。

cc(1) のマニュアルページでは、 Solaris 7、Solaris 8、および Solaris 9 のオペレーティング環境における SVID に準拠したISO C コンパイラオプションについて説明しています。C コンパイラは、 デフォルトで 1999 ISO/IEC C 標準の構造を一部認識することに注意してください。 サポートされる構造については『C ユーザーズガイド』に詳細な説明があります。 コンパイラを 1990 ISO/IEC C 標準に限定したい場合は、 -xc99=%none コマンドを使用してください。

cc は getopt を使用してコマンド行オプションを構文解析します。オプションは 1 文字、または引数を伴う 1 文字として扱われます。詳細は getopt(3C) を参照してください。

cc は、C コンパイルシステムとのインタフェースです。 コンパイル処理には、プリプロセッサ、コンパイラ、 コードジェネレータ、オプティマイザ、 アセンブラ、リンカーが含まれます。 cc は指定されたオプションを処理し、 適切な引数を使って各種の構成要素を実行します。 cc は引数としていくつかの種類のファイルを受け付けます。

接尾辞 .c が付いているファイルは C のソースファイルと見なされ、 前処理、コンパイル、最適化、プロファイリングのための準備、 アセンブル、リンクを行うことができます。 前処理はマクロプロセッサとして使用できますが、その出力は C コンパイラへの入力となることを目的としているため、お勧めできません。 適切なオプションを指定した場合、 コンパイル処理は任意の段階が完了した時点で停止できます。 コンパイル処理でアセンブラの段階まで終了すると、 ソースファイルの名前の .c を .o に置き換えた オブジェクトファイルが生成されます。 しかし、1 つの C ファイルをコンパイルしてすぐにリンクした場合、 通常、接尾辞 .o の付いたファイルは削除されます。 名前が .s で終わるファイルはアセンブリソースファイルと見なされ、 アセンブルとリンクが行われます。
 .S という接尾辞の付いたファイルは、コンパイラの -Xs モードとして扱われ、まず usr/ccs/lib/cpp に渡されて前処理を行なってから、アセンブラに渡されます。 名前が .i で終わるファイルは 前処理済みの C ソースファイルと見なされ、 コンパイル、最適化、プロファイリングのための準備、アセンブル、 リンクを行うことができます。 名前の末尾が .c、.s、.S、.i のいずれでもないファイルは、 リンカーに渡され、動的にリンクされた実行可能ファイルが生成されます。 この実行ファイルの名前は、デフォルトでは a.out になります。

インクリメンタルリンクを行う場合は、リンカー ld の代わりにインクリメンタルリンカー (ild) が使用されます。 詳細は、-xildon および -xildoff を参照してください。

ライブラリの検索に使用するデフォルトディレクトリを変更する場合は、 -Yc, <ディレクトリ> オプションを参照してください。 <ディレクトリ> には、1 つ以上のパスをコロンで区切って指定します。 デフォルトでは、cc は次の順序でライブラリを検索します。
	/opt/SUNWspro/prod/lib
	/usr/ccs/lib
	/usr/lib

64 ビット Solaris 7 用のコンパイル

このバージョンのコンパイラでは、32 ビットまたは 64 ビット Solaris SPARC 版で 64 ビットオブジェクトを生成できます。 生成された実行可能ファイルは、64 ビットカーネルを持つ Solaris ソフトウェアの 64 ビット SPARC または UltraSPARC プロセッサ上 でのみ動作します。

-xarch=v9 オプションのいくつかのバリエーションを使用する、64 ビット Solaris ソフトウェア用のコンパイル。-xtarget または -fast を指定する場合でも、これらのオプションの 1 つを指定しなければなりません。この場合、-xarch=v9 オプションのバリエーションは、-xarch を設定する -xtarget またはその他のオプションの後に指定しなければなりません。 たとえば、次のように指定します。

      -xtarget=ultra -xarch=v9

-xtarget=ultra と -xtarget=ultra2 は -xarch=v8 の指定を含みます。ただし、 -xarch=v9 および -xarch=v9a は含まれません。

64 ビット Solaris オペレーティング環境で -xarch=v9 のバリエーションを使用して共用動的ライブラリを構築する場合、-xcode=pic13 または -xcode=pic32 を指定できますが、これは必須ではありません。

コードアドレスのサイズの指定については、新しいオプション -xcode=abs32|abs64|pic13|pic32 も参照してください。

64 ビット Solaris ソフトウェアは、64 ビットの整数やポインタのデータを有効にするだけではなく、 大規模ファイルもサポートします。

64 ビット Solaris ソフトウェアに関する開発者向けの情報については、 http://docs.sun.com にある『Solaris 64 ビット 開発ガイド』を 参照してください。

オプション

プラットフォーム固有のオプションは、どのプラットフォームでも 受け付けられ、エラーとしては処理されません。 この規則の例外については、各オプションの項で説明しています。

cc では、以下のオプションが解釈されます。

-#  冗長モードでコマンドオプションの展開方法を表示します。呼び出された各構成要素を表示します。

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

-A<名前>[(<トークン>)]
    プリプロセッサ(前処理系)指令 #assert を実行するのと同じように、 <名前> を述語として、指定した <トークン> に対応付けます。
    事前表明 :	system(unix)
    		machine(sparc) (SPARC)
    		machine(i386) (x86)
    		cpu(sparc) (SPARC)
    		cpu(i386) (x86)

    これらは、 -Xc モードでは事前定義されません。

    -A の後にハイフン (-) しかない場合、事前定義されているマクロ ( __ で始まるものを除く) と事前表明はすべて無視されます。

-B [static|dynamic]
    ライブラリのリンクを静的または動的のいずれかに指定します。 静的リンクでは非共有形式のライブラリ、動的リンクでは共有形式のライブラリに なります。 -Bdynamic を指定すると、-lx オプションが 同時に指定されている場合に リンカーは libx.so という名前のファイルを検索し、 次に libx.a という名前のファイルを検索します。 -Bstatic を指定すると、 リンカーは libx.a という名前だけを検索します。 このオプションをコマンド行で 2 回以上指定すると、 トグル (設定の切り替え) として機能します。 このオプションと引数は ld に渡されます。

-C  C プリプロセッサは、プリプロセッサ指令行のコメント以外は、 コメントを削除しません。

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

-D<名前>[=<トークン>]
    プリプロセッサ指令 #define を実行するのと同じように、 <名前> を指定した <トークン> に対応づけます。 <トークン> が指定されない場合は、 トークン 1 を使用します。
    事前定義: unix
    	  sparc (SPARC)
    	  i386 (x86)
    	  sun

    これらは、-Xc モードでは事前定義されません。
    以下の事前定義は、すべてのモードで有効です。
    __sun
    __unix
    __SUNPRO_C=0x550
    __`uname -s`_`uname -r`
    __sparc(SPARC)
    __sparcv9 (-xarch=v9|v9a|v9b 付きの SPARC)
    __i386(x86)
    __BUILTIN_VA_ARG_INCR
    __SVR4
    以下の事前定義は、-Xa および -Xt モードでのみ有効です。
    __RESTRICT
    コンパイラはオブジェクト形式のマクロ
    __PRAGMA_REDEFINE_EXTNAME
    を事前定義して、プラグマを認識できるようにします。

-d[y|n]
    -dy は、リンカーに対して動的リンクを指定します (デフォルト)。 -dn は、リンカーに対して静的リンクを指定します。

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

    注: Solaris 64 ビットコンパイル環境では、システムライブラリの多くは動的ライブラリとしてのみ使用可能です。その結果、このオプションを -xarch=v9 と併用すると致命的エラーが発生します。

-dalign
    (SPARC) -dalign は -xmemalign=8s と同義です。詳細は、 -xmemalign を参照してください。

-E  指定した C ファイルの前処理のみ行い、その結果を標準出力に送ります。 出力には、コンパイルシステムの次の段階で使用するための プリプロセッサ指令が含まれます。 -P オプションも参照してください。

-errfmt[=[no%]error]
    エラーメッセージのはじめに文字列「エラー:」を接頭辞として付け加え、警告メッセージと明確に区別できるようにするには、このオプションを使用します。この接頭辞は、-errwarn によりエラーに変換される警告にも付け加えられます。

    error
        すべてのエラーメッセージに接頭辞「エラー:」を付けます。

    no%error
        エラーメッセージに接頭辞「エラー:」を付けません。

    このオプションを使用しないと、コンパイラはオプションを -errfmt=no%error に設定します。-errfmt を使用して、値を指定しない場合、コンパイラにより -errfmt=error に設定されます。

-erroff[=t[,t...] ]
    cc 警告メッセージを抑制します。エラーメッセージには影響しません。

    t には、次のうちの 1 つまたは複数をコンマで区切って指定します。

    tag tag のリストに指定されているメッセージを抑制します。 -errtags=yes オプションを使用すればメッセージのタグを表示することができます。

    no% tag
        tag 以外のすべてのメッセージを抑制します。

    %all
        すべての警告メッセージを抑制します。

    %none
        すべてのメッセージの抑制を解除します。

    指定の順序は重要です。たとえば、 %all,no%tag によって tag を除く、 すべての警告メッセージが抑制されます。

    デフォルトは、 -erroff=%none です。 -erroff と指定するのは、 -erroff=%all と指定した場合と同等です。

    -erroff オプションにより抑制できるのは、-errtags オプションが使用されるとタグを表示する、C コンパイラフロントエンドからの警告メッセージだけです。エラーメッセージの抑制をより細かく制御するには、#pragma error_messages を使用します。

-errshort[=i]
    型の不一致が検出されたとき、コンパイラがエラーメッセージにどれだけ多くの詳細を生成するかを制御するには、このオプションを使用します。このオプションは、コンパイラによって大規模な集合に関する型の不一致が検出されたときに特に便利です。

    i には以下のいずれかの値を指定できます。

    short
        エラーメッセージは、型の展開なしで短形式で出力されます。集合メンバーは展開されず、関数の引数も戻りの型も展開されません。

    full
        エラーメッセージは、完全冗長形式で出力され、不一致型の完全展開が表示されます。

    tags
        エラーメッセージは、タグ名を持つ型についてはタグ名付きで出力されます。タグ名がない場合、型は拡張形式で出力されます。

    -errshort を使用しない場合、コンパイラがこのオプションを -errshort=full に設定します。-errshort を指定して、値を指定しないと、コンパイラによりオプションは -errshort=tags に設定されます。

    このオプションは累積されず、コマンド行に指定された最後の値を受け入れます。

-errtags=a
    -erroff オプションにより抑制されるか、または -errwarn オプションによって致命的エラーとなる、C コンパイラ フロントエンドからの各警告メッセージのメッセージタグを表示します。C コンパイラドライブや C コンパイルシステムのその他の構成要素からのメッセージにはエラータグはなく、-erroff により抑制されたり、-errwarn により致命的エラーとなることはありません。

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

-errwarn[=t[,t...] ]
    指定された警告メッセージに対して、エラーステータスを返して C コンパイラを終了させるには、-errwarn オプションを使用します。

    t はコンマで区切ったリストで、tag、no%tag、%all、%none の 1 つまたは複数から構成されます。リストの順序は重要です。たとえば、%all,no%tag と指定すると、C コンパイラはタグを除くどのような警告が発行されても致命的エラーステータスを返して終了します。

    C コンパイラにより生成される警告メッセージは、コンパイルエラーチェックの改善や機能の追加のため、リリースごとに異なります。-errwarn=%all を使用してコンパイル時にエラーを返さないコードが、次のコンパイラリリースではコンパイル時にエラーを返すようになる可能性があります。

    -errwarn オプションを使用して C コンパイラをエラーステータスを出して終了させるように指定できるのは、-errtags オプションが使用されるとタグを表示する、C コンパイラフロントエンドからの警告メッセージだけです。

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

    以下の表に -errwarn 値の詳細を示します。

    tag tag で指定したメッセージが警告メッセージとして発行されると、 cc は致命的エラーステータスを返して終了します。tag が発行されない場合は影響しません。

    no%tag
        tag で指定したメッセージが警告メッセージとしてだけ発行された場合に cc が致命的エラーステータスを返して終了することを防ぎます。tag が発行されない 場合は影響しません。このオプションを使用すると、オプションは、tag または %all を使用して以前に指定したメッセージが警告メッセージとして発行されても、 cc は致命的エラーステータスを返して終了しません。

    %all
        どのような警告メッセージが発行されても、 cc は致命的エラーステータスを返して終了します。%all の後に no%tag を指定すると、特定の警告メッセージだけをこの動作から除外できます。

    %none
        どのような警告メッセージが発行されても、 cc は致命的エラーステータスを返して終了することはありません。これはデフォルトです。

-fast
    ベンチマークアプリケーションを最適化する基本オプションセットを選択します。この最適化によって、プログラムの動作を ISO C および IEEE 標準の動作から変更できます。-fast を使ってコンパイルしたモジュールは、リンク時にも -fast を指定する必要があります。

    -fast は、実行可能ファイルを最大の実行時パフォーマンスに調整する開始点として効果的に使用できるマクロオプションです。-fast は、コンパイラのリリースごとに異なるマクロで、ターゲットプラットフォーム固有のオプションに展開されます。-fast の展開をチェックし、適切な -fast オプションを進行中の実行可能ファイル調整プロセスに組み込むには、-# オプションを使用してください。

    -fast オプションは、コンパイルを行なったマシンとは異なるマシン上で 実行する予定のプログラムには適していません。このような場合は、次の例のように、 -fast の後に適切な -xtarget オプションを指定します。

          % cc -fast -xtarget=ultra

    SUID で指定された例外処理に依存する C モジュールの場合、-fast の後に -xnolibmil を指定します。

          % cc -fast -xnolibmil

    -fast オプションはコマンド行でマクロ展開のように動作します。そのため、-fast の後に必要なオプションを指定すれば、展開されたオプションの設定を変更できます。

    -fast を他のオプションと組み合わせた場合は、最後の指定が適用されます。

    前のリリースでは、-fast マクロオプションには -fnonstd が含まれていましたが、今は代わりに -fns が含まれます。

    次のオプションは、 -fast に対して有効になります。

    -fns

    -fsimple=2

    -fsingle

    -ftrap=%none

    -nofstore (x86)

    -xalias_level=basic (SPARC)

    -xarch

    -xbuiltin=%all

    -xdepend

    -xlibmil

    -xmemalign=8s (SPARC)

    -xO5

    -xprefetch=auto,explicit (SPARC)

    注: 最適化の中には、プログラムの動作を仮定しているものもあります。プログラムがこれらの仮定に一致しない場合、アプリケーションがクラッシュしたり、誤った結果となる可能性があります。プログラムが -fast を使用したコンパイルに適しているか否かを判断するには、個々のオプションの説明を参照してください。

    -fast
     コマンドの展開には、マクロ __MATHERR_ERRNO_DONTCARE
     が含まれています。このマクロによって、math.h 中でプロトタイプ化されている数学ルーチンの一部に対して、math.h がパフォーマンスに関連したプラグマを表明します。

        #pragma does_not_read_global_data
        #pragma does_not_write_global_data
        #pragma no_side_effect

    matherr(3M) マニュアルページに解説されているように、例外の場合にコードが errno の戻り値に依存している場合は、-fast オプションの後にマクロ -U__MATHERR_ERRNO_DONTCARE を発行して、このマクロを無効にする必要があります。

    通常このオプションによって、ほとんどのプログラムのパフォーマンスを改善できます。

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

-fd K&R の関数宣言と定義を報告します。

-flags
    利用可能なオプションについて 1 行にまとめて表示します。

-fnonstd
    浮動小数点演算ハードウェアの非標準的な初期化を行います。 -fnonstd オプションによって、浮動小数点オーバーフロー、ゼロ除算、 無効な演算例外によるハードウェアトラップが許可されます。 これらのトラップは SIGFPE シグナルに変換され、 SIGFPE ハンドラがないプログラムはメモリーダンプを残して終了します ( ieee_handler(3m) を参照)。デフォルトでは、IEEE 754 浮動小数点演算は無停止、 アンダーフローは段階的になります。

    -fnonstd は、 -fns および -ftrap=common と同義のマクロです。

-fns [=[yes|no]]
    SPARC 非標準の浮動小数点モードを選択します ( SPARC のみ )。

    SPARC 非標準の浮動小数点モードを選択します。デフォルトの -fns=no は、 SPARC の標準浮動小数点モードです。

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

    -fns は -fns=yes と同義です。 -fns=yes は非標準の浮動小数点を選択します。 -fns=no は標準の浮動小数点を選択します。

    このフラグを設定すると、プログラムが実行を開始するときに、非標準の浮動小数点モードが 有効になります。デフォルトでは、非標準の浮動小数点モードは自動的には 有効になりません。

    一部の SPARC システムでは、非標準の浮動小数点モードは「段階的アンダーフロー」を 無効にします。つまり、小さな演算結果は、非正規数にはならず、ゼロにフラッシュ されます。また、非正規オペランドは自動的にゼロに変更されます。 ハードウェアで段階的アンダーフローと非正規数がサポートされていない SPARC システムでは、このオプションを使用すると、プログラムによっては パフォーマンスが飛躍的に上がることがあります。

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

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

-fprecision=p
    (x86) 浮動小数点制御ワードの丸め精度モードを p に初期化します。p には、single (24 ビット)、 double (53 ビット)、または extended (64 ビット) の いずれかを指定します。 デフォルトの浮動小数点丸め精度は、extended です。

    Intel の場合、浮動小数点丸め精度モードを設定すると、 指数ではなく、精度だけが影響を受けます。

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

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

    r には、 nearest、 tozero、 negative、 positive、 のいずれかを指定します。 デフォルト値は、 -fround=nearest です。

    その意味は、 ieee_flags サブルーチンの場合と同じです。

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

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

-fsimple[=n]
    オプティマイザが浮動小数点演算に関する仮定を単純化できるようにします。 n を指定する場合は、0、1、2 のいずれかを指定します。

    デフォルトは次のとおりです。
    o -fsimple[=n] を指定しない場合、コンパイラは -fsimple=1 を使用します。
    o -fsimple のみを指定して =n を指定しない場合、コンパイラは -fsimple=1 を使用します。

    -fsimple=0
    仮定の単純化を行えないようにします。厳密に IEEE 754 に準拠します。

    -fsimple=1
    適度の単純化を行えるようにします。結果として作成されるコードは、 IEEE 754 に厳密には準拠していませんが、ほとんどのプログラムの数値演算の結果は 変更されていません。

    -fsimple=1 の場合、オプティマイザは以下の事項を前提とします。
    • IEEE 754 のデフォルトの丸めモードおよびトラップモードは、プロセスの初期化後も変化しない。
    • 潜在的な浮動小数点例外以外の目に見える結果を作成しない演算は、削除できる。
    • 無限大または非数をオペランドとして持つ演算は、非数をその結果に伝える必要はない。 たとえば、x*0 は 0 で置き換えることができる。
    • 演算はゼロの符号には依存しない。

    -fsimple=1 を指定した場合は、オプティマイザは必ず四捨五入または例外に応じた最適化を行います。 特に浮動小数点演算は、実行時に適用される丸めモードで異なる結果を作成する 演算で置き換えることはできません。-fast だけを使用すると -fsimple=1 が暗黙的に設定されます。

    -fsimple=2
    多くのプログラムで丸め方法を変更して異なる数値を結果として作成するような、積極的な浮動小数点演算の最適化を可能にします。たとえば、-fsimple=2 を指定すると、オプティマイザは、あるループ内の x/y のすべての計算を x*y に変更しようとします。この場合、x/y はループ内で少なくとも 1 回は計算されることが保証されており、 z=1/y であり、y と z の値はループ実行中は定数値であることが分かっています。

    -fsimple=2 の場合でも、オプティマイザは何も作成しないプログラムに 浮動小数点例外を導入することは許されていません。

-fsingle
    (-Xt モードおよび -Xs モードのみ) コンパイラは、 float 式を倍精度ではなく、単精度として評価します ( -Xa モードまたは -Xc モードのときは、 float 式が常に単精度として評価されるため、 このオプションの影響はありません)。

-fstore
    (x86) 浮動小数点式または関数がある変数に代入されるか、 より短い型の浮動小数点にキャストされる場合に、 コンパイラがその値をレジスタに残さないで、代入値の左の型に変換するようにします。 結果は、四捨五入と切り捨てが適用されるため、 レジスタ値から生成される値とは異なる場合があります。 これはデフォルトのモードです。

-ftrap[=t[,t...] ]
    起動時に IEEE 754 トラップモードを有効にします。

    t には、 %all、 %none、 common、 [no%]invalid、 [no%]overflow、 [no%]underflow、 [no%]division、 [no%]inexact の 1 つまたは複数をコンマで区切って指定します。

    デフォルト値は -ftrap=%none です。

    このオプションは、プログラムの初期化時に確立される IEEE 754 トラップモードを設定します。 処理は左から右に行われます。common は定義により、無効、ゼロ除算、 オーバーフローの例外を指します。

    例: -ftrap=%all,no%inexact は、 inexact を除くすべてのトラップを設定します。

    意味は、以下に示すことを除き ieee_flags サブルーチンの場合と同じです。
    • %all はすべてのトラップモードを起動します。
    • %none はデフォルト設定されており、すべてのトラップモードを終了します。
    • no% を接頭辞としてつけると、そのトラップモードだけを終了します。

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

-G  このオプションを指定すると、リンカーは、 動的にリンクされた実行可能ファイルではなく、共有オブジェクトを作成します。 このオプションは ld に渡されます。 -dn オプションと一緒に使用することはできません。

-g  dbx (1) および パフォーマンスアナライザ analyzer(1) 用の追加シンボルテーブル情報を生成します。

    コンパイラをリンクのみの用途で起動すると、リンカー ld(1) の代わりに、 インクリメンタルリンカー ild(1) がデフォルトになります。-g オプションを指定した場合、コマンド行で -G またはソースファイルを指 定しない限り、ld ではなく ild がデフォルトで自動的に起動され ます。ild の使用を無効にするには、-xildoff を指定します。

    -g を指定して、最適化レベルが -xO3 以下の場合、コンパイラは最大限のシンボル 情報とほぼ完全な最適化を提供します。末尾呼び出しの最適化とバックエンドのインライン化は無効になります。

    -g を指定して、最適化レベルが -xO4 の場合、コンパイラは最大限のシンボル情報と ほぼ完全な最適化を提供します。

    パフォーマンスアナライザの能力をフルに使用するには、-g オプションを指定 してコンパイルを行います。パフォーマンス解析機能の中には -g オプション を指定せずに使用できるものもありますが、注釈付きのソース、機能レベル情報の一 部、コンパイラの注釈メッセージを表示するには、-g を指定してコンパイルを 行う必要があります。詳細については、analyzer(1) のマニュアルページとプロ グラムのパフォーマンス解析』の「データ収集と解析」を参照してください。

    -g を指定した場合に生成される注釈メッセージは、コンパイラがプログラムのコンパイル中に行なった最適化と変換を説明するものです。ソースコードと交互に配置されるメッセージを表示するには、er_src(1) コマンドを使用します。

-H  現在のコンパイル中に取り込まれた各ファイルのパス名を 1 行に 1 つずつ 標準エラーに書き込みます。

-h <名前>
    共有動的ライブラリの名前を指定します。 これにより、複数のライブラリを作成することができます。

    通常は、-h の後に指定する <名前> は、 -o オプションで指定するファイル名と同じにします。 -h と <名前> の間の空白は、あってもなくてもかまいません。

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

    実行時リンカーがライブラリを実行可能ファイルに読み込んだ時点で、 ライブラリファイルからイントリンシック名が、実行可能ファイルと必要な ライブラリファイルのリストにコピーされます。共有ライブラリのイントリンシック 名がない場合、リンカーは共有ライブラリファイルのパスをコピーします。

-I[-|dir]

    -Idir は、#include ファイルが検索されるディレクトリリストに dir を追加します。-I 値は、左から右へ累積されます。

    -I- インクルードファイルの検索規則を次のように変更します。

    o   -I で明示的に指定されない限り、コンパイラは現在のディレクトリを検索しません。 この規則は、#include "foo.h" のようなインクルード文についても同様に適用されます。

    o   #include "foo.h" という形式のインクルードファイルの場合は、 次の順序で検索されます。

        1.  -I オプションで ( -I- の前と後の両方に) 指定されたディレクトリ

        2.  デフォルトのコンパイラインクルードディレクトリ: /opt/SUNWspro/prod/include/cc

        3.  /usr/include

    o   #include <foo.h> という形式のインクルードファイルの場合は、 次の順序で検索されます。

        1.  -I- の後に -I オプションで指定されたディレクトリ

        2.  デフォルトのコンパイラインクルードディレクトリ: /opt/SUNWspro/prod/include/cc

        3.  /usr/include

    上記のように機能するのは、コマンド行中の 1 つ目の -I- オプションだけです。

    -I<ディレクトリ> は usr/include の前に、 <ディレクトリ> を検索して、名前の先頭がスラッシュ (/) でないインクルードファイルを探します。 複数の -I オプションを指定した場合は 指定した順に検索が行われます。

-i  LD_LIBRARY_PATH および LD_LIBRARY_PATH_64 の設定を無視します。

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

-KPIC
    (SPARC) -KPIC コマンドは -xcode=pic32 と同義です。

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

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

-Kpic
    (SPARC) コマンドは -xcode=pic13 と同義です。

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

    (x86) 共用ライブラリ (小型) で使用するために、位置独立コードを生成してください。2**11 一意外部シンボルへの参照を許可します。

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

-L<ディレクトリ>
    ld がライブラリを検索するディレクトリのリストに <ディレクトリ> を 追加します。このオプションと引数は ld に渡されます。

-l<名前>
    lib<名前>.so または lib<名前>.a という名前の オブジェクトライブラリをリンクします。このオプションと 引数は ld に渡されます。 シンボルは指定された順序にライブラリで解決されるため、 コマンド行でのライブラリの指定順序が重要になります。 このオプションはソースファイル名の後に指定してください。

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

-misalign
    (SPARC) -misalign は -xmemalign=1i と同義です。詳細は、 -xmemalign を参照してください。

-misalign2
    (SPARC) -misalign2 は -xmemalign=2i と同義です。詳細は、 -xmemalign を参照してください。

-mr[,<文字列>]
    -mr はオブジェクトファイルの .comment セクションから すべての文字列を削除することができます。このフラグを使用すると、 mcs -d が起動されます。

    -mr,<文字列> はオブジェクトファイルの .comment セクションからすべての文字列を削除し、 代わりに <文字列> を挿入します。 <文字列> に空白が埋め込まれている場合は、二重引用符で括ります。 <文字列> がなければ、.comment セクションは空になります。 このフラグを使用すると、 mcs -d -a が起動されます。

-mt D_REENTRANT をプリプロセッサに渡し、コマンド行のその他のユーザーが指定したライブラリすべての後ろに -lthread を付加します。 マルチスレッドのプログラムに対しては、コンパイルおよびリンク時点で -mt オプションを使用しなければなりません。 実行を高速化する場合、このオプションは 複数プロセッサシステムを必要とします。単一プロセッサ システムでは、このオプションを指定した結果として作成される実行可能プログラムは、実行速度が遅くなります。

-   native

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

-nofstore
    (x86) 浮動小数点式または関数がある変数に代入されるか、 より短い型の浮動小数点にキャストされる場合に、代入値の左の型に変換せずに、 コンパイラがその値をレジスタに渡すようにします。

-O  -xO2 と同等です。

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

-P  指定した C ファイルだけを前処理し、 その結果を接尾辞 .i が付いたファイル名に出力します。 この出力には、-E と異なり、前処理の行指令は含まれません。

-p  prof(1) によるプロファイルの作成に使用するデータを収集するための オブジェクトコードを生成します。 また、リンクを行う場合には、 プロファイリングされたシステムライブラリを使用します。 オブジェクトプログラムの実行が正常に終了すると、 ファイル mon.out が作成されます。 これにより、prof を使って実行プロファイルを生成することができます。

-Q[y|n]
    出力ファイルに識別情報を出力するかしないかを指定します。 -Qy を指定すると、 起動された各コンパイルツールについての識別情報を 出力ファイルに追加します (デフォルトの動作)。 これは、ソフトウェア管理を行うときに役立ちます。 -Qn を指定すると、この情報の出力が抑制されます。

-qp -p と同じです。

-R <ディレクトリ>[:<ディレクトリ>...]
    実行時リンカーがライブラリを検索するディレクトリのリスト。 各ディレクトリ名はコロンで区切ります。 指定したディレクトリは、それが NULL でなければ 出力されるオブジェクトファイルに記録され、実行時リンカーに渡されます。

    LD_RUN_PATH と -R オプションが同時に指定された場合は -R オプションが優先されます。

-S  指定した C ファイルのコンパイル行い、 アセンブルとリンクは行いません。 アセンブリ言語出力が接尾辞 .s を付けた名前のファイルに残されます。

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

-U<名前>
    <名前> の定義を無効にします。このオプションは、コマンド行ドライバにより 置かれたものを含む同じコマンド行上の -D により作成されたプリプロセッサ シンボル <名前> の初期定義を削除します。

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

    同じ <名前> を -D と -U の両方で指定した場合は、 指定した順序にかかわらず <名前> は定義されません。

-V  起動された各ツールのバージョン情報を、標準エラー出力に書き込みます。

-v  意味検査をより厳しく行い、 指定された C ファイルに対する lint と同様の検査を可能にします。

-Wc,<引数>
    <引数> を c に渡します。 各引数は 1 つのコンマだけで区切らなければなりません (コンマは、 直前にバックスラッシュ文字 (\) を置いてエスケープすることで 引数の一部にできます)。 -W の引数はすべて、通常のコマンド行引数の後に渡されます。

    c には、次のいずれかを指定することができます。

    a   アセンブラ (fbe) (gas)
    c   C コードジェネレータ (cg) (SPARC)
    d   cc ドライバ (1)
    h   中間コードの翻訳 (ir2hf)(Intel)
    i   手続き間の分析 (ube_ipa)(Intel)
    l   リンクエディタ (ld)
    m   mcs
    0   内部手続きオプティマイザ (SPARC)
    p   プリプロセッサ (cpp)
    u   C コードジェネレータ (ube), (Intel)
    0   コンパイラ (acomp) (ssbd SPARC)
    2   オプティマイザ (iropt) (SPARC)、

    (1) 注: -Wd では、このマニュアルページにリストされている cc オプションを C コンパイラに渡すことはできません。

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

    引数をツールに渡す順序は、 指定する他のコマンド行オプションによって変わることがあります。

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

    このオプションは error_messages プラグマより優先されます。

-X[c|a|t|s]
    ISO C 標準にどの程度準拠するかを指定します。-xc99 の値は、-X オプションに ISO C 標準のどのバージョンが適用されるかに影響します。-xc99 オプションはデフォルトで、1999 ISO/IEC C 標準のサブセットをサポートする -xc99=%all に設定されます。-xc99=%none は 1990 ISO/IEC C 標準をサポートします。

    c (conformance - 準拠)
        ISO C に厳密に準拠し、K&R C の拡張互換性を含みません。 コンパイラは、ISO C 以外の構造を持つプログラムに対してエラーメッセージや 警告メッセージを出力します。事前定義されたマクロ __STDC__ には、 -Xc オプションと共に 1 の値が含まれています。

    a   これはデフォルトのコンパイラモードです。ISO C と K&R C の拡張互換性が含まれます。ISO C に従って意味処理が行われます。K&R C と ANSI C の意味が異なる場合、ANSI C に準拠した解釈を行います。 -Xa オプションを -xtransition オプションと共に使うと、コンパイラは異なる意味に関する警告を発します。 これはデフォルトのコンパイラモードです。事前定義されたマクロ __STDC__ には、 -Xa オプションと共に 0 の値が含まれています。

    t (transition - 移行)
        ISO C と K&R C の拡張互換性が含まれます。ISO C に従った 意味処理の変更は行いません。K&R C と ISO C の意味が異なる場合、 K&R C に準拠した解釈を行います。 -Xt オプションを -xtransition オプションと共に使うと、コンパイラはこの矛盾に関する警告を発します。 事前定義されたマクロ __STDC__ には、 -Xt オプションと共に 0 の値が含まれています。

    s (K&R C)
        コンパイラは、Sun ISO C と K&R C との間で動作が異なるすべての言語構造に ついて、警告メッセージを出力します。このオプションでは前処理用に cpp が 呼び出され、__STDC__ は定義されません。

    事前定義されたマクロ __STDC__ の値は、-Xt および -Xa の場合は 0、-Xc の場合は 1 になります ( -Xs の場合には定義されません)。動作が異なることに関する警告メッセージは、 適切なコーディングによって表示されないようにすることができます。 たとえば、キャストを使用することによって整数拡張の変更に対する警告を 回避することができます。

-x386
    (x86) 80386 プロセッサ用に最適化します。

-x486
    (x86) 80486 プロセッサ用に最適化します。

-xa このオプションは古い形式とみなされます。代わりに、 -xprofile=tcov
     を使用してください。

-xalias_level[=a]
    a には、any、basic、weak、layout、 strict、std、strong のいずれかを指定します。 このフラグを使用すると、指定した別名解析のレベルが翻訳単位全体に渡って、つまり、 翻訳単位中のすべてのメモリー参照に対して適用されます。-xalias_level を を指定しなかった場合は、コンパイラは -xalias_level=basic を適用します。 -xalias_level を値を指定しないで指定した場合は、コンパイラは -xalias_level=layout を適用します。

    o any

    コンパイラは、このレベルでは、すべてのメモリー参照が別名設定できるとみなします。型に基づいた別名解析は行いません。

    o basic

    -xalias_level=basic オプションを使用すると、コンパイラは、さまざまな C の基本型に関連するメモリー参照が相互に別名設定しないとみなします。また、コンパイラは、他のすべての型への参照が C の基本型と同様に相互に別名設定できるとみなします。コンパイラは、char * を使用する参照が他のすべての型を別名設定できるとみなします。

    o weak

    -xalias_level=weak オプションを使用すると、コンパイラは、構造体ポインタですべての構造体の型を指すことができるとみなします。コンパイルされるソース内の式として参照される、あるいはコンパイルされるソースの外部から参照される型参照を保持する構造体または共用体の型は、コンパイルされるソース内の式の前に宣言されなければなりません。

    それには、コンパイルされるソースの式内で参照されるオブジェクトの型を参照する型を含むプログラムのすべてのヘッダーファイルを取り込みます。

    -xalias_level=weak のレベルでは、コンパイラは、さまざまな C の基本型に関連するメモリー参照が相互に別名設定しないとみなします。コンパイラは、char * を使用する参照が他のすべての型に関連するメモリー参照を別名設定するとみなします。

    o layout

    コンパイラは、メモリー内で同じ型シーケンスを持つ型に関連するメモリー参照が相互に別名設定できるとみなします。コンパイラは、メモリー内で同一に見えない型を保持する 2 つの参照が相互に別名設定するとはみなしません。構造体の初期メンバーがメモリー内で同一に見える場合は、コンパイラは、さまざまな型の構造体からの 2 つのメモリーアクセスが相互に別名設定するとみなします。ただしこのレベルでは、2 つの構造体の間でメモリー内では同一に見える共通の初期シーケンスメンバーの外側にある異なる構造体オブジェクトのフィールドには、構造体へのポインタを使ってアクセスしないでください。コンパイラは、このような参照が相互に別名設定するとはみなさないためです。

    -xalias_level=layout のレベルでは、コンパイラは、さまざまな C の基本型に関連するメモリー参照が相互に別名設定するとはみなしません。コンパイラは、char * を使用する参照が他のすべての型に関連するメモリー参照を別名設定できるとみなします。

    o strict

    コンパイラは、タグを削除すると同一となる構造体や共用体などの型に関連するメモリー参照が相互に別名設定できるとみなします。これに反して、コンパイラは、タグの削除後に同一にならない型に関連するメモリー参照が相互に別名設定するとはみなしません。ただし、コンパイルされるソースの式内で参照される、あるいはコンパイルされるソースの外部から参照されるオブジェクトの一部である型の参照を含む構造体または共用体の型を、コンパイルされるソースの式の前に宣言する必要があります。

    それには、コンパイルされるソースの式内で参照されるオブジェクトの型を参照する型を含むプログラムのすべてのヘッダーファイルを取り込みます。

    -xalias_level=strict のレベルでは、コンパイラは、さまざまな C の基本型に関連するメモリー参照が相互に別名設定するとはみなしません。コンパイラは、char * を使用する参照が他のすべての型を別名設定できるとみなします。

    o std

    コンパイラは、型とタグが同じでなければ別名設定できるとみなしませんが、char * を使用する参照は他のすべての型を別名設定できるとみなします。この規則は、1999 年制定の ISO C 標準にあるポインタの非参照に関する制約と同じです。この規則に則ったプログラムは移植性が高く、最適化することで大きなパフォーマンス向上が得られます。

    o strong

    std レベルと同じ制約が適用されるほかに、コンパイラが、型 char * のポインタの使用を型 char のオブジェクトのアクセスに限定します。コンパイラは、内部ポインタも存在しないものとみなします。内部ポインタは、構造体オブジェクトのメンバーをポイントするポインタとして定義されます。

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

    このオプションは、コンパイラが生成するコードを、指定した命令セットアーキテクチャの命令だけに 制限します。このオプションを使用すると、ターゲット アーキテクチャに固有の命令が使用できない可能性があります。 このオプションは、バイナリプログラムの移植性に影響を及ぼす可能性があります。 詳細については、この節の最後の「注意」および「警告」の項を参照してください。

    コンパイルとリンクを別々のステップで行う場合、両方のステップで -xarch に同じ値を指定する必要があります。

    値:

    SPARC プラットフォームの場合

    値   意味

    generic
        ほとんどの 32 ビットプラットフォームアーキテクチャで良好なパフォーマンスを得られるようにパラメータ を設定します。

        これはデフォルトです。このオプションは、どのプロセッサでも大きくパフォーマンスを落とさず、 またほとんどのプロセッサで良好なパフォーマンスを得られるような最良の命令セットを使用します。 「最良な命令セット」の内容は、新しいリリースごとに調整される可能性があります。このリリースの -xarch=generic 値を確認するには、-xdryrun オプションを指定します。

    native
        native    ホスト環境で最良のパフォーマンスを得られるようにパラメータを設定します。これは -fast オプションのデフォルトです。コンパイラは、現在コンパイラを実行しているシステムのプロセッサに最も適した設定を選択します。

    v7  SPARC-V7 ISA 用にコンパイルします。

        V7 ISA上で良好なパフォーマンスを得るためのコードを生成します。これは、V8 ISA上で最良なパフォ ーマンスを得るための最良の命令セットと同じですが、整数の mul と div 命令、および fsmuld 命令は含まれていません。

        例: SPARCstation 1、SPARCstation 2

    v8a V8a 版の SPARC-V8 ISA 用にコンパイルします。

        定義上、V8a は V8 ISA を意味します。ただし、fsmuld 命令は含まれていません。V8a ISA 上で良好な パフォーマンスを得るためのコードを生成します。

        例: microSPARC I チップアーキテクチャに基づくすべてのシステム

    v8  SPARC-V8 ISA 用にコンパイルします。

        V8 アーキテクチャ上で良好なパフォーマンスを得るためのコードを生成し ます。

        例: SPARCstation 10

    v8plus
        V8plus 版の SPARC-V9 ISA 用にコンパイルします。

        定義上、V8plus は V9 ISA を意味します。ただし、V8plus ISA 仕様で定義されている 32 ビットサブセット に限定されます。さらに、VIS (Visual Instruction Set) と実装に固有な ISA 拡張機能は含まれていません。 このオプションは V8plus ISA 上で良好なパフォーマンスを得るためのコードを生成します。生成される オブジェクトコードは SPARC-V8+ ELF32 形式であり、Solaris UltraSPARC 環境でのみ実行できます。 つまり、V7 または V8 のプロセッサ上では実行できません。

        例: UltraSPARC チップアーキテクチャに基づくすべてのシステム

    v8plusa
        V8plusa 版の SPARC-V9 ISA 用にコンパイルします。

        定義上、V8plusa は V8plus アーキテクチャ + VIS (Visual Instruction Set) バージョン 1.0 + UltraSPARC 拡張機能を意味します。 このオプションは UltraSPARC アーキテクチャ上で良好なパフォーマンスを得るた めのコードを生成します。ただし、V8plus 仕様で定義されている 32 ビットサブセットに限定されます。生成 されるオブジェクトコードは SPARC-V8 + ELF32 形式であり、Solaris UltraSPARC 環境でのみ実行できま す。つまり、V7 または V8 のプロセッサ上では実行できません。

        例: UltraSPARC チップアーキテクチャに基づくすべてのシステム

    v8plusb
        UltraSPARC-III 拡張機能を持つ、V8plusb 版の SPARC-V8plus ISA 用にコンパイルします。

        UltraSPARC アーキテクチャ + VIS (Visual Instruction Set) バージョン 2.0 + UltraSPARC-III 拡張機能 用のオブジェクトコードを生成します。生成されるオブジェクトコードは SPARC-V8 + ELF32 形式です。 このコードは Solaris UltraSPARC-III 環境でのみ実行できます。UltraSPARC-III アーキテクチャ上で良好 なパフォーマンスを得るための最良のコードを使用します。

    v9  SPARC-V9 ISA 用にコンパイルします。

        V9 SPARC アーキテクチャ上で良好なパフォーマンスを得るためのコードを生成します。生成される .o オブジェクトファイルは ELF64 形式です。このファイルは同じ形式の SPARC-V9 オブジェクトファイルと しかリンクできません。生成される実行可能ファイルは、64 ビット対応の Solaris オペレーティング環境 が動作する、64 ビットカーネルを持つ UltraSPARC プロセッサ上でしか実行できません。

        -xarch=v9 は、64 ビット対応の Solaris オペレーティング環境でコンパイルする場合にのみ使用できます。

    v9a UltraSPARC 拡張機能を持つ SPARC-V9 ISA 用にコンパイルします。

        SPARC-V9 ISA に VIS (Visual Instruction Set) と UltraSPARC プロセッサに固有の拡張機能を追加 します。V9 SPARC アーキテクチャ上で良好なパフォーマンスを得るためのコードを生成します。生成 される .o オブジェクトファイルは ELF64 形式です。このファイルは同じ形式の SPARC-V9 オブジェクト ファイルとしかリンクできません。生成される実行可能ファイルは、64 ビット対応の Solaris オペレーティ ング環境が動作する、64 ビットカーネルを持つ UltraSPARC プロセッサ上でしか実行できません。

        -xarch=v9a は、64 ビット対応 Solaris オペレーティング環境でコンパイルする場合にのみ使用できます。

    v9b UltraSPARC-III 拡張機能を持つ SPARC-V9 ISA 用にコンパイルします。

        V9a 版の SPARC-V9 ISA に UltraSPARC-III 拡張と VIS バージョン 2.0 を追加します。Solaris UltraSPARC-III 環境で良好なパフォーマンスを得るためのコードを生成します。生成される .o オブジ ェクトファイルは SPARC-V9 ELF64 形式です。同じ形式の SPARC-V9 オブジェクトファイルとしかリンク できません。生成される実行可能ファイルは、64 ビット対応の Solaris オペレーティング環境が動作する、 64 ビットカーネルを持つ UltraSPARC-III プロセッサ上でしか実行できません。

        -xarch=v9b は、64 ビット対応の Solarisオペレーティング環境でコンパイルする場合にのみ使用できます。

    注意

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

    o   v8plus でコンパイルされたオブジェクトバイナリファイル (.o) と v8plusa でコンパイルした .o ファイルは、SPARC v8plusa 互換のプラットフォーム上でのみリンク、および同時に実行できます。

    o   v8plus 、 v8plusa 、および v8plusb でそれぞれコンパイルされたオブジェクトバイナリファイル (.o) は、SPARC V8plusb 互換プラットフォーム 上でのみリンクおよび同時に実行できます。

    o   -xarch の値 v9 、 v9a および v9b は、UltraSPARC 64 ビット Solaris オペレーティング環境でのみ、指定できます。

    o   v9 と v9a でそれぞれコンパイルされたオブジェクトバイナリファイル (.o) は、SPARC V9a 互換プラットフォーム上でのみリンクおよび同時に実行できます。

    o   v9 、 v9a 、および v9b でそれぞれコンパイルされたオブジェクトバイナリファイル (.o) は、SPARC V9b 互換プラットフォー ム上でのみリンクおよび同時に実行できます。

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

    x86 プラットフォームの場合

    値   意味

    generic
        命令セットを Intel x86 アーキテクチャに限定します。これは 386 と同じオプションです。

    native
        このシステムでは性能を落とさずコンパイルします。これはデフォルトです。このオプションは、どのプロセッサでも大きく性能を落とさず、またほとんどのプロセッサで良好なパフォーマンスを得られるような最良の命令セットを使用します。「最良な」命令セットの定義は、新しいリリースごとに調整される可能性があります。

    386 命令セットを Intel 386/486 アーキテクチャに限定します。

    pentium_pro
        命令セットを pentium_pro アーキテクチャに限定します。

    デフォルト:

    -xarch=isa を指定しないと、 -xarch=generic が使用されます。

    相互の関連性:

    このオプションは単体でも使用できますが、 -xtarget オプションの展開の一部でもあります。したがって、特定の -xtarget オプションによって設定された -xarch の値を変更するためにも使用できます。たとえば、 -xtarget=ultra2 は -xarch=v8 -xchip=ultra2 -xcache=16/32/1:512/64/1 に展開されます。次のコマンドでは、 -xarch=v8plusb は、 -xtarget=ultra2 の展開で設定された -xarch=v8 より優先されます。

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

    警告:

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

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

    スレッド管理を独自に行う場合は、 -xautopar は指定しないでください。

    このオプションを指定して作成したプログラムを 高速に実行するには、マルチプロセッサシステムが必要になります。 シングルプロセッサシステムで実行すると、生成されたバイナリファイルの 実行速度は遅くなります。

    搭載されているプロセッサの数を確認するには、 psrinfo コマンドを使用します。

    複数のプロセッサの使用を要求するには、 PARALLEL 環境変数を設定します。デフォルトは 1 です。

    o   利用可能な数を超えたプロセッサを要求することはできません。

    o   N がマシン上のプロセッサ数を表わす場合、 1 ユーザー、マルチプロセッサシステムで実行するには、 PARALLEL=N-1 と指定します。

    -xautopar を使用して、コンパイルとリンクを一度に実行する場合、 リンク時にマルチタスクライブラリとスレッド環境で安全な C 実行時ライブラリ が自動的に取り込まれます。また -xautopar を使用して、コンパイルとリンクを別々に実行する場合は、 cc -xautopar でリンクする必要があります。

-xbuiltin[=a]
    標準ライブラリ関数を呼び出すコードをより高度に最適化したい場合は、 -xbuiltin[=(%all|%none)] コマンドを使用してください。 math.h や stdio.h で定義されているような多くの標準ライブラリは、 さまざまなプログラムで共通して使用されています。このコマンドを使用すると、 パフォーマンスの向上が期待できる場合、コンパイラが組み込み関数またはシステム関数を 代用します。

    a は (%all|%none) を代用します。

    このコマンドの第一のデフォルトは -xbuiltin=%none です。これは、コンパイラが標準ライブラリの関数をまったく代用または インライン化しないことを意味しています。 第一のデフォルトは、 -xbuiltin が指定されなかった場合に適用されます。

    このコマンドの第二のデフォルトは -xbuiltin=%all です。これは、最適化の改善が見込まれる場合に、コンパイラが組み込み関数を 代用するか、標準ライブラリ関数をインライン化することを意味しています。 第二のデフォルトは、 -xbuiltin が引数なしで指定された場合に適用されます。

    -fast でコンパイルした場合は、 -xbuiltin の引数は %all に設定されます。

-xCC
    -xc99=%none と -xCC を指定すると、コンパイラは C++ 形式のコマンドを受け入れます。特に「//」を使用して、コメントの開始を表すことができます。

-xc99[=o]
    -xc99 フラグは、C99 標準 (ISO/IEC 9899:1999、プログラミング言語 C) 移行に実装された機能の、コンパイラによる認識を制御します。

    o には、以下の値をコンマで区切って指定することができます。

    値   意味

    [no%]lib
        1990、1999 C 標準の両方で規定されている 1999 C 標準ライブラリのルーチンのセマンティックスを有効にします [しません]。

    %all
        C99 に準拠する機能が認識されます。

    %none
        C99 に準拠する機能は認識されません。

    -xc99 の指定を省略すると、-xc99=%all,no%lib がデフォルトで指定されます。

    -xc99 を値なしで指定すると、-xc99=%all が設定されます。

    注意事項:
    コンパイラのサポートレベルは、デフォルトで『C ユーザーズガイド』にリストされる C99 の機能ですが、/use/include において Solaris ソフトウェアが提供する標準ヘッダーは 1999 ISO/IEC C 標準にまだ合致していません。エラーメッセージが表示された場合は、-xc99=%none を使用して、これらのヘッダーのために 1990 ISO/IEC C 標準に準拠した動作を指定してください。

-xcache=c
    オプティマイザ用のキャッシュ特性を定義します。

    c は次のいずれか 1 つを指定します。

    •   generic

    •   native

    •   s1/l1/a1

    •   s1/l1/a1:s2/l2/a2

    •   s1/l1/a1:s2/l2/a2:s3/l3/a3

    si/li/ai は次のように定義されます。

    si  レベル i のデータキャッシュのサイズ、キロバイト単位

    li  レベル i のデータキャッシュのラインサイズ、バイト単位

    ai  レベル i のデータキャッシュのマッピング方法

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

    このオプションは、オプティマイザが使用可能なキャッシュ 特性を指定します。特定のキャッシュ特性が 必ず使用されるわけではありません。

    -xcache の値は次のとおりです。

    generic
        ほとんどのアーキテクチャで良好なパフォーマンスを得られるように パラメータを設定します。これがデフォルトです。

    native
        現在のホスト環境で良好なパフォーマンスを得られるようにパラメータを 設定します。

    s1/l1/a1
        レベル 1 のキャッシュ特性を定義します。

    s1/l1/a1:s2/l2/a2
        レベル 1 および 2 のキャッシュ特性を定義します。

    s1/l1/a1:s2/l2/a2:s3/l3/a3
        レベル 1、2、および 3 のキャッシュ特性を定義します。

    例: -xcache=16/32/4:1024/32/1 では、次のように指定されます。

    レベル 1 のキャッシュサイズ: レベル 2 のキャッシュサイズ:

    16 K バイト
        1024 K バイト

    ラインサイズ 32 バイト
        ラインサイズ 32 バイト

    4 ウェイアソシアティブ
        ダイレクトマッピング

-xcg89
    (SPARC) このオプションは、 -xarch=v7 、 -xchip=old 、および -xcache=64/32/1 と同義のマクロです。

-xcg92
    (SPARC) このオプションは、 -xarch=v8 、 -xchip=super 、および -xcache=16/32/4:1024/32/1 と同義のマクロです。

-xchar=o
    このオプションは、char 型が unsigned と定義されているシステムからのコードの移植を容易にするためのものに過ぎません。このようなシステムからの移植を行わない場合は、このオプションは使用しないでください。char 型の符号に依存するコードだけを signed と unsigned を明示的に指定するために書き換える必要があります。o には以下のいずれかの値を指定できます。

    o   signed: 宣言された文字定数と変数を符号付き char として扱います。この設定は、コンパイルされたコードの動作に影響し、ライブラリルーチンの動作には影響しません。

    o   s: signed と同じです。

    o   unsigned: 宣言された文字定数と変数を符号なし char として扱います。この設定は、コンパイルされたコードの動作に影響し、ライブラリルーチンの動作には影響しません。

    o   u: unsigned と同じです。

    -xchar を指定しないと、コンパイラは -xchar=s とみなします。値を 指定せずに -xchar を指定すると、コンパイラは -xchar=s とみなしま す。

    -xchar オプションは、-xchar を使用してコンパイルされたコードにつ いてのみ char 型の値の範囲を変更します。このオプションは、システムルーチンまた はヘッダーファイルについては char 型の値の範囲を変更しません。 特に limits.h によって定義される CHAR_MAX と CHAR_MIN の値は、このオプ ションが使用されても変更されません。このため、CHAR_MAX と CHAR_MIN は、char で符号化できる値の範囲を表さなくなります。

    -xchar の使用する場合、事前定義されたシステムマクロに対する char の 比較には、特に注意してください。マクロの値には符号付きのものもあるからです。 これは、マクロを通してアクセスされるエラーコードを返すどのルーチンにもほとんど 共通なことです。エラーコードはふつう負の値なので、こうしたマクロの値と char と を比較すると、結果は常に偽です。負の数が符号なし型と等しくなることは決してあり ません。

    ライブラリからエクスポートされたインタフェースについては、-xchar を使用 してルーチンをコンパイルすることは絶対にやめてください。Solaris ABI では char 型を符号付きと指定しており、それに従ってシステムライブラリが動作します。char 型を符号なしとして扱う場合のシステムライブラリへの影響は幅広くテストされてはい ません。このオプションを使用するのではなく、char 型が符号付き、符号なしのいず れでも動作するようにコードを変更してください。char 型の符号はコンパイラ、オペ レーティングシステムによって異なります。

-xchar_byte_order=o
    指定したバイト順序で複数文字定数の文字を並べることにより、整定数を生成します。 o には、次の値のいずれかを代入できます。

    o   low: 複数文字定数の文字を低位から高位へのバイト順序で並べます。

    o   high: 複数文字定数の文字を高位から低位へのバイト順序で並べます。

    o   default: 複数文字定数の文字を、コンパイルモード -X[a|c|s|t] により決定されるバイト 順序で並べます。

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

    n は以下のいずれかの値でなければなりません。

    値   意味

    %all
        すべての -xcheck チェックを実行します。

    %none
        -xcheck を行いません。

    stkovf
        スタックオーバーフローの実行時チェックを可能にします。

    no%stkovf
        スタックオーバーフローチェックを行いません。

    -xcheck を指定しないと、コンパイラはデフォルトで -xcheck=%none を設定します。-xcheck を引数なしで指定すると、コンパイラはデフォルトで、スタックオーバーフローの実行時チェックを行う -xcheck=%all を設定します。

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

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

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

    このオプションは単独でも使用可能ですが、 -xtarget オプションを展開したものの一部です。これは主に、 -xtarget オプションで指定された値を無効にする(変更する)ために使用します。

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

    これは次のことに影響を与えます。

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

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

    •   意味的に等しい命令が複数ある場合に、実際に使用する命令

    -xchip に指定する値の意味は次のとおりです。

    generic
        ほとんどの SPARC プラットフォームアーキテクチャで良好なパフォーマンスを得られるように パラメータを設定します。これがデフォルトです。

    native
        ホスト環境で良好なパフォーマンスを得られるようにパラメータを設定します。

    old SuperSPARC より旧式のプロセッサ用に最適化します。

    super
        SuperSPARC プロセッサ用に最適化します。

    super2
        SuperSPARC II プロセッサ用に最適化します。

    micro
        microSPARC プロセッサ用に最適化します。

    micro2
        microSPARC II プロセッサ用に最適化します。

    hyper
        hyperSPARC プロセッサ用に最適化します。

    hyper2
        hyperSPARC II プロセッサ用に最適化します。

    powerup
        Weitek(R) PowerUp(TM) プロセッサ用に最適化します。

    ultra
        UltraSPARC(TM) プロセッサ用に最適化します。

    ultra2
        UltraSPARC II プロセッサ用に最適化します。

    ultra2e
        UltraSPARC IIe プロセッサ用に最適化します。

    ultra2i
        UltraSPARC IIi プロセッサ用に最適化します。

    ultra3
        UltraSPARC(TM) III プロセッサ用に最適化します。

    ultra3cu
        UltraSPARC III Cu プロセッサ用に最適化します。

    386 Intel 386 アーキテクチャ用に最適化します。

    486 Intel 486 アーキテクチャ用に最適化します。

    pentium
        Intel Pentium アーキテクチャ用に最適化します。

    pentium_pro
        Intel pentium_pro アーキテクチャ用に最適化します。

-xcode=v
    コードアドレス空間を指定します ( SPARC のみ )。

    注: -xcode=pic13 または -xcode=pic32 を指定して共有オブジェク トを構築することを強く推奨します。-xarch=v9 -xcode=abs64 および -xarch=v8 -xcode=abs32 を指定して、使用可能な共有オブジェクトを構築す ることはできますが、効率的ではありません。-xarch=v9 -xcode=abs32 また は -xarch=v9 -xcode=abs44 を使用して構築した共有オブジェクトは動作しま せん。

    -xcode の値は、次のとおりです。

    abs32
        32 ビット絶対アドレスを生成します。
        コード、データ、bss を合計したサイズは 2**32 (2 の 32 乗) バイトに制限されます。 これは 次に示す 32 ビットアーキテクチャでデフォルトです。 -xarch=(generic|v7|v8|v8a|8plus|v8plusa|v8plusb)

    abs44
        44 ビット絶対アドレスを生成します。
        コード、データ、bss を合計したサイズは 2**44 バイトに制限されます。次に示す 64 ビットアーキテクチャだけで利用できます。 -xarch=(v9|v9a|v9b)

    abs64
        64 ビット絶対アドレスを生成します。
        次に示す 64 ビットアーキテクチャだけで利用できます。 -xarch=(v9|v9a|v9b)

    pic13
        共有ライブラリで使用するための位置独立コード (小規模モデル) を生成します。
        -Kpic と同義です。32 ビットアーキテクチャでは最大 2**11 まで、 64 ビットアーキテクチャでは最大 2**10 までの固有の外部シンボルを参照できます。

    pic32
        共有ライブラリで使用するための位置独立コード (大規模モデル) を生成します。
        -KPIC と同義です。32 ビットアーキテクチャでは最大 2**30 まで、 64 ビットアーキテクチャでは最大 2**29 までの固有の外部シンボルを参照できます。

    SPARC V8 と V7 では、デフォルトは -xcode=abs32 です。 SPARC V9 と UltraSPARC V9 (-xarch=v9|v9a) では、デフォルトは -xcode=abs64 です。

    64 ビット Solaris オペレーティング環境で -xarch=v9 または v9a または v9b を使用して動的な共有ライブラリを構築する場合、-xcode=pic13 または -xcode=pic32 を指定できますが、この指定は必須ではありません。

-xcrossfile[=n]
    複数のソースファイル全体に対する最適化とインライン化を 有効にします (SPARC のみ)。

    n を指定する場合は、0 か 1 のどちらかです。

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

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

    -xcrossfile は、 -xO4 または -xO5 と併用したときだけ有効です。

    このコンパイルから生成されるファイルは、インライン化のため、相互に依存しています。 したがって、1 つのプログラムにリンクするときには、1 つの単位として扱う必要が あります。任意の 1 つのルーチンを変更し、そのファイルを再コンパイルした場合は、 すべてのファイルを再コンパイルしなければなりません。

    つまり、このオプションを使用すると、メークファイルの構成にも影響があります。

    コマンド行に何も指定しない場合、デフォルトの -xcrossfile=0 が適用され、複数のファイルに渡る最適化は行われません。 -xcrossfile は -xcrossfile=1 と同義です。

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

-xcsi
    -xcsi は C コンパイラに、ISO C ソース文字コード要件に準拠しないロケールで書かれたソースコードを許可します。これらのロケールは ja_JP.PCK を含んでいます。

    このようなロケールを扱うために必要なコンパイラの変換フェーズは、コンパイルに 膨大な時間がかかる場合があることに注意してください。 このオプションを使用するのは、これらのロケールの一つのソース文字を含む ソースファイルをコンパイルする場合だけにしたほうがよいでしょう。

    -xcsi を出力しない場合、コンパイラは、ISO C ソース文字コード要件に準拠しないロケール で書かれたソースコードを認識しません。

-xdebugformat=[stabs|dwarf]
    C コンパイラのデバッガ情報は stabs 形式から dwarf 形式に移行中です。 dwarf 形式は 『 DWARF Debugging Information Format 』で定められています。 このリリースでのオプションのデフォルトの設定は -xdebugformat=stabs です。

    デバッグ情報を読み取るソフトウェアを保持する場合、 このオプションを使用してツールを stab 形式から dwarf 形式に 変換することができるようになりました。

    このオプションは、ツールを移植する目的で新しい形式に アクセスする方法として使用します。デバッガ情報を読み取る ソフトウェアを保持しない場合や、上記のどちらかの形式の デバッガ情報を必要とするツールを使用しない場合は、 このオプションを使用する必要はありません。

    -xdebugformat=stabs を指定すると、stabs の標準の形式を 使用してデバッグ情報を生成します。

    -xdebugformat=dwarf を指定すると、dwarf の標準の形式を 使用してデバッグ情報を生成します。

    -xdebugformat の指定を省略すると、-xdebugformat=stabs を 指定したと見なされます。このオプションを引数なしで指定することはできません。

    このオプションは、-g オプションを指定して記録する データの形式に影響を与えます。-g の指定を省略しても、 デバッグ情報の一部は記録され、その形式はこのオプションを使用して 制御することができます。したがって、-g が使用されて いない場合でも、-xdebugformat はデバッグ情報の形式に影響を与えます。

    dbx とパフォーマンスアナライザは stabs、dwarf の どちらの形式にも対応しているため、どちらのツールも このオプションの影響を受けません。

    このインタフェースは過渡的なものであるため、 マイナーリリースにおいても、リリースごとに、 互換性のない変更が加えられる可能性があります。

    また、今後、stabs、dwarf の個々のフィールドや値にも 変更が加えられる可能性があります。

-xdepend=[yes|no]
    (SPARC) ループを分析して繰り返し間のデータ依存関係を調べ、ループの再構成を 行います。

    ループを再構成するには、ループの交換、融合、スカラーの置き換え、 および不要な配列の代入の削除が必要になります。最適化レベルが -xO3 より低い場合は、 -xO3 に上げられ、警告が出力されます。

    -xdepend の指定を省略すると、デフォルトで -xdepend=no が設定され、ループのデータ依存関係の 分析が行われません。-xdepend を引数を付けずに指定すると、 -xdepend=yes が設定され、ループのデータ依存関係の分析が行われます。

    依存関係の分析は -xautopar または -xparallel にも含まれており、コンパイル時に実行されます。

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

-xdryrun
    このオプションは、-### と同義のマクロです。

-xe ソースファイルを対象として構文と意味の検査だけを行い、 オブジェクトファイルや実行可能ファイルを生成しません。

-xexplicitpar
    (SPARC) 指定されたループを並行化します。依存関係の分析、つまり 繰り返しの間のループおよびデータ依存関係の分析は、ユーザーの責任です。 ソフトウェアが指定されたループを並行化します。最適化レベルが -xO3 より低い場合は、 -xO3 まで上げられ、警告が出力されます。

    スレッド管理を独自に行う場合は、 -xexplicitpar は指定しないでください。

    このオプションを指定して作成したプログラムを 高速に実行するには、マルチプロセッサシステムが必要になります。 シングルプロセッサシステムで実行すると、生成されたバイナリファイルの 実行速度は遅くなります。

    並行化するループを識別し、そのループに依存関係がある場合、 不正な結果が得られ、多くの場合実行するたびに結果が異なり、 警告は出されません。縮約ループには、明示的な並行プラグマは 適用しないでください。 明示的な並行化が行われますが、ループの縮約については 行われず、結果が不正となることがあります。

    -xexplicitpar を使用して コンパイルとリンクを一度に実行する場合は、自動的に マイクロタスキング・ライブラリおよびスレッドに対して安全な C 実行時ライブラリ が含まれます。 -xexplicitpar を使用して、個別にコンパイルとリンクを行う場合は、リンク時にも cc -xexplicitpar を指定する必要があります。

    -xexplicitpar と -xopenmp を同時に出力しないでください。

-xF -xF オプションは、リンカーによる関数と変数の最適な再整理を可能にします。

    このオプションは、コンパイラに対して、関数またはデータ変数を 細分化された別々のセクションに配置することを指示します。リンカーは、 リンカーの -M オプションで指定されたマップファイル内の 命令を使用してセクションを再整理し、プログラムのパフォーマンスを 最適化することができます。通常、この最適化が効果的なのは、 ページフォルト時間がプログラム実行時間のかなりの割合を占める場合のみです。

    関数と変数を再整理し、パフォーマンスを最適化するには、 以下の作業を行う必要があります。

    1. -xF オプションを使用してコンパイルとリンクを行う。

    2. 『プログラムのパフォーマンス解析』の指示に従って関数の マップファイルを生成するか、『リンカーとライブラリ』の指示に従って データのマップファイルを生成する。

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

    4. プログラムを再実行し、アナライザを使用して パフォーマンスを分析し、パフォーマンスの向上を確認する。

    v には、以下の値のいずれかを指定できます。

    値   意味

    [no%]func
        関数を個々のセクションに細分化します[しません]。

    [no%]glbldata
        大域的なデータ (外部リンケージのある変数) を細分化します[しません]。

    %all
        関数と大域的なデータを細分化します。

    %none
        何も細分化しません。

    -xF の指定を省略すると、デフォルトで -xF=%none が指定されます。-xF を引数なしで 指定すると、デフォルトで -xF=%none,func が指定されます。

    関連項目:

    analyzer(1), debugger(1), ld(1)

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

    f には、 flags または readme、 のいずれかを指定します。

    -xhelp=flags はコンパイラオプションの要約を表示し、
    -xhelp=readme は README ファイルを表示します。 -xhwcprof=[enable|disable] (SPARC) -xhwcprof オプションを使用して、 コンパイラがハードウェアカウンタのプロファイルを サポートできるようにすることができます。

-xhwcprof=[enable|disable]
    (SPARC) -xhwcprof を有効にすると、コンパイラは、 ハードウェアカウンタデータの参照と、失敗したイベントおよびそれに 関連する命令とを、ツールが突き合わせる際に有用な情報を生成します。 シンボリック情報 (-g を指定して生成されます) と共に、 対応するデータ型と構造体のメンバーも明らかにすることができます。 この情報はパフォーマンス分析において役立てることができます。 コードのアドレス、ソース文、ルーチンに基づくプロファイルから 明らかにするのは簡単ではありません。

    -xhwcprof を使用して、指定した複数のオブジェクトファイルを コンパイルすることができますが、-xhwcprof が最も役立つのは、 アプリケーション中のすべてのオブジェクトファイルに対して 適用する場合です。この場合、アプリケーションのオブジェクトファイル内に 散在するすべてのメモリ参照とそれらの相関関係が明らかになります。

    コンパイルとリンクを別々のステップで行う場合、 リンク時にも -xhwcprof を使用します。 将来の -xhwcprof の拡張の際に、リンク時における使用が 義務づけられる可能性があります。

    -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

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

-xildoff
    インクリメンタルリンカーを無効にし、 ld を強制的に使用します。 このオプションは、 -g オプションを使用しない、 -G オプションを使用する、またはコマンド行に何らかのソースファイルがある、 という 3 つの条件のうち 1 つでも当てはまる場合に、デフォルトになります。 ild についての詳細は、『C ユーザーズガイド』を参照してください。

-xildon
    インクリメンタルリンカーを起動し、 ild をインクリメンタルモードで強制的に使用します。このオプションは、 -g オプションを使用する、 -G オプションを使用しない、コマンド行にソースファイル がないという 3 つの条件がすべて当てはまる場合に、デフォルトになります。 ild についての詳細は、『C ユーザーズガイド』を参照してください。

-xinline[=v[,v]...]

    v には [{%auto,func_name,no%func_name}] を指定します。

    -xinline は、リストに指定された関数だけをインライン化しようとします。リストは、関数名をコンマで区切ったものか、no%func_name 値をコンマで区切ったものか、値 %auto です。no%func_name を指定すると、コンパイラは指定された関数をインライン化しません。%auto を指定すると、コンパイラはソースファイルにあるすべての関数を自動的にインライン化しようとします。

    値のリストは、左から右へ累積されます。したがって -xinline=%auto,no%foo と指定すると、コンパイラは foo を除くすべての関数をインライン化しようとします。-xinline=%bar,%myfunc,no%bar と指定すると、コンパイラは myfunc のみをインライン化しようとします。

    最適化レベルを -xO4 以上に設定してコンパイルする場合、コンパイラは通常、ソースファイルに定義されている関数へのすべての参照をインライン化しようとします。-xinline オプションを指定することによって、コンパイラがインライン化する関数セットを制限することができます。-xinline= だけを指定して、関数名や auto を指定しないと、ソースファイルのどのルーチンもインライン化されません。%auto を指定せずに func_name と no%func_name のリストを指定すると、コンパイラはリストに指定された関数だけをインライン化しようとします。最適化レベルが -xO4 以上に設定され、-xinline オプションで、値のリストに %auto を指定すると、コンパイラは no%func_name により明示的に除外されていないすべての関数をインライン化しようとします。

    以下のいずれかの場合、関数はインライン化されません(警告は出力されません)。
    o 最適化のレベルが -xO3 より低いとき
    o ルーチンが見つからないとき
    o iropt によってルーチンのインライン化による効果または安全性が認められないとき
    o ルーチンのソースがコンパイル中のファイルにないとき (-xcrossfile 参照)

    コマンド行に複数の -xinline オプションを指定しても、これらのオプションは累積されません。コンパイラがインライン化を試みる関数は、コマンド行の最後の -xinline によって指定されます。

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

-xipo[=a]
    (SPARC) a は 0 か 1 のいずれかです。引数なしの -xipo は -xipo=1 と同じです。-xipo=0 はデフォルト設定で、-xipo を無効にします。

    コンパイラは、内部手続き解析パスを起動して、プログラム全体の最適化を実行します。-xcrossfile と異なり、-xipo はリンクステップ中のオブジェクトファイルすべての最適化を実行し、コンパイルコマンドのソースファイルだけに限定しません。

    -xipo=1 を指定すると、コンパイラはソースファイル全体のインライン化を行います。-xipo=2 を指定すると、コンパイラは手続き間の別名解析とメモリー割り当ておよび配置の最適化を行い、キャッシュのパフォーマンスを向上させます。

    解析と最適化は -xipo でコンパイルされるオブジェクトファイルに限定されています。ライブラリ上のオブジェクトファイルには拡張できません。 -xipo は複数フェーズで、別々のステップでコンパイルおよびリンクする場合は、 各ステップに -xipo を指定する必要があります。

    -xipo オプションは、ファイル間の最適化を実行するために必要な追加情報により、かなり大きなオブジェクトファイルを生成します。しかし、この追加情報は、最終的な実行可能バイナリファイルの一部にはなりません。実行プログラムのサイズの増加は、最適化がさらに実行されるためです。コンパイルステップで作成されるオブジェクトファイルは、その中でコンパイルされ、リンクステップで実行されるクロスファイルの最適化を許可する解析情報をさらに含んでいます。

    以下に、-xipo について考慮すべきいくつかの重要事項を記述します。

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

    o -xcrossfile と衝突します。同時に使用すると、コンパイルエラーが発生します。

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

    この例では、コンパイルとリンクは単一ステップで発生します。

    cc -xipo -xO4 -o prog part1.c part2.c part3.c

    この例では、コンパイルとリンクは別々のステップで発生します。

    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 のルーチンの間では行われません。 (最初のコンパイルで、未定義のシンボルが存在すると、警告が 出力される場合があります。しかし、内部手続き最適化は、コンパイル およびリンクステップであるので、実行されます。)

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

-xldscope={v}
    外部シンボルの定義のデフォルトのリンカーのスコープを変更します。 デフォルトを変更することによって、実装の隠蔽が向上し、 共有ライブラリがさらに高速かつ安全になる可能性があります。

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

    値   意味

    global
        大域的リンカースコープは、制限が最も少ないスコープです。 シンボルの参照はすべて、シンボルを定義する最初の動的モジュール内の 定義に結びつけられます。このリンカーのスコープが、外部シンボルの 現在のリンカーのスコープです。

    symbolic
        シンボリックリンカースコープを意味し、大域的リンカースコープよりも 制限されています。リンクされている動的モジュール内からの シンボルの参照はすべて、そのモジュール内で定義されているシンボルに 結びつけられます。このシンボルは、モジュールの外部では大域的に見えます。 このリンカースコープは、リンカーのオプション
         -Bsymbolic に相当します。

    hidden
        隠蔽リンカースコープは、シンボリックリンカースコープ、 大域的リンカースコープよりもさらに制限されています。 動的モジュール内の参照はすべて、そのモジュール内の定義に結びつけられます。 シンボルはモジュールの外部では見えません。

    -xldscope の指定を省略すると、-xldscope=global を 指定したと見なされます。-xldscope を引数を付けずに 指定することはできません。引数を付けずに -xldscope を指定すると、 コンパイラはエラーを出力します。コマンド行でこのオプションを複数 指定すると、一番右以外の指定は無効になります。

    クライアントからライブラリ内の関数をオーバーライドすることを許可しよう とする場合、ライブラリの構築中にその関数がインライン生成されないように する必要があります。 関数名を -xinline を付けて指定した場合、#pragma inline を 使用した場合、インライン化が自動的に発生する -xO4 以上でコンパイ ルを行なった場合、インライン指示子を使用した場合、クロスファイルの最適 化を使用する場合には、コンパイラは関数をインライン化します。

    たとえば、ライブラリ ABC にはデフォルトのアロケータ関数があり、 それをクライアントから使用でき、なおかつライブラリ内でも使用される る場合を想定します。

    void* ABC_allocator(size_t size) { return malloc(size); }

    ライブラリを -xO4 以上で構築すると、コンパイラは、 ライブラリコンポーネント内で発生する ABC_allocator の 呼び出しをインライン化します。ライブラリのクライアントが ABC_allocator をカスタマイズしたバージョンで置き換えようとした場合、 ABC_allocator を呼び出したライブラリコンポーネント内では 置き換えは行われません。したがって、最終的なプログラムには、 この関数の相異なるバージョンが含まれることになります。

    指示子 __hidden または __symbolic を使用して 宣言したライブラリ関数は、ライブラリの構築時にインライン 生成される可能性があります。このような関数がクライアントから オーバーライドされることは、サポートされていません。詳細については、 『C ユーザーズガイド』の第 2 章 「Sun の実装に固有のC コンパイラ情報」を参照してください。

    指示子 __global を使用して宣言したライブラリ関数は インラインとして宣言しはなりません。また、コンパイラの -xinline オプションを使用したインライン化も防ぐ必要があります。

    関連項目

    -xinline, -xO, -xcrossfile, ld(1).

-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

-xlibmieee
    例外的な場合に、数学ルーチンの戻り値を強制的に IEEE 754 形式にします。その場合、例外メッセージは出力されず、errno も設定されません。

-xlibmil
    数学ライブラリ用のインライン化テンプレートを取り込みます。 このオプションは、浮動小数点オプションとシステムのプラット フォームに適切なアセンブリ言語インラインテンプレートを選択します。 -xlibmil は、-xinline フラグの一部である関数の指定に 関係なく、関数をインライン化します。

-xlic_lib_=sunperf
    (SPARC) Sun が提供する Performance Library とリンクします。

-xlicinfo
    ライセンスシステムに関する情報を返します。

    このオプションではコンパイルは行われず、ライセンスも検査されません。

-xlinkopt[=level]
    (SPARC) コンパイラに対して、リンク時に再配置可能な オブジェクトファイルの最適化を行うよう指示します。

    ポストオプティマイザは、リンク時に、バイナリオブジェクトコードの 高度なパフォーマンス最適化を行います。level には、 実行する最適化のレベルとして、0、1、2 のいずれかを指定します。

    最適化のレベル

    0   ポストオプティマイザが無効になります (デフォルト値)。

    1   リンク時に、命令キャッシュカラーリング、分岐の最適化など、制御フロー分析に 基づく最適化を実行します。

    2   デッドコードの除去とアドレス計算の簡素化など、 より詳細なデータ制御分析に基づいて、リンク時の最適化を行います。

    level の値を指定せずに -xlinkopt を使用した場合、 -xlinkopt=1 を指定したと見なされます。

    こうした最適化はオブジェクトバイナリコードを分析して、 リンク時に実行されます。このオブジェクトファイルは 書き直されませんが、結果として出力される実行可能コードは、 元のオブジェクトコードとは異なる可能性があります。

    このオプションは、プロファイルフィードバックを使用して プログラム全体のコンパイルを行う際に使用するのが最も効果的です。

    コンパイルを複数の段階に分けて行う場合、コンパイル、 リンクの両段階で -xlinkopt を使用する必要があります。

    example% cc -c -xlinkopt a.c b.c
    example% cc -o myprog -xlinkopt=2 a.o b.o

    level の値は、コンパイラがリンクを行う際にだけ使用されることに注意して ください。上記の例では、オブジェクトバイナリは最適化レベル 1 を指定したとみ なされコンパイルされていますが、最適化のレベルとして 2 が使用されています。

    リンク時にポストオプティマイザをインクリメンタルリンカー ild と共に使用することはできません。 -xlinkopt は、デフォルトのリンカーを ld に設定します。 -xildon を使用してインクリメンタルリンカーを明示的に有効にし、 さらに -xlinkopt を指定すると、-xlinkopt が無効になります。

    -xlinkopt を使用してコンパイルを行う場合、 リンカーオプション -zcompreloc は使用しないでください。

    -xlinkopt がリンク時に効果を発揮できるようにするには、少なくともいく つかのコンパイルコマンドで -xlinkopt を使用しなければなりません。 オプティマイザは、-xlinkopt を指定せずにコンパイルしたオブジェクトバ イナリについても、限定的な最適化を行うことができます。

    -xlinkopt は、コンパイラのコマンド行で指定された静的なライブラリのコードを最適化します が、コマンド行で指定された共有 (動的な) ライブラリのコードはスキップし、最適 化しません。また、共有ライブラリを構築する場合 ( -G を使用してコンパイルする場合)、にも -xlinkopt を使用することができます。

    リンク時のポストオプティマイザは、実行時プロファイルのフィードバックと共に 使用すると最も効果的です。 プロファイルを行うことによって、コードの最も使用される部分と最も使用されない 部分を明らかにし、その結果に従ってオプティマイザを集中的に動作させることがで きます。これは、リンク時にコードの最適な配置を行うことによって命令キャッシュ のミスを低減できる大きなアプリケーションにおいてはとくに重要です。通常、この コンパイルは次のように行います。

    example% cc -o progt -xO5 -xprofile=collect:prog file.c
    example% progt
    example% cc -o prog -xO5 -xprofile=use:prog -xlinkopt file.c

    プロファイルのフィードバックの使用の詳細については、 -xprofile を参照してください。

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

-xloopinfo
    このオプションは、 -loopinfo と同義です。

-xloopinfo

    (SPARC) 並行化されているループと並行化されていないループを 表示します。このオプションは通常、-xautopar および -xexplicitpar オプションと共に使用します。Sun WorkShop には、 マルチプロセッサ C を使用する場合に必要なライセンスが含まれています。

-xM 指定された C プログラムに対してのみプリプロセッサを実行し、 Makefile 用の依存関係の生成と、結果の標準出力への送出を要求します (Makefile と依存関係の詳細については make(1) を参照して ください)。

-xM1
    -xM と同じ。ただし、-xM1 は、-Xs モードでは サポートされておらず、また、ヘッダーファイル /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 を使ってコンパイルすると、ヘッダーファイルの
    依存性は報告されません。
        example% cc -xM1 hello.c
          hello.o: hello.c

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

-xmaxopt[=v]
    このコマンドはプラグマ opt のレベルを、指定されたレベルに制限します。デフォルト値は -xmaxopt=off で、プラグマ opt は無視されます。引数なしで -xmaxopt を指定すると、 -xmaxopt=5 が使用されます。

-xmemalign=ab
    このコマンドは、想定する最大メモリー境界整列と、境界整列に失敗した データがアクセスされた際の動作を指定します。

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

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

    このように境界整列を判別できない状況では、 -xmemalign フラグを使用して、コンパイラが想定すべきデータの最大メモリー 境界整列を指定します。また、整列に失敗したメモリーアクセスが実行時に 発生した場合、従うべきエラー動作も指定できます。

    値

    次に、 a に指定できる値を示します。

        1   最大 1 バイトの境界整列を想定します。

        2   最大 2 バイトの境界整列を想定します。

        4   最大 4 バイトの境界整列を想定します。

        8   最大 8 バイトの境界整列を想定します。

        16  最大 16 バイトの境界整列を想定します。

    次に、 b に指定できる値を示します。

        i   アクセスを解釈して実行を続けます。

        s   シグナル SIGBUS を発生させます。

        f   境界整列が 4 バイト以下の場合に、シグナル SIGBUS を発生させます。 4 より大きい場合、アクセスを解釈して実行を続けます。

    デフォルト

    -xmemalign フラグを指定しない場合、デフォルトは次のようになります。

        -xarch が generic、v7、v8、v8a、v8plus、v8plusa の場合、 -xmemalign=4s

        -xarch が v9、v9a の場合、 -xmemalign=8s

    -xmemalign フラグだけを指定して値を指定しない場合、デフォルトは次のようになります。

        すべてのプラットフォームにおいて -xmemalign=1i

-xnativeconnect[=a[,a]...] ]
    インタフェース情報をオブジェクトファイルと後続の共用ライブラリ内に取り込んで、共用ライブラリを Java[tm] プログラミング言語で書かれたコード (Java コード) から使用できるようにするには、-xnativeconnect オプションを使用します。cc -G コマンドを使用して共用ライブラリを構築する場合も、-xnativeconnect を含める必要があります。

    -xnativeconnect を使用してコンパイルする場合、ネイティブコードインタフェースの外部に対する可視性が最大になります。Native Connector Tool（NCT) を使用すると、Java コードの自動生成と Java[tm] Native Interface (JNI) が使用可能になり、C 共用ライブラリを Java コードから呼び出せるようになります。NCT の使用方法の詳細については、『Forte Developer オンラインヘルプ』を参照してください。

    a には、次のいずれかの値を指定します。%all|%none|[no%]interfaces

    -xnativeconnect を指定しないと、コンパイラはこのオプションを -xnativeconnect=%none に設定します。-xnativeconnect だけを指定すると、コンパイラはこのオプションを -xnativeconnect=interfaces に設定します。

    -xnativeconnect=interfaces は、バイナリインタフェース記述子 (BIDS) を強制的に生成します。

-xnolib
    デフォルトのライブラリをリンクしません。 すなわち、 ld に -l オプションを渡しません。 通常、 cc ドライバは ld に -lc を渡します。

    -xnolib を使用した場合は、 -l オプションをすべて自分で渡す必要があります。たとえば、
        cc test.c -xnolib -Bstatic -lm -Bdynamic -lc
    とすると、 libm は静的にリンクされ、その他のライブラリは動的にリンクされます。

-xnolibmil
    数学ライブラリルーチンをインライン化しません。 このオプションは、 cc -fast -xnolibmil ... のように、 -fast オプションの後ろで指定してください。

-xOn
    最適化レベル (n) を指定します。 大文字のオー (O) の後に数字の 1 〜 5 を指定してください。

    一般的に、プログラムのコンパイル時の最適化レベルが高ければ高いほど、 実行時のパフォーマンスは向上します。しかし最適化レベルが高いと、 コンパイル時間が長くなり、実行可能ファイルのサイズが大きくなる 可能性が高まります。

    -xOn には、5 段階の最適化レベルを指定できます。 次の節では、SPARC プラットフォーム用および x86 プラットフォーム用の 各最適化レベルについて説明します。 各レベルで実施に行われる最適化の内容は、コンパイラのリリースによって 異なる可能性があります。

    オプティマイザは、メモリーが足りなくなると最適化レベルを 下げて現在の手順を再試行し、コマンド行オプションで指定された元の レベルでそれ以降の手続きを再開します。

    値:

    SPARC プラットフォームの場合:

    -xO1
        基本的な局所的最適化 (ピープホール) を行います。

    -xO2
        基本的な局所的および大域的な最適化を行います。 これには、帰納関数の除去、 局所的および大域的な共通部分式の除去、 算術の簡素化、コピーおよび定数の伝播、 可変ループ最適化、レジスタの割り当て、基本ブロックのマージ、 再帰的末尾の除去、無意味なデッドコードの除去、末尾呼び出しの除去、 素数式の展開が含まれています。

        このレベルでは、外部または間接の変数に対する参照または定義は 最適化しません。

        -O は -xO2 と同義です。

    -xO3
        -xO2 レベルで行われる最適化に加えて、外部変数に対する参照や定義を このレベルではポインタ代入の結果を追跡しません。 violate で適切に保護されていないデバイスドライバや、シグナルハンドラの内部から 外部変数を変更するプログラムをコンパイルするときは、 -xO2 を使用してください。

        一般に、 -xO3 および -xO4 のレベルでは、 -xspace を併用すると、結果のコードのサイズが大きくなります。

    -xO4
        -xO3 レベルで行われる最適化に加えて、同じファイルにある関数を 自動的にインライン化します。 この自動インライン化によって、ほとんどの場合に実行速度が向上しますが、 ごくまれに低下する場合もあります。一般的にこのレベルでは、-xspace と 併用しない限り、生成されるコードのサイズが大きくなります。

    -xO5
        最高レベルの最適化を行います。このレベルは、プログラムの中でも、その 実行にコンピュータ時間の大部分を要する、ごく少量のコードに対してのみ より長いコンパイル時間を要する最適化アルゴリズム、または実行時間が 確実に改善されるかが不明な最適化アルゴリズムを使用します。 このレベルでより確実にパフォーマンスを向上させるには、 プロファイルのフィードバックを使用してください。 詳細については -xprofile=collect|use の節を参照してください。

    x86 プラットフォームの場合:

    -xO1
        基本的な最適化を行います。これには、算術の簡素化、レジスタの割り当て、 基本ブロックのマージ、無意味なコードおよびストアの除去、および ピープホール最適化が含まれています。

    -xO2
        -x01 レベルで行う最適化のほかに、大域的な共通部分式の除去、 コピーおよび定数の伝播、再帰的な末尾の除去を行います。

        -O と -xO2 は同義です。

    -xO3
        -x02レベルで行う最適化のほかに、大域的な共通部分式の除去、 大域的なコピーと定数の伝播、ループ強度縮小、帰納変数の除去、 および可変ループ最適化を行います。

    -xO4
        -xO3 で行う最適化のほかに、同じファイルにある関数の自動インライン 化を行います。この自動インライン化は、ほとんどの場合に実行速度を向上させ ますが、逆に低下させることもあります。このレベルでは、フレーム ポインタレジスタ (ebp) を汎用的な目的に使用できるようになります。 一般にこの最適化レベルでは、コードサイズが大きくなります。

    -xO5
        最高レベルの最適化を行います。このレベルでは、コンパイル時間が長くなる 可能性があり、実行時間が確実に改善されるかどうか不明な最適化アルゴリズムを使用します。

    デフォルトでは最適化を行いません。ただし、 このデフォルトの設定は、最適化レベルを指定しない場合のみ 適用されます。最適化レベルを指定した場合には、 最適化を行わないようにすることはできません。

    最適化レベルの設定を行いたくない場合には、 最適化レベルを指定したと見なされる可能性のある オプションを指定しないようにしてください。 たとえば、-fast は、最適化レベルとして -xO5 を設定するマクロオプションです。 最適化レベルを指定したと見なされる可能性のある 他のすべてのオプションは、最適化レベルが設定された ことを示す警告メッセージを表示します。 最適化を行わずにコンパイルを行う唯一の方法は、 コマンド行からすべてのオプションを削除するか、 最適化レベルを指定する Make ファイルを削除することです。

    -g または -g0 を使用していて、最適化レベルが -xO3 以下の場合、コンパイラは、ほぼ完全な最適化によって 最大限のシンボル情報を提供します。末尾呼び出しの最適化と バックエンドのインライン化は無効です。

    -g または -g0 を使用していて、最適化レベルが -xO4 以上の場合、コンパイラは、完全な最適化によって 最大限のシンボル情報を提供します。

    -g オプション付きでデバッグしても -xOn に影響はありませんが、 -xOn によって、 -g オプションが制限を受けます。 たとえば、最適化オプションを使用すると dbx からの変数を表示できないといった、デバッグの機能の制限が 発生します。ただし、 where コマンドを使用してシンボルのトレースバックを 得ることはできます。詳細については 『 dbx コマンドによるデバッグ』 を参照してください。

    -xcrossfile オプションは、 -xO4 または -xO5 と一緒に使用した場合にのみ有効です。

    関連項目:

    -xldscope、 -fast、 -xprofile=p、 csh(1) マニュアルページ

    『プログラムのパフォーマンス解析』 では、最適化の各レベルがアナライザのデータに及ぼす影響に ついて説明しています。

-xopenmp[=i]
    (SPARC)

    -xopenmp オプションを指定して、 OpenMP 指令を使用して明示的な並列化を行うことができます。

    -xopenmp には以下の値を指定することができます。

    parallel
        OpenMP プラグマを認識できるようにします。 -xopenmp=parallel を指定した場合の最適化レベルは -x03 です。コンパイラは、必要に応じて最適化レベルを -x03 に変更し、警告を発生します。

    noopt
        OpenMP プラグマを認識できるようにします。 最適化レベルが -O3 よりも低い場合、 コンパイラは最適化レベルを上げません。 cc -O2 -xopenmp=noopt と指定し、 -O3 よりも低い最適化レベルを明示的に設定した場合、 コンパイラはエラーを発生させます。 -xopenmp=noopt を使用して最適化レベルを指定しない場合、 OpenMP プラグマは認識され、それに従ってプログラムの 並列化が行われますが、最適化は行われません。

    stubs
        OpenMP プラグマの認識を無効にし、スタブライブラリルーチンに リンクし、最適化レベルは変更しません。OpenMP の実行時 ライブラリルーチンを明示的に呼び出すアプリケーションをコンパイルし、 呼び出しを直列に実行したい場合に、このオプションを使用します。 -xopenmp=stubs コマンドは、_OPENMP プリプロセッサトークンも定義します。

    none
        OpenMP プラグマの認識を有効にせず、プログラムの最適化レベルを 変更せず、プリプロセッサトークンの事前定義を行いません。

    -xopenmp を値なしで指定すると、 -xopenmp=parallel を指定したと見なされます。 -xopenmp の指定を省略すると、-xopenmp=none を指定したと見なされます。

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

    -xopenmp を -xparallel または -xexplicitpar と共に指定しないようにしてください。

    将来のリリースでは、-xopenmp のデフォルトの 設定が変更される可能性があります。 適切な最適化レベルを指定することによって、 警告メッセージの表示を防止することができます。

    コンパイルとリンクを別々のステップで行う場合、 リンクのステップでも -xopenmp を指定する必要があります。 OpenMP 指令が含まれるライブラリをコンパイルする場合には 特に注意してください。

    OpenMP の C における実装に固有の情報については、 『C ユーザーズガイド』を参照してください。

    多重処理アプリケーションを構築するための OpenMP Fortran 95、C、C++ の API (Application Program Interface) の概要については、 『OpenMP API ユーザーズガイド』を参照してください。

-xP K&R C 関数定義のプロトタイプを出力します。

-xpagesize=n
    (SPARC) スタックとヒープの優先ページサイズを設定します。

    n には、以下のいずれかの値を指定します。
    8K、64K、512K、4M、32M、256M、2G、16G、default

    対象となるプラットフォーム上の Solaris オペレーティング環境で有効なページサ イズを指定する必要があります。 getpagesize(3C) を使用するとそのサイズがわかります。 有効なページサイズを指定しなかった場合、その要求は実行時に無視され、メッセー ジは出力されません。Solaris オペレーティング環境では、ページサイズ要求が優先 されることを保証してはいません。

    pmap(1) または meminfo(2) を使用して、対象となるプラットフォームのページサイズを確認することができます。

    -xpagesize オプションは、コンパイルおよびリンク時に使わないと効果はあ りません。

    この機能は Solaris 7 および Solaris 8 ソフトウェアでは利用できません。 このオプションを使ってコンパイルされたプログラムは、Solaris 7 および Solaris 8 ソフトウェア上でリンクできません。

    -xpagesize=default を指定すると、 オペレーティング環境によってページサイズが設定されます。 -xpagesize を引数を付けずに指定すると、 -xpagesize=default を指定したことになります。

    このオプションを指定してコンパイルを行うと、 同等のオプションを使用して環境変数 LD_PRELOAD を設定するか、 プログラムの実行前に Solaris 9 のコマンド ppgsz(1) を 同等のオプションを指定して実行するのと同じ効果が得られます。 詳細については、Solaris 9 のマニュアルページを参照してください。

    このオプションは、-xpagesize_heap と -xpagesize_stack と同義のマクロです。 この 2 つのオプションでは、-xpagesize と同じく、 8K、64K、512K、4M、32M、 256M、2G、16G、default という 引数を指定することができます。-xpagesize=n を使用して、 この 2 つのオプションに同じ値を設定することができます。 また、2 つのオプションを個別に指定し、異なる値を設定することもできます。

-xpagesize_heap=n
    (SPARC) メモリー内でヒープ用に使用するページサイズを設定します。 n には、8K、64K、512K、4M、 32M、256M、2G、16G、default のいずれかを指定することができます。 対象となるプラットフォームの Solaris オペレーティング環境で有効なページサイ ズを指定しなければなりません。この値は getpagesize(3C) で確認できます。有効なページサイズを指定しなかった場合、その要求は実行時に 無視され、メッセージは出力されません。

    pmap(1) または meminfo(2) を使用して、対象となるプラットフォームのページサイズを確認することができます。

    -xpagesize_heap=default を指定すると、 Solaris オペレーティング環境によってページサイズが設定されます。 -xpagesize_heap を引数を付けずに指定すると、 -xpagesize_heap=default を指定したことになります。

    このオプションを指定してコンパイルを行うと、 同等のオプションを使用して環境変数 LD_PRELOAD を 設定するか、プログラムの実行前に Solaris 9 のコマンド ppgsz(1) を同等のオプションを指定して実行するのと 同じ効果が得られます。詳細については、 Solaris 9 のマニュアルページを参照してください。

    この機能は、Solaris 7、Solaris 8 では使用できないことに 注意してください。このオプションを使用してコンパイルした プログラムは、Solaris 7、Solaris 8 ではリンクできません。

-xpagesize_stack=n
    (SPARC) メモリー内でスタック用に使用するページサイズを設定します。 n には、8K、64K、512K、 4M、32M、256M、2G、 16G、default のいずれかを指定することができます。 対象となるプラットフォームの Solaris オペレーティング環境で有効なページサイ ズを指定しなければなりません。この値は getpagesize(3C) で確認できます。有効なページサイズを指定しなかった場合、その要求は実行時に無 視され、メッセージは出力されません。

    pmap(1) または meminfo(2) を使用して、対象となるプラットフォームのページサイズを確認することができます。

    -xpagesize_stack=default を指定すると、 Solaris オペレーティング環境によってページサイズが設定されます。 -xpagesize_stack を引数を付けずに指定すると、 -xpagesize_stack=default を指定したことになります。

    このオプションを指定してコンパイルを行うと、 同等のオプションを使用して環境変数 LD_PRELOAD を設定するか、 プログラムの実行前に Solaris 9 のコマンド ppgsz(1) を 同等のオプションを指定して実行するのと同じ効果が得られます。 詳細については、Solaris 9 のマニュアルページを参照してください。

    この機能は、Solaris 7、Solaris 8 では使用できないことに 注意してください。このオプションを使用してコンパイルしたプログラムは、 Solaris 7、Solaris 8 ではリンクできません。

-xpch=v
    v には、collect:pch_filename1 または use:pch_filename を指定することができます。

    -xpch オプションを使用してプリコンパイル済み ヘッダーファイルを作成し、コンパイル時間を短縮することができます。 プリコンパイル済みヘッダーファイルは、ソースファイルが 大量のソースコードが含まれている複数のインクルードファイルを 共有するアプリケーションのコンパイル時間を短縮する目的で 設計されています。プリコンパイル済みヘッダーファイルを 作成することによって、1 つのソースファイルからヘッダーファイルに 関する情報を収集し、そのソースファイルを再コンパイルする場合 や同じヘッダーが記述されている他のソースファイルをコンパイルする 場合にその情報を使用することができます。 この機能は、-xpch、-xpchstop オプションを #pragma hdrstop 指令と組み合わせ、 使用することができます (-xhelp=readme を参照)。

    プリコンパイル済みヘッダーファイルの作成
    -xph を初めて使用する際に、収集モードを指定する必要があります。 -xpch=collect を指定するコンパイルコマンドでは、 ソースファイルを 1 つだけ指定する必要があります。 次の例では、-xpch オプションによって、 ソースファイル a.c に基づいて header.cpch という プリコンパイル済みヘッダーファイルが作成されます。
    cc -xpch=collect:myheader a.c

    有効なプリコンパイル済みヘッダーファイルのファイル名には、 接尾辞を自分で付けることができます。省略すると、 コンパイラによって自動的に付けられます。 たとえば、cc -xpch=collect:foo a.c と指定すると、 プリコンパイル済みヘッダーファイルの名前は foo.cpch になります。

    プリコンパイル済みヘッダーファイルの使用
    プリコンパイル済みヘッダーファイルを使用するには、 -xpch=use:pch_filename を指定します。 プリコンパイル済みヘッダーファイルの作成に使用した ソースファイルと同じインクルードファイルを使用する ソースファイルをいくつでも指定できます。 たとえば、プリコンパイル済みヘッダーファイルを使用するコマンドは 次のようになります。
    cc -xpch=use:foo.cpch foo.c bar.c foobar.c

    以下の項目がすべて当てはまる場合には、 既存のプリコンパイル済みヘッダーファイルのみを使用します。 1 つでも当てはまらない項目がある場合には、 プリコンパイル済みヘッダーファイルを再度作成します。

    o プリコンパイル済みヘッダーファイルの作成に 使用したコンパイラを使用して、プリコンパイル済み ヘッダーファイルにアクセスする。プリコンパイル済み ヘッダーファイルは、その作成に使用したコンパイラと バージョンが異なるコンパイラからはアクセスできない場合が あります。

    o -xpch オプションを除いて、-xpch=use を 使用して指定するコンパイラオプションは、プリコンパイル済み ヘッダーファイルの作成時に指定したオプションと同じでなければならない。

    o -xpch=use を使用して指定するインクルード済み ヘッダーは、プリコンパイル済みヘッダーの作成時に指定したヘッダーと 同じでなければならない。

    o -xpch=use を使用して指定するインクルード済みヘッダーの 内容は、プリコンパイル済みヘッダーの作成時に指定したインクルード済み ヘッダーの内容と同じでなければならない。

    o カレントディレクトリ (コンパイルを行い、指定した プリコンパイル済みヘッダーファイルを使用するディレクトリ) が、 プリコンパイル済みヘッダーファイルを作成したディレクトリと同じである。

    o -xpch=collect を使用して指定したファイル内の 事前処理指令 (#include 指令を含む) の順序が、 -xpch=use を使用して指定したファイル内の 事前処理指令の順序と同じである。

    活性文字列 (Viable Prefix)
    1 つのプリコンパイル済みヘッダーファイルを複数の ソースファイルで共有するには、ソールファイル間で インクルードファイルをトークンの初期シーケンスとして 共有する必要があります。このトークンの初期シーケンスは、 活性文字列と呼ばれます。活性文字列は、 同じプリコンパイル済みヘッダーファイルを使用するすべての ソースファイルで矛盾なく解釈される必要があります。 活性文字列は、各ソースファイルの最初のトークンで始まり、 #pragma hdrstop、または -xpchstop オプションで指定される ヘッダーファイルの #include 指令の最後のトークンで終わります。

    ソースファイルの活性文字列は、コメントと以下の プリプロセッサ指令のみで構成することができます。

    #include #if/ifdef/ifndef/else/elif/endif
    #define/undef
    #ident (同じであれば、そのまま通過)
    #pragma (同じであれば)

    これらの指令は、マクロを参照することができます。 #else、#elif、#endif は、 活性文字列内で適切に組み合わせて使用する必要があります。

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

    プリコンパイル済みヘッダーファイルに組み込まれるヘッダーファイルは、 以下の条件を満たす必要があります。条件を満たさないプログラムの コンパイル結果は不定です。

    o ヘッダーファイルに関数定義が含まれていてはならない。

    o ヘッダーファイルでは、__DATE__ と __TIME__ を 使用してはならない。これらのプリプロセッサマクロを使用すると、 予測できない結果が生じる場合があります。

    o ヘッダーファイルには、#pragma hdrstop を含めてはならない。

    o 実行可能な接頭辞内で __LINE__、__FILE__ を 使用してはならない。インクルードされたヘッダーでは、 __LINE__、__FILE__ を使用できます。

    関連項目: -xpchstop, -xhelp=readme

-xpchstop=file
    file には、プリコンパイル済みヘッダーファイルの作成時に最後に使用されるインクルードファイルを指定します。コマンド行で -xpchstop を使用すると、cc コマンドを使用して指定したソースファイルでファイルを参照する最初のインクルード指令の後ろに hdrstop プラグマ (-xhelp=readme を参照) を配置するのと同じ結果になります。

    関連項目: -xpch, -xhelp=readme

-xparallel
    (SPARC) ループを自動的に(コンパイラによって)、かつ明示的に(プログラマの指定によって) 並列化します。このオプションは、 -xautopar、 -xdepend、 および
    -xexplicitpar をすべて指定したマクロと同義になります。 明示的な並列化を使用すると、不正確な結果が生成される可能性があります。

    最適化レベルが -xO3 より低い場合は、 に上げられ、警告が出力されます。

    スレッド管理を独自に行う場合は、 -xparallel を使用しないでください。 同様に、-xopenmp を指定している場合は、-xparallel を使用しないでください。-xparallel は、-xexplicitpar を設定します。これは、-xopenmp を指定した場合に指定してはいけません。

    プログラムを高速に実行するには、SPARC のマルチプロセッサシステムでこのオプションを使用する必要があります。 シングルプロセッサシステムで実行すると、生成されたバイナリファイルの 実行速度は遅くなります。

    一度にコンパイルとリンクを行う場合、 -xparallel はマイクロタスキングライブラリとスレッドに対して安全な C 実行時ライブラリとリンクします。コンパイルとリンクを 別々に行う場合、コンパイルを -xparallel で行なった場合は、リンクも -xparallel で行なってください。

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

-xpg
    gprof(1) を使ってプロファイリングするためのデータを収集するオブジェクトコードを 作成します。正常終了時にファイル gmon.out を生成する実行時記録メカニズムを呼び出します。

-xprefetch[=val[,val]]
    (SPARC) 先読みをサポートしている UltraSPARC II などのアーキテクチャ (-xarch=v8plus、 v9plusa、 v9、 v9a のいずれか) において、先読み命令を有効にします。

    明示的な先読みは、パフォーマンスが実際に向上する特別な環境だけで使用してください。

    val には次のうちの 1 つを指定します。

    auto
        先読み命令の自動生成を有効にします。

    no%auto
        先読み命令の自動生成を無効にします。

    explicit
        明示的な先読みマクロを有効にします。

    no%explicit
        明示的な先読みマクロを無効にします。

    latx:factor
        コンパイラによるロード命令とストア命令に対する先読み命令の、 「潜在期間」の仮定値を、指定された係数 (factor) で調整します。factor は、 n.n という形式の整数でなければなりません。

        先読み命令の「潜在期間」とは、先読み命令が実行された時点から、 先読み命令の対象であるデータが実際にキャッシュに入れられる時点までの、 ハードウェアに起因する時間のずれを指します。 コンパイラは、先読み命令の挿入位置と、先読みされたデータを 使用するロードまたはストアの命令文の位置がどれだけ離れているかを 確認して、先読みの潜在期間を仮定します。 注意 — 仮定される先読みの潜在期間は、ロード命令とストア命令では 異なる場合があります。

        コンパイラは、広範囲に渡るマシンおよびアプリケーションに対して適切に なるように、先読みのメカニズムを調整しています。このため現在の機能が、 すべてのマシンまたはアプリケーションで最良であるとは限りません。 メモリーを大量に消費するアプリケーション、特に大規模な複数のプロセッサで 実行するアプリケーションの場合は、先読みの潜在期間を示す値を増加させた方が、 パフォーマンスが向上する可能性があります。 先読みの潜在期間を増加させるには、 factor の値を 1 より大きい値にします。 .5 から 2.0 の間の値にすると、ほぼ確実に最高のパフォーマンスが得られます。

        完全に外部のキャッシュに存在するデータベースを扱う アプリケーションの場合は、先読みの潜在期間を減少させた方が、 パフォーマンスが向上する可能性があります。 先読みの潜在期間を減少させるには、 factor の値を 1 より小さい値にします。

        latx:factor サブオプションを使用する場合は、まず factor の値を 1.0 に近い値に設定して、 対象のアプリケーションに対するパフォーマンスを調べます。 そして徐々にその値を変化させていき、パフォーマンスの変化を確認します。 最良のパフォーマンスが得られるまでテストを繰り返し、適切な factor の値を特定します。 factor の値を細かく変更した場合は、しばらくの間パフォーマンスの変化は まったく見られませんが、ある値で突然高くなります。続けて値を増加または減少 させていくと、パフォーマンスは再び下がります。

    yes -xprefetch=auto,explicit と同じです。

    no  -xprefetch=no%auto,no%explicit と同じです。

    -xprefetch を指定しない場合、デフォルトは -xprefetch=no%auto,explicit です。-xprefetch だけを指定 して値を指定しない場合、-xprefetch=auto,explicit と同じです。

    sun_prefetch.h ヘッダーファイルには、明示的な先読み命令を指定するために使用できる マクロが含まれています。先読み命令は実行コードにおいて、マクロの 位置に対応する場所の付近に挿入されます。

-xprefetch_level=l
    -xprefetch=auto によって決定された prefetch 文の自動挿入の程度を制御するには、このオプションを使用します。

    l は 1、2、3 のいずれかです。

    最適化レベル 3 以上でコンパイルするか、prefetch をサポートするプラットフォーム (v8plus、v8plusa、v9、v9a、v9b、generic64、native64) のコードを生成する必要があります。

    -xprefetch_level=1 を指定すると、prefetch の自動生成が可能になります。-xprefetch_level=2 を指定すると、レベル 1 を超える追加生成が可能になり、-xprefetch=3 を指定すると、レベル 2 を超える追加生成が可能になります。

    -xprefetch=auto を指定する場合、デフォルトは -xprefetch_level=1 です。

-xprofile=p
    (SPARC) プロファイル用のデータを収集する、 または最適化を行うためにプロファイルを使用します。

    p には、 collect[:<名前>] 、 use[:<名前>] または tcov を指定します。

    このオプションを使用すると、実行時に実行頻度のデータが収集されて保存されます。このデータは以降の実行パフォーマンスを向上させるために使用することができます。プロファイルの収集は、マルチスレッドアプリケーションを使用した場合であっても安全 です。マルチタスク (-mt) を実行する プログラムを使用した場合、正確な結果が得られます。 このオプションは、-xO2 以上のレベルの最適化を指定する場合にのみ有効です。

    コンパイルとリンクを別の段階で行う場合、コンパイル時には、 リンクの段階で使用したものと同じ -xprofile オプションを 使用しなければなりません。

    collect[:<名前>]
        -xprofile=use で使用できるように、実行頻度の情報を収集および保存します。 コンパイラは、文の実行頻度を測定するためのコードを生成します。

        <名前> には、実行頻度のフィードバックデータを格納する .profile ディレクトリの名前を指定します。この名前の指定は省略可能です。 <名前> の指定を省略すると、実行可能ファイルの名前 (-o オプションで指定した名前、または -o オプション省略時は a.out) に接尾辞 .profile を付けた名前のサブディレクトリが、 プログラムを実行したディレクトリに作成されます。

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

        この環境変数は、 tcov により記述されたプロファイルデータファイルのパスと名前を、tcov(1) のマニュアルページに記述されているのと同様に制御します。

        この環境変数が設定されていない場合、プロファイルデータはカレントディレクトリの name.profile/feedback に書き込まれます。ここで、name は実行可能ファイル、または -xprofile=collect:name フラグに指定された名前です。 -xprofile は name がすでに .profile で終了している場合に、name に .profile を付加しません。 プログラムを複数回実行した場合、実行頻度のフィードバックデータは フィードバックファイルに蓄積されるので、 前回のデータは失われません。

        コンパイルとリンクを別々のステップで行う場合には、 -xprofile=collect を使用してコンパイルした オブジェクトファイルも -xprofile=collect を使用して リンクする必要があります。

    use[:<名前>]
        実行頻度データを利用して、有効に最適化を行います。
        <名前> には、フィードバックデータが格納されている .profile ディレクトリの名前を指定してください。この名前は省略可能です。 <名前> の指定を省略すると、a.out.profile が フィードバックデータのあるディレクトリとみなされます。

        -xprofile=collect でコンパイルしたプログラムを前回実行した結果として feedback ファイルに生成および保存された実行頻度データをもとにして、 プログラムが最適化されます。

        -xprofile オプションを除いて、ソースファイルおよびその他のコンパイラオプションは、feedback ファイルを生成したコンパイル済みプログラムを生成したコンパイル時に使用されたオプションと同じものを指定する必要があります。collect ビルドと use ビルドには同じコンパイラバージョンを使用しなければなりません。-xprofile=collect:<名前> でコンパイルした場合、最適化コンパイルでは同じ <名前>、すなわち -xprofile=use:<名前> を指定する必要があります。

        collect 段階と use 段階の間のコンパイルの 高速化については、-xprofile_ircache も参照してください。

    tcov
        新しい形式の tcov を使用した基本的なブロックカバレージ分析を行います。

        -xprofile=tcov オプションは、tcov のプロファイルの作成に 使用する新しい形式の基本ブロックです。 -xa オプションと同じ機能がありますが、ヘッダーファイルに ソースコードが含まれているプログラムのデータを正確に収集します。 旧形式のプロファイルについての詳細は、 tcov(1) のマニュアルページ、および『プログラムのパフォーマンス解析』を 参照してください。

        コード生成は -xa オプションと同じように実行されますが、.d ファイルは生成されません。代わりに単一のファイルが生成されます。 ファイル名は、対応する実行可能形式のファイルの名前にもとづいて付けられます。 たとえば、プログラムが /foo/bar/myprog.profile から実行されている場合、データファイルは /foo/bar/myprog.profile/myprog.tcovd に格納されます。

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

        tcov を実行する時には、新しい形式のデータが使用されるように -x オプションを指定してください。指定しない場合、 tcov は旧式の .d ファイル(存在する場合)を使用します。 この場合は、予想外の結果が生じることがあります。

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

        注: -xO4 以上の最適化または -xinline を使用したために 関数のインライン化が存在する場合、tcov のコードカバレージ 解析のデータは不正確になる可能性があります。

    -xprofile=collect を使用してプロファイル収集用プログラムをコンパイルし、-xprofile=use を使用してプロファイルフィードバック用プログラムをコンパイルする場合、ソースファイルと、-xprofile=collect および -xprofile=use 以外のコンパイラオプションは、どちらのコンパイルでも同じでなければなりません。

    -xprofile=use:<名前> オプションにより指定されるプロファイルフィードバックディレクトリ名は、コンパイラの 1 回の起動におけるすべてのオプションのインスタンスから累積されます。たとえば、プロファイルディレクトリ a.profile、b.profile、および c.profile が、プロファイルされたバイナリ名 a、b、c の実行結果として作成されたとします。

       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 オプションにより指定されるすべてのプロファイルフィードバックディレクトリ名が無視され、プロファイル生成の計測が有効になります。

-xprofile_ircache[=path]
    (SPARC) -xprofile_ircache[=path] と -xprofile=collect|use を使用して、 収集段階に保存したコンパイルデータを再利用し、 使用段階においてコンパイル時間を短縮することができます。

    大きなプログラムでは、中間データが保存されるため、 使用段階におけるコンパイル時間が大幅に短縮されます。 データを保存するので、必要なディスク空間が大幅に増加する可能性が あることに注意してください。

    -xprofile_ircache[=path] を指定すると、 キャッシュファイルの保存場所ではなく path が使用されます。 デフォルトでは、キャッシュファイルはオブジェクトファイルと同じ場所に 保存されます。収集段階と使用段階で使用するディレクトリが異なる場合、 パスを指定すると便利です。

    典型的なコマンドの流れを以下に示します。

    example% cc -xO5 -xprofile=collect -xprofile_ircache t1.c t2.c
    example% a.out    // フィードバックデータの収集を実行
    example% cc -xO5 -xprofile=use -xprofile_ircache t1.c t2.c

-xprofile_pathmap=collect_prefix:use_prefix
    -xprofile_pathmap オプションは、-xprofile=use コマンドの指定時に使用します。以下の 2 つの条件が当てはまり、 -xprofile=use を指定してコンパイルしたオブジェクトファイルの プロファイルデータをコンパイラが検出できない場合、 -xprofile_pathmap を使用します。

    o  以前に -xprofile=collect を使用してオブジェクトファ
        イルをコンパイルしたディレクトリとは異なるディレクトリで -xprofile=use を使用してオブジェクトファイルをコンパイ ルする。

    o  プロファイル内で、オブジェクトファイルは共通のベース
        名を持つが、保存されているディレクトリによって区別される。

    collect-prefix には、-xprofile=collect を使用して オブジェクトファイルのコンパイルを行なったディレクトリの UNIX パス名の接頭辞を指定します。

    use-prefix には、-xprofile=use を使用してオブジェクトファイルのコンパイルを行うディレクトリの
     UNIX パス名の接頭辞を指定します。

    -xprofile_pathmap を複数指定すると、 指定した順番に処理が行われます。-xprofile_pathmap に 指定された use-prefix は、オブジェクトファイルの パス名と比較されます。比較は、オブジェクトファイルのパス名と 一致する use-prefix が見つかるまで、または、 最後に指定された use-prefix に達し、一致がなくなるまで行われます。

-xreduction
    (SPARC) 自動並列化の縮約のループを分析します。 このオプションは、 -xautopar または -xparallel が同時に指定されている場合に限り有効になります。 これ以外の場合、コンパイラは警告を出します。

    縮約の認識が有効になっている場合、コンパイラは ドット積、最大値と最小値の検出などの縮約を並列化します。 これらの縮約の結果は、 並列化していないコードで得られる値を四捨五入した結果とは異なります。

-xregs=r[,r...]
    生成されたコードでのレジスタの使用方法を指定します (SPARC のみ)。

    r には [no%]appl と [no%]float の 1 つまたは両方をコンマで区切って指定します。

    例: -xregs=appl,no%float

    -xarch の各値に対する -xregs の意味は次のとおりです。

    [no%]appl
        アプリケーションレジスタをスクラッチレジスタとして使用する コードをコンパイラが生成することを許可します[しません]。 アプリケーションレジスタは以下のとおりです。

        g2, g3, g4 (v8a, v8, v8plus, v8plusa, v8plusb)
        g2, g3 (v9, v9a, v9b)

        すべてのシステムソフトウェアとライブラリは必ず -xreg=no%appl を使用してコンパイルしてください。システムソフトウェア (共用ライブラリを含む) は、アプリケーションに対してこれらのレジスタ値を保持する必要があります。これらの値の使用はコンパイルシステムにより制御され、アプリケーション全体で一貫していなければなりません。

        SPARC ABI では、これらのレジスタはアプリケーションレジスタと 表現されます。これらのレジスタを使用すると、必要なロード、 ストア命令の数が減るので、パフォーマンスが向上します。 ただし、このような使用は、アセンブリコードで記述された 古いライブラリプログラムの一部と衝突する場合があります。

        SPARC の命令セットの詳細については、 -xarch の節を参照してください。

    [no%]float
        コンパイラが浮動小数点レジスタを整数値のスクラッチレジスタとして 使用してコードを生成することを許可します[しません]。 このオプションの指定の有無にかかわらず、浮動小数点値を使用すると これらのレジスタが使用される可能性があります。-xregs=no%float を指定した場合、ソースプログラムに浮動小数点コードを含めることはできません。

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

    アプリケーションとリンクする共用ライブラリ用のコードは、必ず -xregs=no%appl,float を使用してコンパイルしてください。ライブラリとリンクするアプリケーションが問題の対処方法を理解できるように、少なくとも共用ライブラリにはアプリケーションレジスタの使用法を明示的に文書化してください。

    たとえば、レジスタを広域的に使用する (たとえばレジスタを使って重要なデータ構造をポイントする) アプリケーションは、-xregs=no%appl を使用しないでコンパイルされたコードを持つライブラリに安全にリンクするために、そのライブラリがアプリケーションレジスタをどのように使用するかを正確に知る必要があります。

-xrestrict[=f]
    (SPARC) ポインタ値の関数引数を制限付き (restricted) ポインタとして 扱います。f には、%all、%none または、 1 つまたは複数の関数名をコンマで区切ったリストを指定します。 このコマンド行オプションは、単独でも使用できますが、 -xO3 以上の最適化レベルと共に使用するのが最適です。

    このオプションに関数リストが指定されると、指定された関数内のポインタパラメータは制限付きとして扱われます。-xrestrict=%all が指定されると、C ファイル全体のすべてのポインタパラメータが制限付きとして扱われます。

    デフォルト値は %none です。 -xrestrict を指定するのは、 -xrestrict=%all を指定することと同等です。

-xs dbx がオブジェクトファイルなしでデバッグを行うことを許可します。

    このオプションを指定すると、すべてのデバッグ情報が 実行可能ファイルにコピーされます。dbx のパフォーマンスや プログラムの実行時パフォーマンスへの影響はほとんどありませんが、 ディスクの使用量が増加します。

-xsafe=mem
    (SPARC プラットフォーム) メモリー保護違反が発生しないことを前提として、コンパイラを動作させます。

    このオプションは、コンパイラが、SPARC V9 アーキテクチャで 障害発生を想定しないロード命令を使用することを許可します。

    障害発生を想定しないロード命令は、アドレス割り当ての失敗やセグメント違反 のような障害が発生した場合でも、トラップを発生させません。 そのためこのオプションは、そのような障害が起こり得ないプログラムで のみ使用してください。メモリーに基づいたトラップを発生させるプログラムは ごく少数なので、このオプションはほとんどのプログラムで安全に使用できます。 しかし、例外的な状態を処理するために、メモリーに基づいたトラップを明示的に使用している プログラムでは、このオプションは使用しないでください。

    このオプションは、 -xO5 の最適化レベルで、かつ、 次のいずれかの値をとる -xarch オプションと一緒に使用された場合にのみ有効です。
    v8plus、 v8plusa、 v8plusb、 v9、 v9a、 v9b

-xsb
    このオプションを使用して、ソースブラウザのシンボルテーブルの 追加情報を生成することができます。このオプションは、 -Xs モードとの互換性はありません。

    コンパイルとリンクを別々のステップで行う場合、 コンパイルステップとリンクステップの両方で -xsb を指定しないと、リンカーがエラーメッセージを表示します。

    -xsb を指定して、-xsb を使用してコンパイルした オブジェクトへのリンクを行わない場合、 ソースブラウザのデータの参照はリンクステップで作成した 実行可能ファイルからしか行えません。また、コンパイルステップと リンクステップの両方で -xsb を指定しないと、 ソースブラウザデータベース中のシンボル参照の一部が失われる可能性があります。

    コンパイルステップとリンクステップの両方で -xsb を使用する場合には次の点に留意してください。オブジェクトが同じ ディレクトリ内で異なる方法でコンパイルされ、異なる実行可能ファイルにリンクさ れる場合には、ソースブラウザで両方のオブジェクト内のすべてのシンボル参照が 見えるようにする必要があります。

-xsbfast
    ソースブラウザ用データベースを作成しますが、実際にはコンパイルしません。このオプションは、コンパイラの -Xs モードが指定されていると、無効になります。

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

-xspace
    コードサイズを拡大するような最適化や並列化を行いません。 たとえば、ループの展開は行いません。

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

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

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

    -xtarget オプションを使用すると、実際のシステムで発生する -xarch、 -xchip、 および -xcache の組み合わせを容易に指定することができます。 -xtarget の意味は、 = の後に指定した値を展開したものにあります。

    -xtarget=native と指定するのは、-xarch=native, -xchip=native, -xcache=native と指定することと同じです。

    -xtarget=generic と指定するのは、-xarch=generic, -xchip=generic, -xcache=generic と指定することと同じです。

    -fast マクロオプションには、 -xtarget=native が含まれています。

    -xtarget コマンド自体は、コマンド行において -xarch、-xchip、 および -xcache オプションをマクロ展開します。したがって、 -xtarget の後に必要なオプションを指定すれば、マクロに含まれるオプションの 設定を変更できます。fpversion(1) コマンドを使用して、 動作中のシステムにおける -xtarget=native の展開を 確認することができます。 注: ホストプラットフォームによっては、コンパイルの際に -xtarget=native を指定しても、-xarch、-xchip、 または-xcache が同じ設定にならない場合があります。

    -xtarget では以下の値を指定することができます。

    native
        現在のホスト環境 (32 ビット環境と仮定する) で良好なパフォーマンスを得られるようにパラメータを 設定します。

    generic
        ほとんどの 32 ビットプラットフォームアーキテクチャで良好なパフォーマンスを得られるようにパラメータ を設定します。これがデフォルトです。

    <システム名>
        指定されたシステムについて最高のパフォーマンスを得ます。
        SPARC で使用できるシステム名は次のとおりです。
        sun4/15、sun4/20、sun4/25、sun4/30、sun4/40、sun4/50、sun4/60、sun4/65、 sun4/75、sun4/110、sun4/150、sun4/260、sun4/280、sun4/330、sun4/370、 sun4/390、sun4/470、sun4/490、sun4/630、sun4/670、sun4/690、sselc、 ssipc、ssipx、sslc、sslt、sslx、sslx2、ssslc、ss1、ss1plus、ss2、 ss2p、ss4、ss4/85、ss4/110、 ss5、ss5/85、ss5/110、 ssvyger、ss10、ss10/hs11、ss10/hs12、ss10/hs14、 ss10/20、ss10/hs21、ss10/hs22、ss10/30、ss10/40、ss10/41、ss10/50、ss10/51、 ss10/61、ss10/71、ss10/402、ss10/412、ss10/512、ss10/514、ss10/612、 ss10/712、ss20、 ss20/hs11、ss20/hs12、ss20/hs14、ss20/hs21、ss20/hs22、ss20/50、 ss20/51、ss20/61、ss20/71、ss20/151、ss20/152、 ss20/502、ss20/512、ss20/514、 ss20/612、ss20/712、ss600/41、ss600/51、ss600/61、ss600/120、 ss600/140、ss600/412、ss600/512、ss600/514、ss600/612、ss1000、 sc2000、cs6400、solb5、solb6、ultra、ultra2、ultra2i、ultra1/140、ultra1/170、ultra1/200、 ultra2/1170、ultra2/1200、ultra2/1300、ultra2/2170、ultra2/2200、 ultra2/2300、ultra2i、ultra3、ultra3cu、entr2、entr2/1170、entr2/2170、entr2/1200、entr2/2200、 entr150、entr3000、entr4000、entr5000、entr6000

    SPARC V9 または UltraSPARC V9 上の 64 ビット Solaris 7 用にコンパイルするには、 -xarch=v9 または -xarch=v9a フラグを指定します。 -xtarget=ultra または ultra2 という設定は必要ないか (必要な場合には) 不十分です。

    (Intel)
        -xtarget= には次のいずれかを指定できます。

    o generic または native

    o 386 (-386 オプションと同等) または
        486 (-486 オプションと同等)

    o pentium

    o pentium_pro

    実際のシステム名と番号のニーモニックコードを示す
        -xtarget を展開した内容ついては、『C ユーザーズガイド』の -xtarget=t の項を参照してください。

-xtemp=<ディレクトリ>
    cc が使用する一時ファイルのディレクトリを<ディレクトリ>に 設定します。 このオプション中に空白文字を入れることはできません。 このオプションを指定しない場合は、一時ファイルは tmp に置かれます。 このオプションによる指定内容は、TMPDIR 環境変数よりも優先されます。

-xthreadvar[=of1]
    (SPARC) 宣言指定子 __thread と組み合わせて使用し、 コンパイラのスレッドローカルな記憶装置を利用することができます。 __thread を使用してスレッド変数を宣言した後に、 -xthreadvar を使用して、動的 (共有) ライブラリ内の位置依存コード (非 PIC コード) を使用してスレッドローカルな記憶装置を 使用可能にすることができます。__thread の使用法の詳細については、 『C ユーザーズガイド』を参照してください。

    o には以下の値を指定できます。

    値   意味

    [no%]dynamic
        動的読み込み用の変数をコンパイルします[しません]。 -xthreadvar=no%dynamic を指定すると、 スレッド変数へのアクセス速度が大幅に高速化されますが、 動的ライブラリ内のオブジェクトファイルを使用できません。 つまり、実行可能ファイル内のオブジェクトファイルを使用できません。

    -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

-xtime
    コンパイルごとに、消費する時間とリソースを報告します。

-xtransition
    K&R C と ISO C 間の相違について、警告を出します。 -xtransition オプションは、 -Xa と -Xt オプションと共にメッセージを発行します。 動作の相違についてのすべての警告メッセージは、 適切なコーディングで解除できます。

-xtrigraphs[=[yes|no]]
    コンパイラが ISO C 標準規格で定義されているように 3 文字表記 シーケンスを認識するかどうかを指定します。

    -xtrigraphs=yes と指定すると、コンパイラはソースコード中の 3 文字表記シーケンスを認識 します。 -xtrigraphs=no と指定すると、コンパイラはソースコード中の 3 文字表記シーケンスを 認識しません。

    デフォルト:

    -xtrigraphs が指定されていない場合は、 -xtrigraphs=no であると仮定されます。

    -xtrigraphs とだけ指定された場合は、 -xtrigraphs=yes であると仮定されます。

-xunroll=n
    コンパイラがループを最適化する (展開する) かどうかを指定します。 n は正の整数です。 n が 1 の場合はコマンドとなり、コンパイラはループを展開しません。 n が 1 より大きい場合は、 ループを n 回展開するようにコンパイラに知らせます。

-xustr={ascii_utf16_ushort|no}
    ISO10646 UTF-16 文字列リテラルを使用する多言語対応アプリケーションを サポートする必要がある場合には、-xustr=ascii_utf16_ushort を指定します。 つまり、オブジェクトファイルで UTF-16 文字列に変換したい文字列リテラルが コードに含まれている場合、このオプションを使用します。 このオプションを指定しないと、コンパイラは 16 ビット文字列リテラルの生成、認識を行いません。 このオプションを指定すると、U"ASCII_string" 文字列リテラルを 符号なし短整数の配列として認識できるようになります。 このような文字列は標準として規定されていないので、 このオプションを使用して、標準に準拠しない C 言語を 認識することができます。

    -xustr=no を指定し、U"ASCII_string" 文字列定数を 認識しないようにすることができます。 コマンド行でこのオプションを複数指定すると、 一番右以外の指定は無効になります。

    デフォルトは -xustr=no です。 引数を付けずに -xustr を指定すると、 指定が無効になり、警告が発生されます。 C または C++ の標準で構文の意味が定義されると、 このデフォルトの設定は変更される可能性があります。

    U"ASCII_string" 文字列リテラルを指定せずに -xustr=ascii_ustf16_ushort を指定してもエラーにはなりません。

    すべてのファイルをこのオプションを指定してコンパイルする 必要があるわけではありません。

    以下の例では、U の後ろの引用符で囲まれた部分が文字列リテラルです。 また、最後の行は、-xustr を指定するコマンド行です。

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

-xvector[={yes|no}]
    ベクトルライブラリ関数呼び出しの自動生成を有効にします。

    -xvector=yes を指定すると、コンパイラは、可能な限り、ループ内にある数学ライブラリ 呼び出しを、等価なベクトル数学ルーチン呼び出しに変換します。このような 変換の結果として、ループカウントが大きいループではパフォーマンスが 向上する可能性があります。

    -xvector を指定しない場合、デフォルトは -xvector=no です。 -xvector=no は以前に指定した -xvector=yes を無効にします。 -xvector だけを指定して値を指定しない場合、 デフォルトは -xvector=yes です。

    -xdepend を指定していない場合、-xvector をコマンド行 に指定すると、-xdepend が暗黙的に指定されます。最適化レベル を指定していない場合、あるいは、-O3 よりも低い最適化を指定している 場合、-xvector オプションを指定すると、-O3 の最適化レベルが 暗黙的に設定されます。

    コンパイラは、ロード段階において、 libmvec ライブラリを取り込みます。異なるコマンドでコンパイルおよび リンクする場合は、 cc コマンドのリンクで -xvector を指定する必要があります。

-xvis
    (SPARC) VSDK (VIS[tm] 命令セット Software Developers Kit) で定義されているアセンブリ言語 テンプレートを使用する場合、-xvis=[yes|no] コマンドを使用します。デフォルトは -xvis=no です。 -xvis を引数を付けずに指定すると、 -xvis=yes と指定したことになります。

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

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

-xvpara
    (SPARC) ループが正しく並列化されない場合に、警告を出力します。 たとえば、コンパイラがループの繰り返しの間にデータの依存関係を検出すると、 警告が出力されます。

    このオプションは、 -xexplicitpar または -xparallel オプションおよび MP 指令と共に使用してください。

-Yc,<ディレクトリ>
    構成要素 c の位置として、新しい <ディレクトリ> を指定します。 c は、-W オプションで示した構成要素を表わします。

    構成要素の場所を指定すると、 その構成要素の新しいパス名は <ディレクトリ>/<構成要素>になります。 任意の 1 つの項目に対して複数の -Y オプションを適用すると、 最後に指定した内容が保持されます。

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

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

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

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

-Zll
    (SPARC) lock_lint 用プログラムデータベースを作成しますが、実行可能コードは生成しません。

cc は、-a、-e、 -r、-t、-u、-z を認識し、 これらのオプションとそれぞれの引数を ld に渡します。 また、認識できなかったオプションも ld に渡し、 そのことに対する警告を出します。

  プラグマ

コンパイルシステムは以下の #pragma を認識します。

SPARC のみ:

プラグマについての詳細は、『C ユーザーズガイド』を参照してください。

環境

OMP_DYNAMIC
    スレッドの数の動的調整を使用可能または使用不能にします。

OMP_NESTED
    入れ子の並列要素を使用可能または使用不能にします。

OMP_NUM_THREADS
    実行中に使用されるスレッドの数を設定します。

OMP_SCHEDULE
    実行時のスケジュールタイプとチャンクサイズを設定します。

PARALLEL
    マルチプロセッサを利用するときは、 PARALLEL 環境変数を設定します。 PARALLEL 環境変数は、プログラムが利用できるプロセッサの数を指定します。 ターゲットマシンが複数のプロセッサを持っている場合、スレッドが 個々のプロセッサにマップされます。プログラムを実行すると、 プログラムの並列化された部分を実行する 2 つのスレッドが作成されます 。

STACKSIZE
    実行プログラムは、マスタースレッドのメインメモリースタックと各スレーブスレッドの特殊スタックを保持します。スタックは、サブプログラム呼び出し用の引数と自動変数を保持するために使用される、一時メモリーアドレス空間です。メインスタックのデフォルトのサイズは、約 8 メガバイトです。現在のメインスタックのサイズを表示および設定するには、limit コマンドを使用します。

    マルチスレッド化プログラムの各スレーブスレッドには、独自のスレッドスタックがあります。このスタックは、マスタースレッドのメインスタックに似ていますが、スレーブスレッド固有のスタックです。(スレッドに局所的な) 専用配列と変数は、スレッドスタックに割り当てられます。

    スレーブスレッドのスタックサイズはすべて同じです。デフォルトでは、32 ビットアプリケーション用が 4 メガバイトで、64 ビットアプリケーション用が 8 メガバイトです。サイズは、STACKSIZE 環境変数によって設定されます。

    並列化されたコードによっては、スレッドスタックサイズをデフォルト値より大きい値に設定する必要があります。

    コンパイラは、より大きいスタックサイズが必要であることを知らせる警告メッセージを表示することがあります。ただし、特に専用/局所配列が使用される場合には、テストやエラーの場合を除いて、どのようなサイズに設定すべきか分からないことがあります。スタックサイズが小さすぎてスレッドを実行できない場合、セグメント例外によりプログラムは異常終了します。

TMPDIR
    通常、 cc は一時ファイルをディレクトリ tmp に作成します。 環境変数 TMPDIR を別のディレクトリに設定すれば、 そのディレクトリを一時ファイル用のディレクトリとして使用することができます ( TMPDIR が有効なディレクトリでないとき、 cc は tmp を使用します)。 -xtemp は、TMPDIR 環境変数より優先されます。

SUNPRO_SB_INIT_FILE_NAME
    .sbinit(5) ファイルが格納されているディレクトリの絶対パス名。この変数は、 -xsb または -xsbfast フラグを指定したときだけに使用されます。

SUNPROF_DATA
    -xprofile=collect コマンドが実行頻度のデータを保存するファイル名を制御します。

SUNPROF_DATA_DIR
    -xprofile=collect コマンドが実行頻度のデータファイルを置くディレクトリを制御します。

SUNW_MP_THR_IDLE
    ヘルパースレッドのタスク終了状態を制御します。 spin ns または sleep nms に 設定することができます。デフォルトは spin です。 詳細については、、『OpenMP API ユーザーズガイド』を参照してください。

SUNW_MP_WARN
    この環境変数は TRUE に設定し、OpenMP および他の 並列化実行時システムからの警告メッセージを表示するようにします。警告メッセージを扱うため、sunw_mp_register_warn() を使用して関数を登録した場合、SUNW_MP_WARN は警告メッセージを出力しません。TRUE に設定した場合も同様です。関数を登録しないで、SUNW_MP_WARN を TRUE に設定した場合、SUNW_MP_WARN は警告メッセージを stderr に出力します。関数を登録せず、SUNW_MP_WARN を設定しない場合、警告メッセージは出力されません。libmtsk で送出された場合も同様です。sunw_mp_register_warn() について詳細は、C ユーザーズガイド を参照してください。

ファイル
a.out
    実行可能出力ファイル
bb_link.o
    tcov サポート
<ファイル>.a
    オブジェクトファイルのライブラリ
<ファイル>.c
    C 言語のソースファイル
<ファイル>.d
    tcov(1) テストカバレージ入力ファイル
<ファイル>.i
    前処理後の C ソースファイル
<ファイル>.il
    inline(1) 展開ファイル
<ファイル>.ll
    lock_lint データベース
<ファイル>.o
    オブジェクトファイル
<ファイル>.profile
    -xprofile が使用するデータのディレクトリ
<ファイル>.s
    アセンブラのソースファイル
<ファイル>.so
    動的ライブラリ
<ファイル>.tcov
    tcov(1) からの出力
acomp
    コンパイラ・フロントエンド
cc  コンパイラ・コマンド行ドライバ
cg  コードジェネレータ (SPARC)
cg386
    オプティマイザ (Intel)
codegen
    コードジェネレータ (Intel)
crt1.o
    実行時起動コード
crti.o
    実行時起動コード
crtn.o
    実行時起動コード
fbe アセンブラ
gcrt1.o
    gprof(1) を使ったプロファイリングのための実行開始ファイル
gmon.out
    -xpg 用のデフォルトのプロファイルファイル
ipo 内部手続きオプティマイザ (SPARC)
ir2hf
    中間コード変換プログラム (Intel)
iropt
    大域的なオプティマイザ
libldstab_ws.so
    sbfocus ロケータ
libredblack.so
    bids サポート
mcrt1.o
    prof(1) および intro(3) を使ったプロファイリングのための実行開始ファイル
misalign.o
    misalign データサポート (SPARC)
mon.out
    -p 用のデフォルトのプロファイルファイル
postopt
    後置きオプティマイザ (SPARC)
ssbd
    静的同期バグ検出 (SPARC)
stack_grow.o
    スタックオーバーフローチェック (SPARC)
SunWS_cache
    -xsb フラグまたは -xsbfast フラグが使用されたときに sbrowser(1) のデータを格納するディレクトリ
ube オプティマイザ、コードジェネレータ (Intel)
ube_ipa
    内部手続きアナライザ (Intel)
values-xa.o
    -Xa サポート
values-xc.o
    -Xc サポート
values-xpg4.o
    -xpg4 サポート
values-xs.o
    -Xs サポート
values-xt.o
    -Xt サポート

関連項目
analyzer(1)、 as(1)、 dbx(1)、 ild(1)、 ld(1)、 lint(1)、 prof(1)、 sbquery(1)、 tmpnam(3S)
『C ユーザーズガイド』

『ISO/IEC 9899-1990 Programming Language - C standard』

『ISO/IEC 9899-1999 Programming Language - C standard』

<install_directory>/SUNWspro/READMEs/ja/
にある math_libraries の README ファイル
(<install_directory> は通常 /opt です)