CC(1)

名前
CC - C++ コンパイラ

形式

CC  [-386] [-486] [-a] [-B{dynamic|static|symbolic}] [-c] [-cg{89|92}] [-compat[={4|5}]] [+d] [-Dname[=def]] [-d{y|n}] [-dalign] [-dryrun] [-E] [+e{0|1}] [-erroff[=t[,t...]]] [-errtags[=a]] [-errwarn[=t[,t...]]] [-fast] [-features=a[,a...]] [-filt[=filter[,filter...]] [-flags] [-fnonstd] [-fns[={yes|no}]] [-fprecision=a] [-fround=a] [-fsimple[=n]] [-fstore] [-ftrap=a[,a...]] [-G] [-g] [-g0] [-H] [-h[ ]lname] [-help] [-Ipathname] [-I-] [-i] [-inline] [-instances=i] [-instlib=file] [-keeptmp] [-KPIC] [-Kpic] [-Lpath] [-llib] [-libmieee] [-libmil] [-library=lib[,lib...]] [-mc] [-migration] [-misalign] [-mr[,string]] [-mt] [-native] [-noex] [-nofstore] [-nolib] [-nolibmil] [-noqueue] [-norunpath] [-O[n]] [-o file] [+p] [-P] [-p] [-pentium] [-pg] [-PIC] [-pic] [-pta] [-ptipath] [-pto] [-ptrpath] [-ptv] [{-Qoption|-qoption} phase option[,option...]] [{-Qproduce|-qproduce} type] [-qp] [-Rpath[:path...]] [-readme] [-S] [-s] [-sb] [-sbfast] [-staticlib=l[,l...]] [-temp=path] [-template=a[,a...]] [-time] [-Uname] [-unroll=n] [-V] [-v] [-vdelx] [-verbose=a[,a...]] [+w] [+w2] [-w] [-xa] [-xalias_level[=n]] [-xar] [-xarch=isa] [-xbuiltin[={%all|%none}]] [-xcache=c] [-xcg{89|92}] [-xchar[=o]] [-xcheck[=n]] [-xchip=c] [-xcode=v] [-xcrossfile[=n]] [-xdumpmacros[=value[,value...]] [-xe] [-xF] [-xhelp={flags|readme}] [-xia] [-xild{off|on}] [-xinline[=func_spec[,func_spec...]] [-xipo[={0|1|2}] [-xjobs=n] [-xlang=language[,language]] [-xldscope={v}] [-xlibmieee] [-xlibmil] [-xlibmopt] [-xlic_lib=sunperf] [-xlicinfo] [-xlinkopt[=level]] [-Xm] [-xM] [-xM1] [-xMerge] [-xmemalign=ab] [-xnativeconnect[=n]] [-xnolib] [-xnolibmil] [-xnolibmopt] [-xOn] [-xopenmp] [-xpagesize=n] [-xpagesize_heap=n] [-xpagesize_stack=n] [-xpch=v] [-xpchstop] [-xpg] [-xport64[=v]] [-xprefetch[=a[,a]] [-xprefetch_level[=l]] [-xprofile=p] [-xprofile_ircache[=path]] [-xprofile_pathmap=collect_prefix:use_prefix] [-xregs=r[,r...]] [-xs] [-xsafe=mem] [-xsb] [-xsbfast] [-xspace] [-xtarget=t] [-xthreadvar[=f2o]] [-xtime] [-xtrigraphs[={yes|no}]] [-xunroll=n] [-xustr={ascii_utf16_ushort|no}] [-xvis] [-xwe] [-z arg] [file] ...

Sun[tm] Open Network Environment (Sun ONE) Studio 8 C++ コンパイラ

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

プラットフォーム、環境、新機能、およびソフトウェアの修正の最新情報については、以下のコマンドを実行して表示されるオンライン Readme ファイルを参照してください。
CC -xhelp=readme

Readme ファイル、ユーザーズガイド、リファレンスマニュアルを含むすべてのインストール済み Sun ONE Stuido 8 Compiler Collection マニュアルには、HTML ブラウザで以下の URL を指定してアクセスできます。
file:/opt/SUNWspro/docs/ja/index.html

注 — このドキュメントの中で、"IA" という用語は Pentium、Pentium Pro、Pentium II、 Pentium II Xeon、Celeron、Pentium III、および Pentium III Xeon プロセッサを 含む Intel 32 ビットプロセッサアーキテクチャと、AMD と Cyrix によって製造され る互換マイクロプロセッサチップを指します。

機能説明
CC は、C++ とアセンブラのソースファイルをオブジェクトファイルに変換し、 生成されたオブジェクトファイルとライブラリを実行可能プログラムにリンクします。

C++ オブジェクトを含むプログラムは必ず、CC でリンクする必要があります。

CC では、 .c、 .C、 .cc、 .cxx、 .c++、 .cpp、 .i のいずれかの接尾辞を持つ引数は、 C++ のソースプログラムと見なされます。 ファイルの接尾辞が .s の場合はアセンブルのソースファイル、 .o の場合はオブジェクトファイルであると見なされます。

上記の接尾辞を持たないファイルはオブジェクトプログラムまたは ライブラリと見なされ、リンカーに渡されます。 -c、 -S、 -E、 -P のいずれかが指定されていないかぎり、これらのプログラムおよびライブラリは、 指定された任意のコンパイルまたは アセンブルの結果とともに指定された順序でリンクされ、 a.out という名前の実行ファイルが生成されます。 実行ファイルの名前は -o オプションを使用して指定できます。

1 つのファイルのコンパイルとリンクをすべて一度に行うときには、 中間ファイルは削除されます。

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

CC コマンドを使用する前に、C++ コンパイルシステムのインストール場所として選んだ ディレクトリの名前を検索パスに追加してください。 検索パスの設定方法については csh(1) または sh(1) マニュアルページを 参照してください。

64 ビットのコンパイル
C++ コンパイラは、64 ビットカーネルを持つ Solaris 7 および Solaris 8 オペレーティング環境 (SPARC Platform Edition) 上で、64 ビットのオブジェクトバイナリを生成できます。 その実行可能プログラムは、64 ビットカーネルを持つ Solaris 7 および Solaris 8 オペレーティング環境の SPARC V9 (64 ビット) プロセッサのみで実行します。

64 ビットアプリケーションを作成するには、 -xarch=v9、 -xarch=v9a または -xarch=v9b のいずれかのオプションを使用します。 -xtarget または -fast も指定する場合でも、これらのオプションのいずれか 1 つを指定しなけれなりません。 この場合、
-xarch=v9 、 -xarch=v9a または -xarch=v9b オプションは、 -xtarget を設定するオプション ( -fast など) の後に指定しなければなりません。 たとえば、次のように指定します。

-xtarget=ultra -xarch=v9

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

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

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

オプション

マクロオプション (他のオプションを含むオプション) を選択的に無効にするため、 コンパイラオプションは一般に、左から右にかけて処理されます (例外として、 -U オプションはすべての -D オプションの後に処理されます)。 この規則は、リンカーオプションには当てはまりません。

C++ コンパイラオプションについての詳細な説明は、 『C++ ユーザーズガイド』を参照してください。

CC は次のオプションを受け付けます。

-386
    (IA プラットッフォーム) -xtarget=386 を使用します。

-486
    (IA プラットッフォーム) -xtarget=486 を使用します。

-a  -xa を使用します

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

-Bbinding
    ライブラリのリンク方法を指定します。 リンクをシンボリック、動的 (共有、-Bdynamic) または静的 (非共有、-Bstatic) のいずれで 行うかを指定します。
    デフォルトでは動的リンクが行われます。 このオプションはコマンド行の中で繰り返し指定できます。

    -Bbinding についての詳細は、 ld(1) のマニュアルページおよび Solaris のマニュアルを参照してください。

    -Bdynamic このオプションを指定すると、 liblib.so ファイルを検索するようにリンカーに指示します。 リンクのライブラリ束縛を共有にしたい場合は、 -Bdynamic オプションを指定します。 liblib.so ファイルが見つからないと、 liblib.a ファイルを検索します。

    libC を静的にリンクしたい場合は、 -staticlib=libC オプションを使用してください。

    -Bstatic このオプションを指定すると、 リンカーは liblib.a ファイルだけを検索します。 接尾辞 .a は、ファイルが静的、つまり非共有であることを示します。 リンクのライブラリ束縛を非共有にしたい場合は、このオプションを指定します。

    -Bsymbolic は、シンボルが他で定義済みであっても、可能であれば共用ライブラリ内でシンボルを解決します。-Bsymbolic の説明については、ld(1) のマニュアルページを参照してください。

    このオプションと引数は ld リンカーに渡されます。 コンパイルとリンクを別々の工程で行ない、 -Bbinding オプションを使用する場合は、リンク工程で -Bbinding オプションを指定しなければなりません。

    警告:

    C++ コードを含むプログラムには -Bsymbolic を使用しないで、代わりにリンカーマップファイルを使用してください。

    -Bsymbolic を使用すると、異なるモジュール内の参照を、1 つの広域オブジェクトとみなされるターゲットの別のコピーにバインドできます。

    例外メカニズムは、アドレス比較に依存します。何らかのコピーが 2 つある場合、そのアドレスが同一でないと、例外メカニズムは一意とみなされるアドレスの比較に依存するため、例外メカニズムが失敗することがあります。

    別々のステップでコンパイルおよびリンクし、-Bbinding オプションを使用する場合、このオプションはリンクステップに置く必要があります。

-c  ld(1) によるリンクを抑止し、ソースファイルごとに .o ファイルを作成します。 ファイルを 1 つだけコンパイルする場合は、 -o オプションによってオジェクトファイルの名前を指定できます。 以下に例を示します。

    o   以下のように入力すると、オブジェクトファイル x.o が生成されます。

        % CC -c x.cc

    o   以下のように入力すると、オブジェクトファイル y.o が生成されます。

        % CC -c x.cc -o y.o

    警告:

    コンパイラは、入力ファイル (たとえば、.cc、.c、 および .i) のオブジェクトコードを生成するときに、常に作業用ディレクトリに .o ファイルを作成します。リンク工程を抑止する場合には、 .o ファイルは削除されません。

    関連項目:

    -o filename

-cg{89|92}
    -xcg{89|92} を使用します。
    -xtarget=native も参照してください。

-compat[={4|5}]
    コンパイラの主要なリリースの互換モードを設定します。 このオプションにより、プリプロセッサ記号の __cplusplus と __SUNPRO_CC_COMPAT が制御されます。

    C++ コンパイラには 2 つの主要モードがあります。互換モードは、4.2 コンパイラ (-compat[=4]) で定義される Annotated C++ Reference Manual (ARM) 意味論と言語を受け付けます。 標準モードは、ANSI/ISO 標準 -compat=5) に準拠した言語構造を受け付けます。 ANSI/ISO 標準と C++ 4.0.1、4.1、4.2 の間には、名前の符号化、vtable の位置、ABI の細部に ついて多数の相違点があるため、これら 2 つのモードはお互いに互換性がありません。 2 つのモードは、次の表に示すように、 -compat オプションで区別します。

    値   意味

    -compat[=4]
        (互換モード) 言語およびバイナリ互換を 4.0.1、4.1、および 4.2 のコンパイラに設定します。 __cplusplus プリプロセッサマクロを 1 に __SUNPRO_CC_COMPAT プリプロセッサマクロを 4 に設定します。

    -compat=5
        (標準モード) 言語およびバイナリ互換を ANSI/ISO 標準モードに設定します。 (__cplusplus プリプロセッサマクロを 199711Lに __SUNPRO_CC_COMPAT プリプロセッサマクロを 5 に設定する)。

    デフォルト:

    -compat オプションを指定しない場合は、 -compat=5 が設定されます。 -compat だけを指定すると、 -compat=4 が設定されます。 -compat の設定に関係なく、 __SUNPRO_CC_COMPAT は 0x550 に設定されます。

    相互の関連性:

    互換モード (-compat[=4]) で標準ライブラリを使用することはできません。

    -compat[=4] と以下のオプションは併用できません。

    o -Bsymbolic (ライブラリに例外がある場合)
    o -features=[no%]strictdestorder
    o -features=[no%]tmplife
    o -library=[no%]iostream
    o -library=[no%]Cstd
    o -library=[no%]Crun
    o -library=[no%]rwtools7_std
    o -xarch=v9
    o -xarch=v9a
    o -xarch=v9b

    -compat=5 と以下のオプションは併用できません。

    o +e
    o -features=[no%]arraynew
    o -features=[no%]explicit
    o -features=[no%]namespace
    o -features=[no%]rtti
    o -library=[no%]complex
    o -library=[no%]libC
    o -vdelx

    警告:

    互換モードで共用ライブラリを構築する場合、 ライブラリに例外があれば、 (-compat[=4]) は (-Bsymbolic) を使用しません。例外を捕獲できない場合があります。

+d  コンパイラによる C++ インライン関数の展開を抑止します。

    C++ 言語の規則では、C++ インライン関数とは以下の文のどれかが当てはまる関数です。

    o 関数はインラインキーワードを使用して定義されます。

    o 関数はクラス定義の中で定義されます (宣言ではありません)。

    o 関数は、コンパイラが生成したクラスメンバー関数です。

    C++ 言語の規則では、実際にインライン関数の呼び出しをインライン化するかどうかコンパイラが選択できます。以下を除いて、C++ コンパイラはインライン関数の呼び出しをインライン化します。

    o 関数が複雑すぎます。

    o +d オプションが選択されています。

    o -g オプションが選択されています。

    相互の関連性:

    このオプションは、デバッグオプション -g を指定すれば、自動的に有効になります。

    -g0 オプションを指定すると +d は有効になりません。

    +d オプションは -x04 または -x05 を使用した場合に実行される自動インライン化には影響しません。

-Dname[=def]
    マクロシンボル name を def と定義します。これは、ソースファイルの先頭に #define 指令を指定するのと同義です。 -D オプションは、コマンド行で複数回指定する ことができます。

    次の値が事前に定義されています。

    SPARC および IA プラットフォーム:

    __BUILTIN_VA_ARG_INCR
    __cplusplus
    __DATE__
    __FILE__
    __LINE__
    __STDC__
    __SVR4
    __SUNPRO_CC = 0x550
    __SUNPRO_CC_COMPAT = 4 または 5
    __sun
    sun
    __TIME__
    __`uname -s`_`uname -r` (無効な文字列は下線に置き換えられます。 例: -D__SunOS_5_7, -D__SunOS_5_8)
    __unix
    unix
    _WCHAR_T
    __ARRAYNEW 「配列」形式の operator new と operator delete が有効な場合 (「-features=[no%]arraynew」を参照)
    _BOOL bool 型が有効な場合 (「-features=[no%]bool」を参照)

    (SPARC のみ)

    __sparc
    sparc (32 ビット用のコンパイルのみ)

    (SPARC V9 のみ)

    __sparcv9 (64 ビット用のコンパイルのみ)

    (IA プラットフォームのみ)

    __i386
    i386

    デフォルト:

    [=def] を使用しない場合は、 name は 1 として定義されます。

    相互の関連性:

    +p を使用すると、 sun、 unix、 sparc、 i386 は定義されません。

-d{y|n}
    実行可能ファイルすべてに対する動的ライブラリの使用を許可 [禁止] します。

    -dy では、リンカーは動的リンクを行います。これはデフォルトです。

    -dn では、リンカーは静的リンクを行います。

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

    相互の関連性:

    64 ビット環境では、システムライブラリの多くは動的共用ライブラリとして有効です。これには、 libm.so、 および libc.so が含まれ、 libm.a および libc.a は提供されません。結果として、 -Bstatic および -dn により 64 ビット Solaris オペレーティング環境でリンクエラーが発生します。 このような場合、アプリケーションは動的ライブラリとリンクする必要があります。

-dalign
    (SPARC) -dalign は -xmemalign=8s と同じです。詳細については -xmemalign をご覧ください。

-dryrun
    CC ドライバに、コンパイラに渡すオプションを実行はせず、表示するように指示します。

-E  CC ドライバに、C++ ソースファイルに対して前処理のみを行い、 結果を標準出力に送るように指示します。コンパイルは行われず .o ファイルも生成されません。

    このオプションを使用すると、プリプロセッサの行番号付け情報も出力に含まれます

    テンプレートが使用されている場合は、このオプションによる出力を C++ コンパイラへの入力として使用することはできません。

+e{0|1}
    互換モード (-compat[=4]) では仮想関数のクラスに対する仮想テーブルの生成を制御します。 標準モード (デフォルトモード) では無効であり無視されます。

    値:

    o   +e0 仮想テーブルの生成を抑止し、必要とされているテーブルへの 外部参照を生成します。

    o   +e1 仮想関数が定義されたすべてのクラスに対して仮想テーブルを 生成します。

        相互の関連性:

        このオプションでコンパイルする場合は、 -features=no%except も使用してください。それ以外は、コンパイラは例外処理で使用される内部型用に仮想テーブルを生成します。

        テンプレートクラスに仮想関数がある場合、コンパイラがすべての必要な仮想テーブルを生成するが、テーブルが重複しないことを確認できない可能性があります。

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

    値:

    -erroff の値は、以下のいずれか 1 つまたは複数を含むコンマで区切ったリストのメンバーです。

    tag この tag で指定された警告メッセージを抑止します。 -errtags=yes オプションを使用すれば、メッセージのタグを表示できます。

    no%tag
        この tag で指定された警告メッセージを有効にします。

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

    %none
        すべての警告メッセージを有効にします。これはデフォルトです。

    指定の順序は重要です。たとえば、 %all,no%tag は tag を除くすべての警告メッセージを抑止します。

    デフォルト:

    デフォルトは -erroff=%none です。 -erroff を指定することは、 -erroff=%all を指定することと同じです。

    警告:

    -erroff オプションで抑止できるのは、 -errtags オプションが使用されたときにタグが表示される、 C++ コンパイラのフロントエンドからの警告メッセージだけです。

-errtags [ = a]
    -erroff オプションで抑止できる、あるいは -errwarn オプションで重大なエラーとすることのできる、 C++ コンパイラのフロントエンドからの警告メッセージすべての メッセージタグを表示します。 C++ コンパイラドライバや、C++ コンパイルシステムの その他のコンポーネントからのメッセージにはエラータグがなく、 -erroff で抑止したり、 -errwarn で重大なエラーにすることはできません。

    値とデフォルト:

    a は「yes」か「no」です。デフォルトは -errtags=no です。 -errtags を指定することは -errtags=yes を指定することと同じです。

-errwarn [ = t[,t...]]
    このオプションを使用すると、指定した警告メッセージが発生した場合に、 C++ コンパイラがエラーステータスで終了します。

    値:

    t は tag、no%tag、%all, %none の いずれか 1 つ、または複数を含むコンマで区切ったリストです。 指定の順序は重要です。たとえば %all,no%tag と指定した場合、 このタグ以外のなんらかの警告が発せられると、C コンパイラは 重大エラーのステータスで終了します。

    以下は -errwarn の値についての詳しい説明です。

    tag tag で指定されたメッセージが発行されると、 cc は重大エラーのステータスで終了します。 tag が出力されない場合には影響はありません。

    no%tag
        tag で指定されたメッセージが警告メッセージとしてだけ出色された場合に、 cc が重大エラーのステータスで終了するのを回避します。 tag が出色されない場合には影響はありません。 以前、このオプションにtag または %all を付けて行なった、該当のメッセージが警告メッセージとして出力された場合に cc が重大エラーのステータスで終了するという指定を元に戻すには、 このオプションを使用します。

    %all
        なんらかの警告メッセージが発せられた場合に、 cc が重大エラーのステータスで終了します。%all に続けて no%tag を指定すると、特定の警告メッセージについてこの処理を回避させることが できます。

    %none
        どのような警告タグが出力されたとしても、そのメッセージが原因で cc が重大エラーで終了するのを回避します。

    デフォルト:

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

    警告:

    C コンパイラから出される警告メッセージは、リリースによって異なります。 これはコンパイラのエラーチェックの向上や、機能追加によるものです。 -errwarn=%all を使用してコンパイルした結果、エラーが 発生しなかったものが、次のリリースのコンパイラではエラーが発生して しまう場合もあります。

    -errtags オプションの指定時にタグが表示される、 C コンパイラフロントエンドからの警告メッセージについてのみ、 -errwarn の指定によって C コンパイラを エラーステータスで終了させることができます。

    関連項目:

    -erroff、-errtags

-fast
    コンパイルオプションの最適な組み合わせを選択して、コードを コンパイルするシステム上での実行速度を向上させます。 このオプションを指定すると、以下のオプションが展開され、ほとんど のアプリケーションで 最高に近いパフォーマンスが得られます。

    • -fns (SPARC、IA) • -fsimple (SPARC のみ) • -ftrap=%none (SPARC、IA) • -nofstore (IA のみ) • -xarch (SPARC、IA) • -xlibmil (SPARC、IA) • -xlibmopt (SPARC、IA) • -xmemalign (SPARC のみ) • -xO5 (SPARC、IA) • -xtarget=native (SPARC、IA) • -xbuiltin=%all (SPARC, IA)

    相互の関連性:

    コード生成オプション、最適化レベル、組み込み関数の最適化、インラインテンプレートファイルの 使用を指定しても、その後で指定したフラグの方が優先されます。 たとえば、 -fast だけを使用した場合、最適化レベルは -xO5 となりますが、 -fast -xO3 と指定すると -xO3 の最適化レベルが使用されます。 すでに設定されている最適化レベルは、新たに指定した最適化レベルに 置き換えられます。

    -fast マクロはコンパイルオプションまで展開しますが、これは指定された 他のオプションに影響を及ぼすことがあります。 たとえば次のコマンドで、 -fast マクロの展開は -xtarget=native を含み、これは 32 ビットアーキテクチャオプションの 1 つに -xarch を復帰させます。

    無効:
    example% CC -xarch=v9 -fast test.cc

    有効:
    example% CC -fast -xarch=v9 test.cc

    相互の関連性については、各オプションの説明を参照してください。

    警告:

    -fast オプションでコンパイルした場合、そのコードには移植性がありません。 たとえば、UltraSPARC-III システム上で次のコマンドを使用してコードをコンパイル した場合、生成されるバイナリは UltraSPARC-II システム上では実行できません。

    example% CC -fast test.cc

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

    -fast オプションには、 -fns -ftrap=%none が含まれています。つまり、すべてのトラップをオフにします。

    以前の SPARC リリースでは、-fast マクロに -fnonstd が 含まれていましたが、現在は含まれていません。

    以前の SPARC リリースでは、 -fast マクロは -fsimple=1 に展開されていました。現在は -fsimple=2 に展開されます。

    以前の SPARC リリースでは、 -fast マクロは -xO4 に展開されていました。現在は -xO5 に展開されます。

    『数値計算ガイド』、 ieee_sun(3M) も参照してください。

-features=a
    C++ 言語の機能の一部を有効または無効にします。

    別途指定がある場合を除き、以下のフラグは標準モード (デフォルト) と互換モード (-compat[=4]) の両方で有効です。

    値   意味

    %all
        所定のモード (互換モードか標準モード) で有効なすべての -feature オプション。

    %none
        所定のモード (互換モードか標準モード) でオフに切り替えることが できるすべての機能をオフに切り替えます。

    [no%]altspell
        トークンの代わりのスペルを認識します [認識しません] (例、 && の代わりに and)。 デフォルトは、互換モードで no%altspell、標準モードで altspell です。

    [no%]anachronisms
        旧形式の構文を許可 [禁止] します。無効な場合 (-feature=no%anachronisms)、旧形式の構文は許可されません。デフォルトは anachronisms です。

    [no%]arraynew
        (互換モードのみ) operator new と operator delete の配列形式を認識します [認識しません] (例、 operator new[] (void*) )。 有効にすると、マクロ __ARRAYNEW = 1 が定義されます。 有効にしない場合は、マクロは定義されません。 デフォルトは no%arraynew です。 このフラグを使用する方法については、 『C++ 移行ガイド』を参照してください。

    [no%]bool
        bool 型とリテラルを許可 [禁止] します。有効にする場合は、マクロ _BOOL = 1 が定義されます。有効にしない場合は、マクロは定義されません。デフォルトは、互換モードで no%bool、標準モードで bool です。

    [no%]conststrings
        読み取り専用メモリー中にリテラル文字列を置きます [置きません]。デフォルトは、互換モードで no%conststrings、標準モードで conststrings です。

    [no%]except
        C++ 例外を許可 [禁止] します。C++ 例外が無効 (-features=no%except) のとき、関数の throw 指定が受け付けられますが、無視されます。 コンパイラは例外コードを生成しません。try、throw、および catch キーワードは常に保持されます。デフォルトは except です。

    [no%]explicit
        (互換モードのみ) キーワード explicit を認識します [認識しません]。 デフォルトは、no%explicit です。

    [no%]export
        キーワード export を認識します [認識しません]。 デフォルトは互換モードで no%export、標準モードで export です。

    [no%]extensions
        その他の C++ コンパイラで一般的に受け付けられる非標準コードを許可 [禁止] します。-features=extensions オプションを使用する際にコンパイラが受け付ける無効なコードに関する説明は、 C++ ユーザーズガイドの第 4 章を参照してください。 デフォルトは -features=no%extenstions です。

    [no%]iddollar
        $ を非初期識別文字として許可 [禁止] します。 デフォルトは no%iddollar です。

    [no%]localfor
        for 文に対して、新しい「局所的スコープの規則」を適用します [適用しません]。デフォルトは互換モードで no%localfor、標準モードで localfor です。

    [no%]mutable
        キーワード mutable を認識します [認識しません]。 デフォルトは、互換モードで no%mutable、標準モードで mutable です。

    [no%]namespace
        (互換モードのみ) キーワード namespace と using を認識します [認識しません]。 デフォルトは no%namespace です。

        -features=namespace の目的は、コードの標準モードへの変換をサポートすることです。これらのキーワードを識別子として使用している場合、このオプションを有効にするとエラーメッセージが出力されます。このキーワード認識オプションを使用すると、標準モードでコンパイルすることなく、追加キーワードの使用を検出できます。

    [no%]rtti
        (互換モードのみ) 実行時の型識別 (RTTI) を許可 [禁止] します。 dynamic_cast<> 演算子と typeid 演算子を使用するには、RTTI を有効にしなければなりません。 デフォルトは no%rtti です。

    [no%]split_init
        ローカルでない静的オブジェクトの初期設定子を各関数に設定します [しません]。-features=no%split_init を使用する場合、コンパイラによりすべての初期設定子が一つの関数に設定されます。-features=no%split_initを使用すると、可能なコンパイル時間でコードの大きさを最小化します。デフォルトは split_init です。

    [no%]strictdestorder
        (標準モードのみ) 静的な記憶期間を持つオブジェクトを破壊する 順番について、C++ 標準に従います [従いません]。 デフォルトは strictdestrorder です。

    [no%]tmplife
        (標準モードのみ) ANSI/ISO C++ 標準規格で定義されているように、 ある式によって生成された一時オブジェクトを、 式全体が終わる時点で消去します [しません] ( -features=no%tmplife が指定されている場合は、 ほとんどの一時オブジェクトは、そのブロックの最後で 消去されます)。デフォルトは tmplife です。

    [no%]transitions
        標準 C++ で問題となり、予期できない動作をしたり、将来のコンパイラで動作しない可能性のある ARM 言語構成を許可 [禁止] します。 -features=no%transitions を使用する場合、コンパイラはエラーメッセージの代わりにこれらの構成に関する警告を出力します。 互換モード (-compate[=4]) で -features=transitions を使用した場合は、 +w または -w2 が指定された場合のみ、コンパイラはこれらの構成に関する警告を表示します。以下の構成は移行エラーと考えられ、使用後にテンプレートを再定義し、 typename がテンプレート定義に必要な場合に省略し、 型 int を暗黙に宣言します。 移行エラーの設定は将来のリリースでは変更される可能性があります。デフォルトは transitions です。

    デフォルト:

    -features を指定しない場合、互換モード (-compat[=4]) では -features=%none,anachronisms,except,split_init,transitions が仮定されます。

    -features を指定しない場合、標準モード (デフォルトモード) には -features=%all,no%iddollar,no%extensions が仮定されます。

    相互の関連性:

    このオプションは上書きされずに累積されます。

    標準モード (デフォルト) で次のいずれかを使用すると、 標準ライブラリおよび標準ヘッダーとの互換性がなくなります。

    o no%bool
    o no%except
    o no%mutable
    o no%explicit

    警告:

    -features=tmplife を使用すると、プログラムの動作が変わる可能性があります。 -features=tmplife オプションがプログラムの正しい動作に影響を及ぼすかどうかを 調べることは、プログラムの移植性を検査することにもなります。

-filt[=filter[,filter...]
    通常 CC がリンカーからのエラーメッセージに対して行う、 フィルタ処理を抑止します。

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

    [no%]errors
        リンカーからのエラーメッセージに関する、C++ の説明を表示します [しません]。 説明を抑止すると、リンカーの診断が別のツールに直接渡される場合に役立ちます。

    [no%]names
        C++ の符号化されたリンカー名を復号化します [しません]。

    [no%]returns
        関数の戻り型を符号化します [しません]。 符号化を抑止すると、関数名をより簡単に特定できます。 ただし、仮想関数の場合、関数名は同じで戻り型のみが 異なる関数があるため、注意が必要です。

    [ no% ] stdlib
        リンカーおよびコンパイラ双方のエラーメッセージに含まれる、 標準ライブラリの名前を簡素化します[しません]。 これにより、標準ライブラリ関数の名前を容易に認識できる ようになります。

    %all
        -filt=errors,names,returns,stdlib を指定することと同じです。 これは、デフォルトの動作です。

    %none
        -filt=no%errors,no%names,no%returns,no%stdlib と指定することと同じです。

    デフォルト:

    -filt オプションを使用しない場合、 または -filt を値なしで指定した場合は、 コンパイラは -filt=errors,names,returns,stdlib が指定されたものと仮定します。

    相互の関連性:

    [no%]returns no%names と一緒に使用された場合は無効です。 つまり、次のオプションはすべて同じ意味を持ちます。

    -filt=no%names
    -filt=no%names,no%returns
    -filt=no%names,returns

-flags
    -xhelp=flags と同義です。

-fnonstd
    このオプションによって、浮動小数点オーバーフロー、ゼロによる除算、 無効な演算例外によるハードウェアトラップが可能になります。

    これらのトラップは SIGFPE シグナルに変換され、 プログラムに SIGFPE ハンドラがない場合は、メモリーダンプを残して終了します (コアダンプのサイズをゼロに限定していない場合)。

    SPARC: さらに、 -fnonstd は SPARC 非標準浮動小数点を選択します。

    デフォルト:

    -fnonstd を指定しない場合、IEEE 754 浮動小数点演算例外はプログラムを中断せず、 アンダーフローは段階的になります。

    拡張:

    IA: -fnonstd は -ftrap=common に拡張されます。

    SPARC: -fnonstd は -fns -ftrap=common に拡張されます。

    詳細については、-fns と -ftrap=common ならびに『数値計算ガイド』を参照してください。

-fns[={no|yes}]

    SPARC: SPARC 非標準の浮動小数点モードを選択します。

    このフラグを設定すると、プログラムが実行を開始するときに、 非標準の浮動小数点モードが有効になります。

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

    -fast などのマクロは、-fns を含む複数のオプションに展開されます。 マクロ中の -fns オプションの設定だけを変更したい場合は、マクロの指定の後に -fns オプションを =yes または =no 付きで指定してください。 この指定内容は、マクロに含まれるものよりも優先されます。

    -fns は -fns=yes と同義です。
    -fns=yes と指定すると、非標準の浮動小数点が使用されます。 -fns=no と指定すると、標準の浮動小数点が使用されます。

    デフォルト:

    このフラグを指定しない場合、非標準の浮動小数点モードは自動的に 有効になりません。代わりに、 標準 IEEE 754 浮動小数点演算が行われます。 つまり、アンダーフローは段階的になります。

    -fns だけを指定した場合、 -fns=yes が仮定されます。

    警告:

    非標準の浮動小数点が使用される場合は、浮動小数点算術演算の結果が、IEEE 754 標準に 準拠しないことがあります。

    このオプションは、SPARC プラットフォーム上でメインプログラムのコンパイル時に 使用された場合にのみ有効です。IA プラットフォームでは、このオプションは無視されます。

    -fns を使用してルーチンを 1 つコンパイルした場合、プログラム中のその他すべてのルーチンも同じ -fns オプションを使用してコンパイルしてください。そうしないと、 予想外の結果が生じることがあります。

-fprecision=a
    (IA プラットフォーム) 浮動小数点の丸め精度モードを設定します。 a には、 single、 double、 extended のいずれかを指定します。

    -fprecision フラグは、浮動小数点制御ワード中の丸め精度モードのビットを設定します。 これらのビットは、基本算術演算 (加算、減算、乗算、除算、平方根) の結果を 丸める精度を制御します。

    以下に、 a の値と意味を示します。

    値   意味

    single
        IEEE 単精度値に丸めます。

    double
        IEEE 倍精度値に丸めます。

    extended
        最大精度値に丸めます。

    a を single または double にすると、プログラムが実行を開始するときに、 丸め精度モードがそれぞれ単精度または倍精度に設定されます。 a を extended にするか、 -fprecision フラグを使用しないときは、丸め精度モードは拡張精度のままになります。

    single 精度の丸めモードでは、結果が 24 ビットの有効桁に丸められます。また、 double 精度の丸めモードでは、53 ビットの有効桁に丸められます。デフォルトの extended 精度の モードでは、64 ビットの有効桁に丸められます。このモードは、 レジスタ中の結果を丸めるときの精度だけを制御します。レジスタの 値には影響がありません。 レジスタ中の結果はすべて、拡張倍精度形式のすべての範囲を 使用して丸められます。 メモリー中に格納される結果は、指定した形式の範囲と精度を 使用して丸め られています。

    float 型の公称精度は、 single です。 long double 型の公称精度は、 extended です。

    デフォルト:

    -fprecision フラグが指定されていない場合、デフォルトの丸め精度モードは extended になります。

    警告:

    このオプションは、IA プラットフォームで、メインプログラムのコンパイル時に 使用された場合にのみ有効です。SPARC プラットフォームでは、 このオプションは無視されます。

-fround=a
    IEEE 丸めモードを起動時に有効に設定します。

    a には、 nearest、tozero、negative、positive のいずれかを指定してください。

    値   意味

    nearest
        もっとも近い値の方向に丸め、中間値の場合は偶数にします。

    tozero
        ゼロの方向に丸めます。

    negative
        負の無限の方向に丸めます。

    positive
        正の無限の方向に丸めます。

    このオプションで設定される IEEE 754 丸めモードは以下のものです。

    •   定数式を評価するときにコンパイラが使用できる。

    •   プログラム初期化中の実行時に設定される。

    これは、ieee_flags サブルーチンと同義で、 実行時のモード変更に使用できます。

    デフォルト:

    -fround オプションを指定しないとき、丸めモードはデフォルトで -fround=nearest になります。

    警告:

    このオプションを使用してルーチンを 1 つコンパイルしたら、 プログラム中のその他のすべてのルーチンも -fround=a を使用してコンパイルしてください。そうしないと、予想外の結果 が生じることがあります。このオプションは、メインプログラムを コンパイルするときに使用する場合だけ有効です。

-fsimple[=n]
    浮動小数点の最適化を簡素化するために、仮定の設定レベルを選択します。

    n を指定する場合は、0、1、2 のいずれかを指定します。

    以下に、 -fsimple の値と意味を示します。

    値   意味

    0   仮定の設定を許可しません。IEEE 754 基準に厳密に準拠します。

    1   安全な簡素化を許可します。 生成されるコードは IEEE 754 に厳密には準拠していませんが、 プログラムの数値演算の結果は、ほとんどの場合変わりません。

        -fsimple=1 を指定すると、オプティマイザは丸めや例外を完全に無視して最適化を 行うことはできません。 特に、浮動小数点演算の場合で、実行時に適用される丸めモードで 異なる値を生成する演算には置き換えることはできません。

        -fasimple=1 を指定すると、オプティマイザは以下の事柄を仮定して最適化を行います。

        o   プロセスを初期化した後でも、 IEEE 754 のデフォルトの丸めモードおよびトラップモードは変化しません。

        o   潜在的な浮動小数点例外を除き、目に見える結果が生成されない演算は、 削除される可能性があります。

        o   オペランドとして無限大または非数 (NaN) を使用した演算は、 演算結果に NaN を反映させる必要はありません。 たとえば、x*0 は 0 に置き換えられます。

        o   演算は、ゼロの符号には依存しません。

    2   丸め方法を変更して積極的な最適化を行うので、 生成される数値結果が異なるプログラムが多くなります。たとえば、 x/y がループ中で必ず 1 回以上評価され、 z=1y および y と z の値はループの実行中には定数値をとることが 保証されている場合には、 オプティマイザがそのループ中にある x/y という計算をすべて x*z に置き換えることを許可します。

    デフォルト:

    -fsimple を指定しない場合、コンパイラは -fsimple=0 を使用します。

    -fsimple を指定するが、 n に値を指定しない場合、コンパイラは -fsimple=1 を使用します。

    警告:

    このオプションは IEEE 754 に準拠しない場合があります。

-fstore
    (IA プラットフォーム) 強制的に浮動小数点式の精度を使用します。

    浮動小数点式または浮動小数点関数が変数に代入された場合、 または浮動小数点式がより短い浮動小数点型にキャストされた場合に、 レジスタに値をそのまま残さずに、式または関数の値を代入式の左辺の型に 変換します。

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

    警告:

    四捨五入や切り上げによって、結果がレジスタの値と異なることが あります。

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

    このオプションは、プログラムの初期化時に確立された IEEE 754 トラップモードを設定しますが、 SIGFPE ハンドラはインストールしません。 ieee_handler を使用すると、トラップを有効にすると同時に、 SIGFPE ハンドラもインストールできます。複数の値を使用すると、 リストは左から右の順番に処理されます。

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

    値   意味

    [no%]division
        ゼロによる除算時にトラップします [しません]。

    [no%]inexact
        不正確な結果時にトラップします [しません]。

    [no%]invalid
        無効な演算時にトラップします [しません]。

    [no%]overflow
        オーバーフロー時にトラップします [しません]。

    [no%]underflow
        アンダーフロー時にトラップします [しません]。

    %all
        上記すべての場合にトラップします。

    %none
        上記のいずれの場合にもトラップしません。

    common
        無効な演算、ゼロによる除算、およびオーバーフロー時にトラップします。

    このオプションの [no%] の形式は、 %all または common の値の意味を変更する場合に限って使用してください。 例に示すとおり、必ずこれらいずれかの値とともに使用する必要があります。 [no%] の形式だけでは、特定のトラップが明示的に無効になることはありません。

    IEEE トラップを有効にするには、 -ftrap=common を設定することをお勧めします。

    デフォルト:

    -ftrap を指定しない場合、 -ftrap=%none 値が仮定されます (トラップは自動的に無効になります)。

    例:

    1 つ以上の値を指定すると、値は左から右の順番に処理されます。したがって、 -ftrap=%all、no%inexact は、 inexact 以外のすべてのトラップを設定することになります。

    相互の関連性:

    ieee_handler(3M) では、モードは実行時に変更される可能性があります。

    警告:

    -ftrap を使用してルーチンを 1 つコンパイルした場合、 プログラムのすべてのルーチンも同じ -ftrap オプションを使用してコンパイルしてください。 そうしないと、予想外の結果が生じることがあります。

    -ftrap=inexact を使用してトラップすると、浮動小数点値が正確に表現できない場合でも トラップが行われるため、注意が必要です。たとえば、次の文でこの 状態が発生します。

    x = 1.0 / 3.0;

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

-G  実行可能ファイルでなく、動的共有ライブラリを構築します。 ld(1) のマニュアルページおよび『C++ ユーザーズガイド』を 参照してください。 コマンド行で指定するソースファイルはすべてデフォルトで -Kpic でコンパイルされます。

    テンプレートを使用する共有ライブラリを構築するとき、ほとんどの場合、 テンプレートデータベースにインスタンス化されているテンプレート関数は 共有ライブラリに取り込む必要があります。 このオプションを使用すると、これらのテンプレートが必要に応じて 自動的に共有ライブラリに追加されます。

    -c が指定されていなければ、オプション -dy 、 -G 、 -R が ld に渡されます。

    共用ライブラリの構築には、ld -G を使用しないで、CC -G を使用してください。CC ドライバは C++ に必要な ld に対していくつかのオプションを自動的に渡します。

    -G オプションを使用する場合、コンパイラはデフォルトの -l オプションを ld に渡しません。共用ライブラリがその他の共用ライブラリに依存性を持つようにするには、必要な -l オプションをコマンド行に渡す必要があります。例えば、共用ライブラリが libCrun に依存するようにするには、-lCrun をコマンド行に渡す必要があります。

-g  コンパイラとリンカーに、デバッグで使用するファイルとプログラムを 用意するように指示します。これには、次の処理が含まれています。

    •   オブジェクトファイルと実行可能ファイルのシンボルテーブル内に、 詳細情報 (スタブ) を生成します。

    •   「支援関数」を生成します。デバッガはこれを呼び出して、 デバッガの機能のいくつかを実装します。

    •   関数のインライン化を不可にします。つまり、 +d オプションを指定したことになります。

    •   特定のレベルの最適化を無効にします。

        相互の関連性:

        このオプションを -xO[level] 、あるいは、それと等価なオプション ( -O など) と併用する場合、デバッグ情報が制限されます。詳細は -xO の項目を参照してください。

        最適化レベル -xO3 かまたはそれ以下で、このオプションを使用する場合、コンパイラはほとんど完全な最適化とともに最善のシンボリック情報を提供します。末尾呼び出し最適化およびバックエンドのインライン化は無効になります。

        最適化レベル -xO4 かそれ以上で、このオプションを使用する場合、コンパイラはほとんど完全な最適化とともに最善のシンボリック情報を提供します。

        このオプションを指定すると、 +d オプションは自動的に指定されます。

        このオプションを指定すると、 -xildon が指定されてデフォルトのリンカーがインクリメンタルリンカーになるため、 コンパイル、編集、デバッグの 開発作業にかかる時間を短縮することができます。 -xildon および -xildoff の項目を参照してください。 以下の条件がすべてあてはまらない場合は、 ld ではなく ild を起動します。

    •   -G オプションを指定している

    •   -xildoff オプションを指定している

    •   コマンド行でソースファイルを指定している

    パフォーマンスアナライザのすべての機能を使用 するには、 -g でコンパイルしてください。 パフォーマンス解析の機能には、 -g を必要としないものありますが、注釈付きのソース、機能レベル情報、コンパイラコメン トメッセージを表示するには、 -g でコンパイルする必要があります。詳細については、analyzer(1) マニュアルページおよび『プログラムのパフォーマンス解析』の「データ収集と解析のためのプログラムの準備」を参照してください。

    -g で生成されたコメントメッセージは、プログラムをコンパイルする際にコンパイラが生成 する最適化と変換について記述します。 ソースコードでインタリーブされたメッセージを表示するには、 er_src(1)、 コマンドを使用してください。

    関連項目:

    ld(1) のマニュアルページのほかに、 -go および +d の項目も参照してください。dbx スタブの詳細については、 『dbx コマンドによるデバッグ』を参照してください。

-g0 デバッガ用のシンボルテーブル情報を生成します。ただし、 C++ のインライン展開は可 能なままです。 このオプションは、 +d が無効になることを除いて、 -g と同義です。

    +d も参照してください。

-H  標準エラー出力 ( stderr ) に、現在のコンパイルで対象となる各 #include ファイルのパス名が 1 行 ずつ出力されます。

-h[ ]lname
    生成される共有動的ライブラリに名前 lname を割り当てます。

    これはローダー用のオプションで、 ld に渡されます。 -h の後に指定する名前は、 -o オプションで指定したファイル名と同一にします。 -h と lname の間には、空白を入れても入れなくてもかまいません。

    コンパイル時のローダーは、指定された lname を作成中の動的共有ライブラリに割り当て、その lname をそのライブラリのイントリンシック名としてライブラリの中に記録します。 -hlname オプションを指定しない場合には、イントリンシック名はライブラリファイルに 記録されません。

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

    % CC -G -o libx.so.1 -h libx.so.1 a.o b.o c.o

    相互の関連性:

    このオプションは上書きされずに累積されます。

-help
    -xhelp=flags と同義です。

-i  LD_LIBRARY_PATH の設定を無視するようにリンカー ld(1) に伝えます。

-Ipathname
    相対ファイル名 (先頭が / でないファイル名) で指定された インクルードファイルの検索ディレクトリのリストに pathname を追加します。 コンパイラは、二重引用符で囲まれたインクルードファイル (例: #include "foo.h") を次の順序で検索します。

    1.  ソースファイルを含むディレクトリ

    2.  -I オプションで指定されたつディレクトリ (もしあれば)

    3.  コンパイラが提供する C++ ヘッダーファイル、ANSI C ヘッダーファイル、 および特殊ファイルのための include ディレクトリ

    4.  usrinclude

    コンパイラは、山括弧で囲まれたインクルードファイル (例: #include <foo.h>) を次の順序で検索します。

    1.  -I オプションで指定された名前を持つディレクトリ (もしあれば) ソースファイルを含むディレクトリ

    2.  コンパイラが提供する C++ ヘッダーファイル、ANSI C ヘッダーファイル、 および特殊ファイルのための include ディレクトリ

    3.  usrinclude

    注 — ファイル名が標準ヘッダーのファイル名と重なってしまった場合は、 『C++ ユーザーズガイド』の「標準ヘッダーの実装」を参照してください。

    相互の関連性:

    このオプションは上書きされずに累積されます。

    -I- オプションを使用すると、デフォルトの検索規則を変更できます。

    -library=no%Cstd を指定した場合、コンパイラが提供する Cstd ヘッダーファイルは検索されません。

    注 — -ptipath オプションが使用されていない場合、コンパイラは -Ipathname 中のテンプレートファイルを探します。 -ptipath オプションではなく、 -Ipathname オプションを使用することをお勧めします。

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

    o   #include "foo.h" という形式のインクルードファイルの場合は、 次の順序でディレクトリを検索します。

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

        2.  コンパイラが提供する C++ ヘッダーファイル、ANSI C ヘッダーファイル、および 特殊ファイルのためのディレクトリ

        3.  /usr/include

    o   #include <foo.h> という形式のインクルードファイルの場合は、 次の順序でディレクトリを検索します。

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

        2.  コンパイラが提供する C++ ヘッダーファイル、ANSI C ヘッダーファイル、 および特殊ファイルのためのディレクトリ

        3.  /usr/include

    警告:

    -I- オプションは、コマンド行 1 行につき 1 度しか使用できません。

-i  すべての LD_LIBRARY_PATH 設定を無視するようリンカー ld(1) に伝えます。

-inline
    -xinline と同じです。

-instances=a
    テンプレートのインスタンスの配置とリンクを制御します。 以下に a の値と意味を示します。

    値   意味

    extern
        必要なすべてのインスタンスを comdat セクションに配置し、 大域的なリンケージを与えます (リポジトリ内のインスタンスが古い場合は、 再インスタンス化が行われます)。
        注: コンパイルとリンクを別々のステップで行なうときに、 コンパイルのステップで -instance=extern を指定すると、 同じようにリンクのステップでも指定しなければなりません。

    explicit
        明示的にインスタンス化されたインスタンスを comdat セクション内の 現在のオブジェクトファイルに配置し、大域リンケージを与えます。 必要なその他のインスタンスは生成しません。

    global
        すべての必要なインスタンスを comdat セクション内の 現在のオブジェクトファイルに配置し、大域リンケージを与えます。

    semiexplicit
        明示的にインスタンス化されたインスタンスと すべての必要なインスタンスを comdat セクション内の 現在のオブジェクトファイルに配置し、大域リンケージを与えます。

    static
        注: -instances=static は旧式なものとなりました。-instances=global が static の利点を備えながら欠点をなくしたため、 -instances=static を使う理由はなくなりました。 このオプションは古いコンパイラで発生する問題を克服するために 提供されていましたが、こうした問題は C++ 5.5 には存在しません。
        すべての必要なインスタンスを現在のオブジェクトファイルに配置し、静的リンケージを与えます。

    デフォルト:

    -instances を指定しない場合、 -instances=global が仮定されます。

    警告:

    値として static および semiexplicit を指定すると、無効な結果になることがあります。 詳細は『C++ ユーザーズガイド』を参照してください。

-instlib=file

    このオプションを使用すると、静的ライブラリ、共有ライブラリ、 または現在のオブジェクトの中で、 重複するテンプレートインスタンスの生成を禁止できます。 一般に、ライブラリを使用するプログラムが多数のインスタンスを 共有する場合、-instlib=file を指定して コンパイル時間の短縮を試みることができます。

    値:

    file 引数を使って、既存のテンプレートインスタンスが 含まれていることがわかっているライブラリを指定します。 ファイル名の引数にはスラッシュ (「/」) が入っていなければなりません。 現在のディレクトリへの相対パスとしては、ドットとスラッシュ(「./」)を 使います。

    デフォルト:

    -instlib=file オプションにはデフォルトはなく、 指定した場合にのみ働きます。このオプションは複数指定でき、 指定内容は追加されていきます。

    例:

    libfoo.a ライブラリと libbar.so ライブラリが、 ソースファイル a.cc と共有する 多数のテンプレートインスタンスをインスタンス化するとします。 -instlib=file を追加してライブラリを指定すると、 冗長性が回避され、コンパイル時間の削減に役立ちます。

    example% CC -c -instlib=./libfoo.a -instlib=./libbar.so a.cc

    相互の関連性:

    -g を使ってコンパイルするとき、-instlib=file で 指定されたライブラリが -g でコンパイルされていないと、 そのテンプレートインスタンスはデバッグできるようになりません。 対処方法は、-g を使うときには -instlib=file を避けるようにすることです。

    file の値は -L パスの一部として検索されません。

    警告

    -instlib でライブラリを指定する場合は、リンク時にそのライブラリを 使用しなければなりません。

    関連項目:

    -template 、-instances 、-pti

-keeptmp
    コンパイル中に作成された一時ファイルをすべて保持します。 このオプションを -verbose=diags と一緒に使用すると、デバッグに便利です。

-KPIC
    (SPARC プラットフォーム) -xcode=pic32 と同義です。

    (IA プラットフォーム) -Kpic と同義です。

-Kpic
    -xcode=pic13 と同義です。

    (SPARC プラットフォーム) -xcode=pic13 と同義です。

    (IA プラットフォーム) 位置独立コードを生成します。このオプションは、 共有ライブラリを構築するときに ソースファイルを構築するために使用します。大域的なデータへの 各参照はポインタの 間接参照として大域的なオフセットテーブルに生成されます。 各関数呼び出しは、手続きリンケージテーブル経由で、PC の 相対アドレッシングモードで 生成されます。

-Lpath
    ライブラリ検索パスに path を追加します。

    このオプションは ld に渡されます。リンカーは path で指定されたディレクトリを検索してから、 コンパイラが提供するディレクトリを検索します。

    相互の関連性:

    このオプションは上書きされずに累積されます。

-llib
    リンカーのライブラリ検索用のリストにライブラリ liblib.a または liblib.so を追加します。

    このオプションは ld に渡されます。通常のライブラリは、 liblib.a または liblib.so ( lib と .a または .so の部分は必須) という名前を持っています。このオプションでは、 lib の部分を指定できます。1 行のコマンド行に希望する数だけのライブラリを 指定できます。これらのライブラリは、 -Lpath で指定した順序で検索されます。

    このオプションは、オブジェクトファイル名の後に指定してください。

    相互の関連性:

    このオプションは上書きされずに累積されます。

    警告:

    マルチスレッドアプリケーションを構築したり、マルチスレッドライブラリに アプリケーションをリンクする場合には、 -lthread を使ってアプリケーションを直接的にリンクする代わりに、 -mt オプションを使ってプログラムをコンパイルし、リンクしなければなりません。

    POSIX スレッドを使用する場合には、 -mt -lpthread オプションを使ってリンクしなければなりません。マルチスレッド アプリケーションでは libC (互換モード) と libCrun (標準モード) に libthread が必要なので、 -mt オプションが必要です。

    関連項目:

    -mt

-libmieee
    -xlibmieee を使用します。

-libmil
    -xlibmil を使用します。

-library=lib[,lib...]
    指定した CC 提供ライブラリをコンパイルとリンクに組み込みます。

    -library オプションを使って CC 提供ライブラリを指定した場合、コンパイル 時に適切な -I パスが設定され、リンク時には適切な -L, -Y, -P, および -R パスと -l オプションが設定されます。

    値:

    以下に lib の値と意味を示します。

    互換モード (-compat[=4]) の場合:

    値   意味

    [no%]f77
        推奨しません。 -xlang=f77 を使用しないでください。

    [no%]f90
        推奨しません。 -xlang=f90 を使用しないでください。

    [no%]f95
        推奨しません。 -xlang=f95 を使用しないでください。

    [no%]rwtools7
        従来の iostreams Tools.h++ バージョン 7 を使用します [しません]。

    [no%]rwtools7_dbg
        デバッグが有効な Tools.h++ バージョン 7 を使用します [しません]。

    [no%]complex
        libcomplex (複素数演算) を使用します [しません]。

    [no%]interval
        推奨しません。使用しないでください。 -xia を使用してください。

    [no%]libC
        libC (C++ サポートライブラリ) を使用します [しません]。

    [no%]gc
        libgc (ガベージコレクション) を使用します [しません]。

    [no%]sunperf
        SPARC: Sun Performance Library(TM) を使用します [しません]。

    %all
        推奨しません。 -library=%all は -library=f77、 f90、 rwtools7、 complex、 interval、 gc を指定するのと同じです。 libC ライブラリは、 -library=no%libC を使用して特別に除外されない限りは、常にインクルードされることに注意してください。

    %none
        libC を除いたいずれの C++ ライブラリも使用しません。

    標準モード (デフォルトモード) の場合:

    値   意味

    [no%]f77
        推奨しません。 -xlang=f77 を使用しないでください。

    [no%]f90
        推奨しません。 -xlang=f90 を使用しないでください。

    [no%]f95
        推奨しません。 -xlang=f95 を使用しないでください。

    [no%]rwtools7
        従来の iostreams Tools.h++ バージョン 7 を使用します [しません]。

    [no%]rwtools7_dbg
        デバッグが有効な Tools.h++ バージョン 7 を使用します [しません]。

    [no%]rwtools7_std
        標準 iostreams Tools.h++ バージョン 7 を使用します [しません]。

    [no%]rwtools7_std_dbg
        デバッグが有効な標準 iostreams Tools.h++ バージョン 7 を使用します [しません]。

    [no%]interval
        推奨しません。使用しないでください。 -xia を使用してください。

    [no%]iostream
        libiostream (従来の iostream ライブラリ) を使用します [しません]。

    [no%]Cstd
        libCstd (C++ 標準ライブラリ) を使用します [しません]。コンパイラが提供する Cstd ヘッダーファイルをインクルードします [インクルードしません]。

    [no%]stlport4
        標準ライブラリのSTL ポートの実装を使用します [しません]。-library=stlport4 を指定すると、コマンドは -library=no%Cstd,stlport4 に拡張されます。

    [no%]stlport4_dbg
        STLport のデバッグが有効なライブラリを使用します[しません]。

    [no%]Crun
        libCrun (C++ 実行時ライブラリ) を使用します [しません]。

    [no%]gc
        libgc (ガベージコレクション) を使用します [しません]。

    [ no% ]sunperf
        SPARC: Sun Performance Library (TM) を使用します [しません]。

    %all
        推奨しません。 -library=%all は -library=f77、 f90、 rwtools7、 gc、 interval、 iostream、 Cstd と同じです。 libCrun ライブラリは -library=no%Crun を使用して特別に除外されない限り、常にインクルードされることに注意してください。

    %none
        libC run 以外のいずれの C++ ライブラリも使用しません。

    デフォルト:

    互換モード (-compat[=4])で -library が指定されない場合、 -library=%none が指定されます。

    libC ライブラリは -library=no%libC を使用して特別に除外されない限り、常にインクルードされます。

    標準モード (デフォルトモード) で、 -library が指定されない場合、 -library=%none,Cstd が指定されます。

    libCstd ライブラリは、-library=%none または -library=no%Cstd または -library=stlport4 を使用して特別に除外されない限り、常にインクルードされます。

    libCrun ライブラリは -library=no%Crun を使用して特別に除外されない限り、常にインクルードされます。

    例:

    C++ ライブラリ (libCrun を除く) なしで標準モード (デフォルトモード) でリンクするには、次のコマンドを使用します。

    example% CC -library=%none

    標準モードで 従来の iostreams Rogue Wave tools.h++ ライブラリを取り込むには、次のコマンドを使用します。

    example% CC -library=rwtools7,iostream

    標準モードで標準 iostreams Rogue Wave tools.h++ ライブラリを取り込むには、次のコマンドを使用します。

    example% CC -library=rwtools7_std

    互換モードで 従来の iostreams Rogue Wave tools.h++ ライブラリを取り込むには、次のコマンドを使用します。

    example% CC -compat -library=rwtools7

    標準モード (デフォルトモード) で従来の iostreams Rogue Wave tools ライブラリを取り込む場合、libiostream も含める必要があります (詳細は『C++ 移行ガイド』を参照)。標準 iostreams Rogue Wave tools ライブラリは、標準モードでのみ使用できます。以下のコマンド例は、Rogue Wave tools.h++ ライブラリオプションの有効な使用法と無効な使用法を示しています。

    有効:
    example% CC -compat -library=rwtools foo.cc
    無効:
    example% CC -compat -library=rwtools_std foo.cc

    有効 (従来の iostreams)
    example% CC -library=rwtools,iostream foo.cc
    無効 example% CC -library=rwtools foo.cc

    有効 (標準 iostreams)
    example% CC -library=rwtools_std foo.cc
    無効
    example% CC -library=rwtools_std,iostream foo.cc

    libCstd と libiostream を両方含める場合、同じファイルにアクセスするためにプログラム内で古い形式と新しい形式の iostreams (たとえば cout と std::cout) を混在しないように気を付けてください。同一プログラム内に標準 iostreams とクラシック iostreams が混在する場合、従来のものと標準 iostream コードから同じファイルにアクセスがあると問題が発生する恐れがあります。

    libC にも libCrun にもリンクしないプログラムは、C++ 言語のすべての機能を使用できないことがあります。

    -xnolib が指定されると、-library は無視されます。

    相互の関連性:

    -library を使用してライブラリを指定すると、コンパイル時に適切な -I パスが設定されます。リンク時には適切な -L、-Y、-P、-R パスおよび -I オプションが設定されます。

    このオプションは上書きされずに累積されます。

    rwtool ライブラリは一度に 1 つだけ使用できます。-library=stlport4 では rwtool ライブラリを使用できません。

    -library=stlport4 および -library=Cstd は同じコマンド行では使用できません。

    -library=sunperf および -xlic_lib=sunperf は同じコマンド行では使用できません。

    -library オプションを使用すれば、指定されたライブラリの -l オプションを 正しい順序で出力できます。 たとえば、 -library=rwtools7 、 iostream でも -library=iostream 、 rwtools7 でも -l オプションは -lrwtool -liostream の順序で ld に渡されます。

    区間演算ライブラリを使用する場合は、 libCstd、 libiostreams のいずれかのライブラリを使用しなければなりません。

    指定したライブラリは、システムサポート ライブラリがリンクされる前にリンクされます。

    警告:

    STLport、Rogue Wave、Sun Microsystems の C++ ライブラリの 構成マクロはいずれも再定義したり変更したりしないでください。 これらのライブラリは C++ コンパイラとともに動作するように 構成および構築されています。libCstd と Tool.h++ は 相互に働き合うように構成されているので、その構成マクロを変更すると、 プログラムがコンパイル、リンクされなかったり、あるいは正しく 実行されなかったりします。

    コンパイルとリンクを別々の手順で実行する場合、コンパイルコマンドの -library オプションで指定した内容は、リンクコマンドでも指定される必要があります。

    一連のライブラリ群は恒久的なものではないため、リリースごとに変更される 可能性があります。

    stlport4、Cstd、iostream の各ライブラリには それぞれの入出力ストリームの実装が存在します。 -library オプションでこれらの中から複数を指定すると、 結果として、プログラムが予測できない動作をする可能性があります。

    以下の理由から、 -library=%all オプションを使用しないことをお勧めします。

        o コマンドによって実際にインクルードされるライブラリ群は、各リリース間で異なる 可能性があります。

        o 予期したライブラリが指定されない可能性があります。

        o 予期しないライブラリが指定される可能性があります。

        o 他の開発者がメークファイルのコマンド行を見ても、実際に何がリンクされるのかを 知ることはできません。

        o このオプションはコンパイラの将来のリリースでは削除される予定です。

    関連項目:

    -I、 -l、 -R、 -staticlib、 -xia、 -xlang、 -xnolib

    『C++ 移行ガイド』、 『C++ Interval Arithmetic Programming Reference』『Tools.h++ ユーザーズガイド』、 『Tools.h++ クラスライブラリ・リファレンスマニュアル』、 『Standard C++ Class Library Reference』

-mc オブジェクトファイルの .comment セクションから重複している文字列を削除します。文字列が空白文字を含む場合、その文字列を引用符で囲む必要があります。mc オプションを使用すると、 -mcs -c コマンドが呼び出されます。

-migration
    以前のバージョンのコンパイラ用に構築されたソースコードの移行についての情報が置かれている場所について記述しています。

    注 — このオプションは次のリリースで廃止される予定です

-misalign
    (SPARC プラットフォーム) メモリー中に境界整列の誤ったデータが存在することを許可します。 このオプションを指定しないと、 境界列の正しくないデータに対してエラーが生成されます。

    このオプションは、プログラム内のデータが正しく整合されていないことを コンパイラに通知します。 したがって、正しく整合されない可能性のあるデータについては、読み込 みと保存を抑えなければなりません (具体的には一度に 1 バイト)。このオプションを使用すると、実行時の性能 が大幅に低下することがあります。 この性能低下の度合いは、アプリケーションによって異なります。

    コンパイルとリンクを別の工程で行ない、 -misalign オプションを使用する場合は、両方の工程で -misalign オプションを指定しなければなりません。

    可能な場合は、プログラム中の境界整列の正しい部分と正しくない部分を互いに リンクしないようにしてください。

    相互の関連性:

    o   SPARC プラットフォームで #pragma pack を使ってタイプのデフォルト整列よりも濃密なパックを実行するときは、アプリケーションのコンパイルとリンクの両方で -misalign オプションを指定しなければなりません。

    o   不整合データは、実行時に ld から供給されるトラップ機構によって処理されます。 -misalign オプションとともに最適化フラグ (-xO{1|2|3|4|5} かそれと同等のフラグ) を使用する場合には、不整合データの整合に要求される追加の命令は オブジェクトファイルの中に挿入され、実行時不整合トラップは生成しません。

-mr[,string]
    オブジェクトファイルの .comment セクションからすべての文字列を削除し、string が指定された場合は、そのセクションに string を配置します。文字列が空白文字を含む場合、その文字列を引用符で囲む必要があります。このオプションを使用すると、コマンドmcs -d [-a string] が呼び出されます。

    相互の関連性:

    このオプションは -S、-xsbfast、-sbfast のどれかが指定されている場合は、有効ではありません。

-mt マルチスレッド化されたコード用のコンパイルおよびリンクを行います。

    このオプションは次のことを実行します:

    o   -D_REENTRANT をプリプロセッサに渡します。

    o   -lthread を正しい順序で ld に渡します。

    o   標準モード (デフォルトモード) で、 libCrun よりも前に libthread がリンクされることを保証します。

    o   互換モード (-compat) で libC よりも前に libthread がリンクされることを保証します。

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

    警告:

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

    POSIX スレッドを使用する場合には -mt -lpthread オプションを使ってリンクしなければなりません。マルチスレッドアプリケーションでは、 libC
     (互換モード) と libCrun (標準モード) に libthread が必要なので、 -mt オプションが必要です。

    別々のステップでコンパイルとリンクを行い、-mt でコンパイルした場合、予期しない結果になる可能性があります。-mt で一つの翻訳単位をコンパイルする場合、プログラムのすべての単位を -mt でコンパイルしてください。

    並列 Fortran オブジェクトと C++ オブジェクトを混在させる場合は、 リンク行に -mt フラグを指定しなければなりません。

    互換モード (-compat=4) では C99 サポートは利用できません。

    関連項目:

    -xnolib

-native
    -xtarget=native を使用します。

-noex
    -features=no%except を使用します。

-nofstore
    (IA プラットフォーム) 式の精度を強制しません。

    このオプションでは、 浮動小数点の式または関数の値が、代入式の左辺の型に強制的に変換 されることはありません。 また、浮動小数点の式または関数を変数に割り当てたり、短い浮動小数点 型に変換しても、レジスタ中の値は保持されます。

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

-nolib
    -xnolib を使用します。

-nolibmil
    -xnolibmil を使用します。

-noqueue
    ライセンスを待ち行列に入れません。 ライセンスを取得できないと、 コンパイラは要求を待ち行列に入れたり、 コンパイルを行わずに終了します。 メークファイルのテストでは、ゼロ以外の状態が返されます。

-norunpath
    共有ライブラリ用のパスを実行可能ファイル中に構築しません。

    実行可能ファイルが共有ライブラリを使用している場合、 コンパイラは通常、実行時リンカーに共有ライブラリの場所を 伝えるために、構築を行なったパスを知らせます。 具体的には、コンパイラが -R オプションを ld に渡します。このパスは、コンパイラのインストール先ディレクトリに よって決まります。

    製品用の実行可能ファイルを構築する場合で、その製品のユーザーが 共有ライブラリのパスとして、プログラムで使用されるパスとは異なるパスを 使用する可能性があるときに、このオプションを使用することをお勧めします。

    相互の関連性:

    コンパイラがインストールされた場所 (デフォルトは optSUNWsprolib) でいずれかの共有ライブラリを使用し、同時に -norunpath も使用する場合は、リンク時に -R を指定するか、実行時に LD_LIBRARY_PATH 環境変数を設定して共有ライブラリの位置を指定する必要があります。 これによって、実行時リンカーが共有ライブラリを検索できるようになります。

-O  -xO2 と同義です。

-O [ level ]
    -xO level を使用します。

-ofilename
    コンパイラが生成するバイナリファイル (接尾時 .o ) または実行可能ファイルの名前 filename を指定します。

    注 — コンパイラは、テンプレートインスタンスを格納する必要がある場合に、 出力ファイルの ディレクトリにあるテンプレートリポジトリにテンプレートインスタンスを格納します。

    警告:

    filename (ファイル名) には、コンパイルが作成するファイルの種類を示す適切な接尾辞を 付けてください ( 「ファイル」 の項目を参照)。 また、 CC このオプションは上書きされずに累積されます。 filename とソースファイル を同じにしないでください。

+p  非標準プリプロセッサ断定を無視します。

    デフォルト:

    +p が存在しない場合、コンパイラは非標準プリプロセッサ表明を認識します

    相互の関連性:

    +p を使用する場合は、 sun, unix, sparc, および i386 マクロは定義されません。

-P  ソースの前処理だけを行います。コンパイルは行いません ( .i という接尾辞の付いたファイルが生成されます)。

    このオプションでは、プリプロセッサが出力するような 行番号はファイルに出力されません。

-p  prof(1) でプロファイリングを行うためのデータを収集する オブジェクトコードを作成します。実行内容を記録し、正常終了時に mon.out というファイルを生成します。

    警告:

    別々のステップでコンパイルおよびリンクする場合、 -p オプションはコンパイルコマンドおよびリンクコマンド両方に存在する必要があります。 あるステップに -p をインクルードして、その他のステップにはインクルードしなくてもプログラムの正確さには影響ありませんが、プロファイルができなくなるでしょう。

    -xpg -xprofile analyzer(1) のマニュアルページを参照してください。
    『プログラムのパフォーマンス解析』

-pentium
    (IA プラットフォーム) -xtarget=pentium を使用します。

-pg -xpg を使用します。 SPARC: -xcode=pic32 と同じです。

    IA: -KPIC と同じです。

-pic
    SPARC: -xcode=pic13 と同じです。

    IA: -Kpic と同じです。

-pta
    -template=wholeclass を使用します。

-ptipath
    テンプレートソースの検索対象ディレクトリを指定します。

    これは、 -Ipathname で設定した通常の検索パスに代わるオプションです。 -ptipath フラグを使用すると、コンパイラはこのパス上でテンプレート定義ファイルを探し、 -Ipathname フラグを無視します。

    -ptipath の代わりに、 -Ipathname フラグを使用すると、混乱が起きにくくなります。

    相互の関連性:

    このオプションは上書きされずに累積されます。

-pto
    -instances=static を使用します。

-ptrpath
    このオプションは廃止されており、コンパイラによって無視されます。

    警告:

    -ptr オプションは無視されますが、今後のリリースで、異なる扱いで再利用される可能性があるので、すべてのコンパイルコマンドから削除する必要があります。

-ptv
    -verbose=template を使用します。

-Qoption phase option[,option...]
    オプション option をコンパイル段階に渡します。

    コンパイル段階 phase に指定するオプションは、以下のとおりです。

    SPARC
        IA

    ccfe
        ccfe

    iropt
        cg386

    cg  codegen

    CClink
        CClink

    ld  ld

    例:

    ld が CC ドライバから起動されたとき、 -Qoption は -i オプション を ld に渡します。

    example% CC -Qoption ld -i test.cc

    警告:

    意図しない結果を防ぐために注意してください。次はその例です。

    -Qoption ccfe -features=bool,iddollar

    これは次のように解釈されます。

    -Qoption ccfe -features=bool -Qoption ccfe iddollar

    正しい用法は次のとおりです。

    -Qoption ccfe -features=bool,-features=iddollar

-qoption phase option
    -Qoption を使用します。

-qp -p と同義です。

-Qproduce sourcetype
    CC ドライバに sourcetype に指定した種類のソースコードを生成するよう指示します。 以下に、ソースコードの種類を示します。

    値   意味

    .i  ccfe が作成する前処理済みの C++ のソースコード

    .o  コード生成プログラムが作成するオブジェクトファイル

    .s  コード生成プログラムが作成するアセンブラソース

-qproduce sourcetype
    -Qproduce を使用します。

-Rpath[:path...]
    動的ライブラリの検索パスを実行可能ファイルに構築します。

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

    デフォルト:

    -R オプションが存在しない場合、ライブラリは出力オブジェクトに記録されたパスを検索し、 -xarch オプション ( -xarch が連結されていない場合は、 -xarch-generic が仮定されます) により指定されたターゲットアーキテクチャー命令に依存する実行時リンカーに渡されます。

    -xarch=v9 、 -xarch=v9a、または -xarch=v9b

    <install-directory>/SUNWspro/lib/v9

    その他の -xarch 値:

    <install-directory>/SUNWspro/lib

    標準インストールでは、 <install-directory> は /opt になります。

    相互の関連性:

    このオプションは上書きされずに累積されます。

    環境変数 LD_RUN_PATH と -R オプションの両方を指定すると、 -R オプションで指定したパスが検索され、 LD_RUN_PATH で指定されたパスは無視されます。

    関連項目:

    -norunpath

-readme
    -xhelp=readme と同義です。

-S  アセンブリコードのコンパイルと生成だけを行います。 CC ドライバはプログラムをコンパイルして、アセンブリソースファイルを作成しますが、 プログラムのアセンブルは行いません。このアセンブリソースファイル名には、 .s という接尾辞が付きます。 プログラムのアセンブルは行いませんが、 接尾辞 .s の付いたアセンブリソースファイルを生成します。

-s  実行可能ファイルからシンボルテーブルを削除します。 出力される実行可能ファイルからすべてのシンボル情報が削除されます。 このオプションは ld に渡されます。

-sb CC -xsb を使用します。

-sbfast
    -xsbfast を使用します。

-staticlib=l[,l...]
    -library オプション (デフォルトのライブラリを含む) により、 -xlang オプション中で、 -xia オプションを使用して指定される C++ ライブラリのうち、静的にリンクされるライブラリを指示します。

    値:

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

    値   意味

    [no%]library
        library に静的にリンクします [しません]。library に有効な値は、すべて -library に有効な値 ( %all および %none を除く) および -xlang に有効な値、および interval ( -xia と連結して使用) です。

    %all
        -library オプションにより指定されたすべてのライブラリ、 -xlang オプションに指定されたすべてのライブラリ、 -xia が指定された場合は区間ライブラリを静的にリンクします。

    %none
        -library オプションおよび -xlang オプションに指定されたライブラリに静的にリンクしません。 -xia がコマンド行に指定された場合、区間ライブラリを静的にリンクしません。

    デフォルト:

    -staticlib を指定しないときは、 -staticlib=%none が仮定されます。

    相互の関連性:

    このオプションは上書きされずに累積されます。

    -staticlib オプションは、-xia オプション、-xlang オプション、および -library オプションで 明示的に選択された C++ ライブラリ、または、デフォルトで暗黙的に 選択された C++ ライブラリだけに機能します。互換モード (-compat=[4]) では、 libC がデフォルトで 選択されます。標準モード (デフォルトのモード) では、 Cstd と Crun が デフォルトで選択されます。

    例:

    次のコマンドは、 Crun が -library のデフォルト値であるため、 libCrun を静的にリンクします。

    (正)
    example% CC -staticlib=Crun test.cc

    ただし、 libgc は -library オプションで明示的に指定されない限りリンクされないので、次のコマンドは libgc をリンクしません。

    (誤)
    example% CC -staticlib=gc test.cc

    次のコマンドは、librwtool ライブラリを動的にリンクします。librwtool はデフォルトのライブラリでもなく、-library オプションでも選択されていないため、-staticlib の影響はありません。

    (誤)
    example% CC -lrwtool -library=iostream \
    -staticlib=rwtools7

    次のコマンドは、Tools.h++ ライブラリを静的にリンクします。

    (正)
    example% CC -library=rwtools7,iostream \
    -staticlib=rwtools7

    警告:

    使用できるライブラリの値は安定しておらず、リリースごとに変わることがあります。

    -xarch=v9 、 -xarch=v9a 、または -xarch=v9b (または同じ意味の 64 ビットアーキテクチャーオプション) を使用するときには、一部のライブラリは静的ライブラリとして使用できません。

-temp=path
    一時ファイル用のディレクトリを定義します。

    コンパイル中に生成される一時ファイル用のディレクトリとして path を指定します。

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

-template=a[,a...]
    各種のテンプレートオプションを有効または無効にします。

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

    値   意味

    [no%]extdef
        別のソースファイル中のテンプレート定義を検索します [しません]。

    [no%]geninlinefuncs
        明示的にインスタンス化されたクラステンプレートの インラインメンバー関数をインスタンス化します [しません]。

    [no%]wholeclass
        使用されている関数だけではなく、テンプレートクラス全体をインスタンス化します [しません]。少なくともクラス中の一つのメンバーを参照する必要があります。それ以外は、コンパイラはクラスのいずれのメンバーもインスタンス化しません。

    デフォルト:

    -template=no%wholeclass,extdef,no%geninlinefuncs

-time
    -xtime を使用します。

-Uname
    プリプロセッサシンボル name の初期定義を削除します。 このオプションは -D が同じコマンド行で作成したマクロシンボル name の初期定義を削除します。これには、コマンド行ドライバ により暗黙的に置かれたものも含まれます。

    その他のソースファイル中で使用される事前定義されたマクロやマクロ定義に影響はありません。

    コマンド行ドライバによりコマンド行に置かれた -D オプションを参照するには、コマンド行に -dryrun オプションを追加してください。

    -U オプションは、1 行のコマンド行で複数回指定できます。

    例:

    以下のコマンドは事前定義されたシンボル __sun を未定義にします。 #ifdef(__sun) のような test.cc 中のプリプロセッサ文は、シンボルが未定義であることを意味しています。

    example% CC -U__sun test.cc

    相互の関連性:

    このオプションは上書きされずに累積されます。

    すべての -U オプションは、存在するすべての -D オプションの後で処理されます。

-unroll=n
    -xunroll=n と同義です。

-V  -verbose=version と同義です。

-v  -verbose=diags と同義です。

-vdelx
    このフラグは互換モード (-compat[=4]) だけで利用できます。

    delete[] を使用する式では、このオプションにより、 _vector_delete_ への呼び出しではなく、実行時ライブラリ関数 _vector_deletex_ への呼び出しが生成されます。

    関数 vector_delete_ は 2 つの引数をとります。1 つ目の引数は削除されるポインタで、 2 つ目の引数は各配列要素のサイズです。

    関数 _vector_deletex_ は、3 つ目の引数をとりますが、それ以外 vector_delete と同じように動作します。3 つ目の引数はクラスのデストラクタのアドレスです。 この 3 つ目の引数は関数では使用されませんが、サン以外のベンダー用に 用意されています。

    デフォルト:

    -vdelx を指定しない場合、コンパイラは、 delete[] を使用する式に対して、 _vector_delete_ への呼び出しを生成します。

-verbose=a[,a...]
    コンパイラの冗長性を制御します。

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

    値   意味

    [no%]template
        テンプレートをインスタンス化する冗長モード (検証モードとも言います) をオンにします [しません]。 冗長モードでは、 コンパイル中に行われるインスタンス化の各段階が表示されます。

    [no%]diags
        コンパイル段階ごとにコマンド行に出力します [しません]。

    [no%]version
        CC ドライバは、起動されるプログラムの名前とバージョン番号を出力します [しません]。

    %all
        上記のすべてを行います。

    %none
        上記のいずれも行いません。

    デフォルト:

    -verbose が指定されていない場合、コンパイラは -verbose=%none を仮定します。

    相互の関連性:

    このオプションは上書きされずに累積されます。

+w  意図しない結果を生じる可能性のあるコードを識別します。+w オプションは、関数が大きすぎてインライン化できなかったり、宣言されたプログラム要素が使用されない場合は、警告を出力しなくなりました。これらの警告は、ソース上の実際の問題を識別しないので、開発環境によっては不適切でした。このような環境では、これらの警告を +w から削除することによって、より広範に +w を使用できます。これらの警告は、+w2 オプションで使用可能です。

    o   移植性がない

    o   誤りである可能性がある

    o   効率が悪い

    デフォルト:

    +w を指定しない場合、 コンパイラは、ほぼ間違いなく誤りである構造についてのみ警告を出力します。

    相互の関連性:

    C++ 標準ヘッダーの中には、 +w 付きでコンパイルすると警告を出力するものがあります。

+w2 +w で報告される警告に加えて、技術的な違反についての警告を報告します。 +w2 で報告される警告は、危険性はないが、プログラムの移植性を 損なう可能性があるものです。

    +w2 オプションは、システムヘッダーファイルにおける実装依存構造の使用についての警告を出力しなくなりました。システムヘッダーファイルは実装なので、この警告は不適切です。これらの警告を +w2 から削除することによって、より広範にこのオプションを使用できます。

    警告:

    Solaris ソフトウェアおよび C++ の標準ヘッダーファイルの中には、 +w2 を指定してコンパイルすると警告を出力するものがあります。

-w  警告メッセージを抑止します。

    このオプションにより、コンパイラから警告メッセージが出力されなくなります。 ただし警告メッセージの中には、廃止された内容に対する警告など、 抑止できないものもあります。

-xa プロファイル用のコードを生成します。

    コンパイル時にこのオプションが設定された場合、 カバレージ (.d) ファイルが存在するディレクトリは、 TCOVDIR 環境変数によって指定されます。この TCOVDIR が設定されて いない場合、カバレージ (.d) ファイルは同じディレクトリにソースファイルとして残ります。

    このオプションは、古いカバレージファイルとの下位互換性のためだけに使用してください。プロファイルの新しいスタイルについては、 -xprofile=tcov を参照してください。詳細は、 tcov(1) のマニュアルページと『プログラムのパフォーマンス解析』を参照してください。

    相互の関連性:

    -xprofile=tcov と -a オプションは、単一の実行可能ファイル内では互換性があります。 つまり、 -xprofile=tcov でコンパイルしたファイルと -xa でコンパイルしたファイルが混在するプログラムはリンクできます。 両方のオプションを使用して単一のファイルをコンパイルすることはできません。

    -xa には、 -g との互換性はありません。

    警告:

    コンパイルとリンクを別の段階で行う場合、コンパイル時には、 リンクの段階で使用したものと同じ -xa オプションを使用しなければなりません。そうしないと、 予想外の結果が生じることがまれにあります。

-xalias_level[= n]
    コンパイラが、型に基づいた別名解析を実行します。

    デフォルト:

    n は any、simple、compatible のいずれかです。

    o -xalias_level

        -xalias_level を値なしで指定する場合、コンパイラにより -xalias_level=empty が設定されます。

    o -xalias_level=any

        この解析レベルでは、コンパイラはどの型も他の任意の型の別名になるとみなします。ただし、このように仮定しても、一部の最適化は可能です。

    o -xalias_level=simple

        コンパイラは、基本型は別名にならないとみなします。特に、以下のいずれかの基本型の動的な型を持つ記憶オブジェクトは、特定の型の lvalues からのみアクセスされます。

          * char、signed char、および unsigned char
          * wchar_t
          * short int、unsigned short int
          * int、unsigned int
          * long int、unsigned long int
          * long long int、unsigned long long int
          * float、double、long double
          * 列挙型
          * データポインタ型
          * 関数ポインタ型
          * データメンバーポインタ型
          * 関数メンバーポインタ型

        この場合の lvalues の型は以下のとおりです。

          * オブジェクトの動的な型

          * オブジェクトの動的な型を
            constant および volatile で修飾したもの

          * オブジェクトの動的な型の
            符号付き、または符号なしの型

          * オブジェクトの動的な型を
            constant および volatile で修飾したもの
            符号付き、または符号なしの型

          * 上記の型の 1 つをメンバーに含む
             (副集合体または含まれる共用体
            のメンバーを再帰的に含む) 集合
            体型または共用体型

          * 文字型または無符号文字型

    o -xalias_level=compatible

        コンパイラは、レイアウト非互換型は別名にならないとみなします。記憶オブジェクトは以下の型の lvalues からのみアクセスされます。

        * オブジェクト型の動的な型

        * オブジェクト型の動的な型を
          constant および volatile で修飾したも

        * オブジェクトの動的な型の
          符号付き、または符号なしの型

        * オブジェクトの動的な型を
          constant および volatile で修飾したもの
          符号付き、または符号なしの型

        * 上記の型の 1 つをメンバーに含む
           (副集合体または含まれる共用体の
          メンバーを再帰的に含む) 集合体型
          または共用体型

        * 動的オブジェクト型の (場合によって
          は定数またはvolatile修飾) 基本クラス型

        * 文字型または無符号文字型

        コンパイラは、すべての参照の型は、対応する動的記憶オブジェクト型とレイアウト互換性があるとみなします。2 つの型は、以下の条件でレイアウト互換型となります。

        * 2 つの型が同じ型であれば、この
          2 つは配置互換です。

        * 2 つの型が constant および volatile修飾かの
          点のみが異なる場合、この 2 つは
          配置互換です。

        * 符号付の整数型について、対応する
           (ただし異なる) 符合なしの整数型が
          存在する場合、これらの対応型は
          配置互換です。

        * 2 つの列挙型は、基本型が同じで
          あれば配置互換です。

        * 2 つの Plain Old Data (POD) 構造
          体型は、メンバー数が同じで、対応
          するメンバーが (順番に) 配置互換で
          ある場合は、配置互換です。

        * 2 つの POD 共用体型は、メンバー数
          が同じで、対応するメンバーが (任意
          の順序で) 配置互換である場合は、
          配置互換型です。

        参照は、動的記憶オブジェクト型とレイアウト非互換になることがありますが、以下の状況に制限されます。

        * POD 共用体が、共通の初期シーケンス
          を共有する 2 つ以上の POD 構造体を
          持ち、POD 共用体オブジェクトが現在
          これらの POD 構造体の 1 つを含んで
          いる場合、構造体の共通初期部分を調
          べることができます。2 つの POD 構造
          体は、対応するメンバーが配置互換で
          あり、ビットフィールドが該当する場合は、
           つまたは複数の初期メンバーの
          シーケンスについて幅が同じであるとき、
          共通初期シーケンスを共有します。

        * POD 構造体オブジェクトへのポインタは、
          reinterpret_cast を使用して適切に変換
          され、初期メンバーを指します。そのメン
          バーがビットフィールドの場合は、ビット
          フィールドが属すユニットを指します。

    相互の関連性:

    コンパイラは、最適化レベル -x02 以下では型に基づく別名解析を行いません。

-xar
    アーカイブライブラリを作成します。

    テンプレートを使用する C++ のアーカイブをコンパイルするときには 通常、後でインスタンス化されてテンプレートリポジトリに入れられる 可能性のあるテンプレート関数をアーカイブの中にあらかじめ入れておく 必要があります。このオプションは自動的にそれらの テンプレートを必要に応じてアーカイブに追加します。

    値:

    -xar を指定して ar -c-r を起動し、スクラッチから アーカイブを作成します。

    例:

    次のように実行すると、ライブラリおよびオブジェクトファイルに含まれている テンプレート関数をアーカイブします。

    example% CC -xar -o libmain.a a.o b.o c.o

    警告:

    コマンド行では、テンプレートリポジトリの .o ファイルは追加しないでください。

    アーカイブを作成するときに、 ar コマンドを直接使用することはできません。 CC -xar を使用して、テンプレートのインスタンス化がアーカイブの中に自動的に 取り込まれるようにする必要があります。

    関連項目:

    ar(1)

-xarch=isa
    ターゲットの命令セットアーキテクチャ (ISA) を指定します。

    このオプションは、コンパイラが生成するコードを、指定した命令セット アーキテクチャの命令だけに制限します。このオプションは、ターゲットに固有な 命令の使用を保証するものではありません。ただし、このオプションを使用すると、 バイナリプログラムの移植性に影響が生じることがあります。 注と警告の部分も参照してください。

    コンパイルとリンクを別々の手順で行なう場合には、 どちらの手順でも同じ -xarch の値を指定するように してください。

    値:

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

    値   意味

    generic
        ほとんどのシステムで良好なパフォーマンスを得られるように 32 ビットオブジェクトバイナリを生成します。

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

    generic64
        ほとんどの 64 ビット対応プラットフォームで最高のパフォーマンスを得る ために 64 ビットオブジェクトバイナリを生成します。

        このオプションは、 どのプロセッサでも大きく パフォーマンスを落とさずに 64 ビットカーネル Solaris オペレーティング環境で良好なパフォーマンス を得るための最良の命令セットを使用します。「最良な命令セット」の定義は、 必要に応じてリリースごとに調整される可能性があります。

    native
        当該システムで良好なパフォーマンスを得られるように 32 ビットオブジェクトバイナリを生成します。

        これは -fast オプションのデフォルトです。コンパイラは、プロセッサが実行している システムに適切な設定を選択します。

    native64
        当該システムで良好なパフォーマンスを得られるように 64 ビットオブジェクトバイナリを生成します。

        コンパイラは、プロセッサが実行している現在のシステムに適切な設定を選択します。

    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-V8 plus 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 と v8plusa でコンパイルしたオブジェクトバイナリファイル (.o) は、 SPARC V8plusa 互換プラットフォーム上でのみ、一緒にリンク および実行できます。

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

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

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

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

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

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

    値   意味

    generic
        ほとんどのシステムで良好なパフォーマンスを得られるようにコンパイルします。

        これはデフォルトです。このオプションは、どのプロセッサでも大きく パフォーマンスを落とさずに、ほとんどのプロセッサで良好なパフォーマンスを 得るための最良の命令セットを使用します。新しいリリースごとに、 「最良な命令セット」の定義を調節する必要があるかもしれません。

    386 このリリースでは、generic と 386 は同じです。

    pentium_pro
        Intel 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 ...

    -xarch=v9、 -xarch=v9a、 または -xarch=v9b オプションは -compat[=4] オプションとは併用できません。

    警告:

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

-xbuiltin[={%all|%none}]
    標準ライブラリ呼び出しの最適化を有効にしたり無効にしたりします。

    デフォルトでは、標準ライブラリのヘッダーで宣言された関数は コンパイラにより通常の関数として扱われます。 しかし、いくつかの関数はコンパイラにより、組み込みとして認識することができます。 組み込みとして扱われた場合、コンパイラはより効果的なコードを生成できます。 例えば、コンパイラは、いくつかの関数には副作用がないと認識でき、常に同じ入力から 同じ出力を戻します。 コンパイラにより直接インラインに生成される関数もあります。

    -xbuiltin=%all はコンパイラにできるだけ多くの組み込み標準関数を認識させようとします。 認識された関数の正確なリストは、コンパイラコードジェネレータのバージョンに より変化します。

    -xbuiltin=%none はデフォルトの動作です。

    デフォルト:

    -xbuiltin オプションが指定されていない場合、コンパイラは -xbuiltin=%none を想定します。 -xbuiltin のみが指定されている場合は、コンパイラは -xbuiltin=%all を想定します。

-xcache=c
    (SPARC プラットフォーム) オプティマイザが使用できるキャッシュの属性を定義します。

    このオプションによって、特定のキャッシュ属性が使用されるわけではありません。

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

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

    o   generic

    o native

    o s1/l1/a1

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

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

    つまり、
    -xcache={generic | s1/l1/a1[:s2/l2/a2[:s3/l3/a3]]} のように指定します。si/li/ai は、次のように定義されています。

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

    li  レベル i のデータキャッシュの行サイズ (バイト)

    ai  レベル i のデータキャッシュの結合規則

    たとえば、 i=1 により、レベル 1 のキャッシュ属性、 s1l1a1 が指定されます。

    以下に -xcache の値を示します。

    値   意味

    generic
        ほとんどの SPARC プロセッサ上で良好なパフォーマンスが得られ るキャッシュ属性を定義します。

        ほとんどの SPARC 上で良好なパフォーマンスが得られ、 どのプロセッサ上でもパフォーマンスが低下するこ とがないような、キャッシュ属性を使用するように コンパイラに指示する、デフォルトの値です。

    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:

    16K バイト
        1024K バイト

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

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

-xcg89
    -xtarget=ss2 と同じです。

    警告:

    単独のステップでコンパイルおよびリンクを行い、 -xcg89 でコンパイルした場合、同じオプションでリンクすることに留意してください。さもないと、予期しない結果になる可能性があります。

-xcg92
    -xtarget=ss1000 と同じです。

    警告:

    単独のステップでコンパイルおよびリンクを行い、 -xcg92 でコンパイルした場合、同じオプションでリンクすることに留意してください。さもないと、予期しない結果になる可能性があります。

-xchar=o
    このオプションは、文字型が符号なしとして定義されているシステムからの コードを容易に移植できるようにするためだけに提供されています。 こうしたシステムから移植するのでなければ、 このオプションは使用しないでください。 文字型の符号に依存するコードだけが、明示的に符号付き、符号なしを 指定して書き直される必要があります。

    値:

    o は次のいずれか 1 つで置き換えることができます。

    o   signed: 文字定数および変数を、符号付きとして宣言されているものと して取り扱います。このことでコンパイルされたコードの動きに影響が 生じますが、ライブラリルーチンの動きには影響ありません。

    o   s: signed と同じです。

    o   unsigned: 文字定数および変数を、符号なしとして宣言されているものとして取り扱います。このことでコンパイルされたコードの動きに影響が 生じますが、ライブラリルーチンの動きには影響ありません。

    o   u: unsigned と同じです。

    デフォルト:

    -xchar を指定しない場合、コンパイラは -xchar=s と 仮定します。-xchar を指定して、値は指定しなかった場合、 コンパイラは -xchar=s と仮定します。

    相互の関連性:

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

    警告:

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

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

-xcheck[=n]
    (SPARC プラットフォーム) スタックオーバーフローの実行時チェックを行います。

    値:

    n は以下のいずれかの値です。

    値   意味

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

    %none
        チェックを行いません。

    stkovf
        単一スレッドプログラムにはメインスレッドのスタックオーバーフローの実行時チェックを、マルチスレッドプログラムにはスレーブスレッドのスタックオーバーフローの実行時チェックを行います。スタックオーバーフローが検出されると、SIGSEGV 障害が発生します。アプリケーションが、スタックオーバーフローが原因で発生した SIGSEGV を他のアドレス空間違反の処理とは異なる方法で処理する必要がある場合は、sigaltstack(2) を参照してください。

    no%stkovf
        スタックオーバーフローチェックを無効にします。

    相互の関連性:

    -xcheck を引数なしで指定すると、コンパイラはデフォルトで -xcheck=%none を設定します。

-xchip=c
    オプティマイザを使用するターゲットとなるプロセッサを指定します。

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

    ターゲットとなるプロセッサを指定することによって、タイミング属性を指定します。

    このオプションは、次の内容に影響を与えます。

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

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

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

    以下に SPARC プラットフォームに適用される -xchip の値を示します。

    値   意味

    generic
        SPARC プロセッサ上で良好なパフォーマンスを得るための、タイミング属性を使用します。

        ほとんどの SPARC 上で良好なパフォーマンスが得られ、どのプロセッサ上でも パフォーマンスが低下することがないような、タイミング属性を使用するように コンパイラに指示する、デフォルトの値です。

    native
        ホストの環境で最高のパフォーマンスを得る ためのパラメータを設定します。

    old 旧 SuperSPARC(TM) プロセッサのタイミング属性を使用します。

    super
        SuperSPARC プロセッサのタイミング属性を使用します。

    super2
        SuperSPARC II プロセッサのタイミング属性を使用します。

    micro
        MicroSPARC (TM) プロセッサのタイミング属性を使用します。

    micro2
        MicroSPARC II プロセッサのタイミング属性を使用します。

    hyper
        HyperSPARC (TM) プロセッサのタイミング属性を使用します。

    hyper2
        HyperSPARC II プロセッサのタイミング属性を使用します。

    powerup
        Weitek PowerUp プロセッサのタイミング属性を使用します。

    ultra
        UltraSPARC プロセッサのタイミング属性を使用します。

    ultra2
        UltraSPARC II プロセッサのタイミング属性を使用します。

    ultra2e
        UltraSPARC IIe プロセッサのタイミング属性を使用します。

    ultra2i
        UltraSPARC IIi プロセッサのタイミング属性を使用します。

    ultra3
        UltraSPARC III プロセッサのタイミング属性を使用します。

    IA プラットフォーム用の -xchip の値:

    値   意味

    generic
        ほとんどの IA プロセッサ上で良好なパフォーマンスを得るためのタイミング属性を使用します。

    386 Intel 386 プロセッサのタイミング属性を使用します。

    486 Intel 486 プロセッサのタイミング属性を使用します。

    pentium
        Intel Pentium プロセッサのタイミング属性を使用します。

    pentium_pro
        Intel Pentium Pro プロセッサの属性を使用します。

-xcode=a
    (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 乗) バイトに制限されます。

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

    abs64
        SPARC: 低速で範囲の限定されない 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|v9b}) ) では、デフォルトは -xcode=abs64 です。

    警告:

    単独のステップでコンパイルおよびリンクを行った場合、コンパイルステップとリンクステップと同じ -xarch オプションを使用する必要があります。

-xcrossfile[=n]
    (SPARC プラットフォーム) ソースファイル間の最適化とインライン化を有効にします。-xcrossfile は、コンパイル時に有効となり、各コンパイル時にコマンドで指定されたファイルのみに作用します。例として以下のコマンド行での動作を説明します。

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

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

    値:

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

    値   意味

    0   ソースファイル間の最適化とインライン化を実行しません。

    1   ソースファイル間の最適化とインライン化を実行します。

    通常、コンパイラの解析の範囲は、コマンド行上の各ファイルに 制限されます。たとえば、 -xO4 オプションを指定した場合、自動インライン化は同じ ソースファイル内で定義および参照されるサブプログラムに制限されます。 -xcrossfile または -xcrossfile=1 を指定した場合、コマンド行上のすべてのファイルが単一のソース ファイルに連結されたかのように解析されます。

    デフォルト:

    -xcrossfile を指定しない場合、 -xcrossfile=0 が仮定され、ソースファイル間の最適化とインライン化は実行されません。 -xcrossfile は -xcrossfile=1 と同義です。

    相互の関連性:

    -xcrossfile オプションは、 -xO4 または -xO5と一緒に使用したときだけ有効です。

    警告:

    インライン化の可能性があるため、このコンパイルから生成されたファイル は相互に依存します。したがって、プログラムにリンクするときは、 1 つのユニットとして使用する必要があります。あるルーチンを変更し、 ファイルを再コンパイルする場合、すべてのファイルを再コンパイル する必要があります。結果として、このオプションを使用すると、 makefile の構造に影響を与えます。

    関連項目:

    -xldscope

-xdumpmacros[=value[,value...]]
    プログラム中でのマクロの動きを確認したい場合に、このオプションを 使用します。定義済みマクロ、解除済みマクロ、実際の使用状況といった 情報が得られます。結果は、マクロの処理順に基づいて 標準エラー (stderr) に出力されます。 -xdumpmacros オプションは、ファイルの終わりまで、あるいは dumpmacros か end_dumpmacrosoption のプラグマによって 上書きされるまで、有効です。

    値:

    値   意味

    [no%]defs
        すべての定義済みマクロを出力します[しません]。

    [no%]undefs
        すべての解除済みマクロを出力します[しません]

    [no%]use
        使用されているマクロの情報を出力します[しません]

    [no%]loc
        定義済み、解除済みのもの、使用されているものについて、場所 (パス名と行番号) を出力します

    [no%]conds
        条件付き指令で使用されているマクロの使用情報を出力します[しません]。

    [no%]sys
        システムヘッダーファイルのマクロについて、すべての定義済みマクロ、 解除済みマクロ、使用情報を出力します[しません] 。

    %all
        このオプションを -xdumpmacros=defs,undefs,use,loc,conds,sys に設定します。 この引数の効果的な使い方は、その他の引数の [no%] 形とともに使うことです。たとえば -xdumpmacros=%all,no%sys は 出力からヘッダーマクロを排除しますが、その他のマクロについては 情報を提供します。

    %none
        マクロ情報はまったく出力しません。

    このオプションの値は追加されていきます。したがって -xdumpmacros=sys -xdumpmacros=undefs を指定すると -xdumpmacros=undefs,sys と同じことになります。

    注: サブオプション loc、conds、sys は defs、undefs、use の各オプションの 修飾子と同じです。loc、conds、sys は それだけでは効果はありません。たとえば、 -xdumpmacros=loc,conds,sys には効果はありません。

    デフォルト:

    引数を付けずに -xdumpmacros を指定すると、それは -xdumpmacros=defs,undefs,sys という意味になります。 -xdumpmacros を指定しない場合、デフォルトは
     -xdumpmacros=%none となります。

-xe 構文と意味のエラーだけをチェックします。 -xe と指定すると、コンパイラはオブジェクトコードを作成しません。 -xe の出力は、直接 stderr ファイルに送られます。

    コンパイルで作成されるオブジェクトファイルが必要でない場合は、 -xe オプションを使用します。 たとえば、コードの部分部分を削除しながらエラーメッセージの原因を 特定しようとしている場合、-xe を使えば編集とコンパイルの サイクルをより早くできます。

-xF -xF オプションは、リンカーによる関数と変数の最適な順序の並べ替えを有効にします。

    このオプションは、コンパイラに対して関数、データ変数を細分化された 別々のセクションに配置するよう指示し、それによってリンカーが、 リンカーの -M オプションで指定されたマップファイル内の 指示を使って、プログラムのパフォーマンスが最適化されるように これらのセクションを整理します。 一般にこの最適化は、ページフォルト時間がプログラム実行時間の 大半を占める場合にのみ効果があります。

    最適なパフォーマンスを目指す関数および変数の整理には、以下の 操作が必要です。

    1. -xF でコンパイル、リンクします。

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

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

    4. アナライザの下で再度実行して、改善を確認します。

    値:

    v は次のいずれかの値になります。

    値   意味

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

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

    [no%]lcldata
        局所データ (内部リンケージのある変数) を別々のセクションに 細分化します[しません]。

    %all
        関数、大域的なデータ、局所データを断片化します。

    %none
        何も断片化しません。

    デフォルト:

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

    相互の関連性:

    -xF=lcldata を使用すると、一部のアドレス計算の最適化が 禁止されるので、このフラグは実験結果が妥当である場合にのみ 使用するようにしてください。

    関連項目:

    analyzer(1)、 debugger(1)、 ld(1)

-xhelp=flags
    各コンパイラのフラグについて簡単な説明を表示します。

-xhelp=readme
    README オンライン ファイルの内容を表示します。 README ファイルのページング には、環境変数 PAGER で指定されているコマンドが使用されます。 PAGER が設定されていない場合、デフォルトのページングコマンド more が使用されます。

-xia
    (SPARC プラットフォーム) 適切な区間演算ライブラリとリンクして、 必要な浮動小数点環境を設定します。

    -xia オプションは、以下のように展開されるマクロです。
    -fsimple=0 -ftrap=%none -fns=no -library=interval

    相互の関連性:

    区間演算ライブラリを使用するには、 <suninterval.h>をインクルードしてください。

    区間演算ライブラリを使用する場合は、 libC、 Cstd、 iostreams のいずれかのライブラリが必要です。 上記のライブラリを組み込む方法については、 -library オプションの説明を参照してください。

    警告:

    区間演算を使用する場合、 -fsimple、 -ftrap、 -fns のいずれかに、それとは異なる値を指定すると、 プログラムが誤った動作をすることがあります。

    C++ 区間演算は実験的で発展途上にある機能です。 そのため、個々の内容はリリースごとに変化する可能性があります。

    関連項目:

    『C++IntervalArithmeticProgrammingReference』、
    『Interval Arithmetic Solves Nonlinear Problems While Providing Guaranteed Results』 (http://www.sun.com/software/sundev/news/features/intervals.html), -library

-xildoff
    インクリメンタルリンカーを使用しません。

    -g オプションを使用しない場合は、このオプションが仮定されます。 また、 -G オプションを使用しているか、 コマンド行にソースファイルの名前を指定している場合も、 このオプションが仮定されます。
    -xildon オプションを使用すると、 -xildoff オプションは無効になります。

-xildon
    インクリメンタルリンカーを起動します。 -g オプションを使用し、 -G オプションを使用せず、かつ、コマンド行にソースファイルの名前を指定しない場合は、 このオプションがデフォルトです。このデフォルトを使用したくない場合は、 -xildoff オプションを指定してください。

-xinline[=func_spec[,func_spec...]]
    -xO3 またはそれ以上で、ユーザーが記述したルーチンの中でオプティマイザによりインライン化できるものを指定します。

    値:

    func_spec は次のいずれかの値です。

    値   意味

    %auto
        最適化レベル -xO4 またはそれ以上において自動インライン化を有効にします。 この引数はオプティマイザに対し、選択した関数をインライン化できることを通達します。 %auto を指定しないと、-xinline=[no%]func_name によりコマンド行に明示的インライン化が指定された場合に、通常は自動インライン化が無効になることに注意してください。

    func_name
        オプティマイザによる関数のインライン化を強く必要とします。関数が、外部関数 "C" として宣言されていない場合、func_name の値は符号化する必要があります。実行可能ファイルの nm コマンドを使用して、符号化された関数名を検索することができます。外部関数 "C" として宣言された関数名は、コンパイラにより符号化されません。

    no%func_name
        リストのルーチン名の前に no% をつけると、そのルーチンのインライン化は抑止されます。 func_name に対する符号化名に関する規則は、同様に no%func_name に適用されます。
    コンパイルされたファイルのルーチンのみが、-xcrossfile[=1] を使用していない限り、インライン化されたものと考えられます。オプティマイザは、これらのルーチンの中でインライン化に適切なものを決定します。

    デフォルト:

    -xinline オプションが指定されていない場合、コンパイラは -xinline=%auto を仮定します。 -xinline= が引数なしで指定された場合、最適化レベルに関わらず、関数はインライン化されません。

    例:

    int foo() で宣言された関数のインライン化を無効にする際に、自動インライン化を有効にします。

    example% CC -xO5 -xinline=%auto,no%__1cDfoo6F_i_ -c a.cc を使用してください。

    int foo() として宣言された関数のインライン化を強く必要とし、その他のすべての関数をインライン化の候補にするため、

    example% CC -xO5 -xinline=%auto, __1cDfoo6F_i_ -c a.cc を使用してください。

    int foo() として宣言される関数のインライン化を強く必要とし、その他の関数のインライン化を許可しないために、

    example% CC -xO5 -xinline=__1cDfoo6F_i_ -c a.cc を使用してください。

    相互の関連性:

    -xinline オプションは -xO3 の下の最適化レベルには影響しません。 -xO4 およびそれ以上では、オプティマイザはインライン化が必要な関数を決定します。-xinline が指定されていない場合も同様です。-xO4 またはそれ以上では、コンパイラは、インライン化されている場合にパフォーマンスを改善する関数を決定しようとします。

    以下の条件のいずれかが適用される場合は、ルーチンはインライン化されません。警告は省略されません。

        o   最適化は -xO3 以下です。

        o   ルーチンが見つかりません。

        o   インライン化は有益または安全ではありません。

        o   コンパイルされたファイルにソースが存在しません。または、-xcrossfile[=1] を使用した場合、コマンド行で指定されたファイルにソースが存在しません。

        警告:

        -xinline で関数のインライン化を行った場合、実際にパフォーマンスが悪くなる可能性があります。

    関連項目:

    -xldscope

-xipo[={0|1}]
    (SPARC) 内部手続き最適化を実行します。

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

    -xipo オプションは大規模な複数ファイルのアプリケーションをコンパイルおよびリンクする際に特に有効です。このフラグでコンパイルされたオブジェクトファイルにはその中でコンパイルされた解析情報があり、ソースおよび事前コンパイルされたプログラムファイルの内部手続き解析ができるようになります。 しかし、解析と最適化は -xipo でコンパイルされたオブジェクトファイルに限定され、ライブラリのオブジェクトファイルに拡張しません。

    値:

    値   意味

    0   内部手続き最適化を実行しません。

    1   内部手続き最適化を実行します。

    2   内部手続き別名解析と、記憶域割り当ておよびレイアウトの最適化を実行して、キャッシュを改善します。
    デフォルト:

    -xipo が指定されない場合、-xipo=0 が仮定されます。

    -xipo が指定される場合、-xipo=1 が仮定されます。

    例:

    以下の例では同じ行でコンパイルとリンクを行っています。

    example% CC -xipo -xO4 -o prog part1.cc part2.cc part3.cc

    オプティマイザは 3 つのすべてのソースファイルのクロスファイルインライン化を実行します。 これはリンクの最終ステップで実行されるので、ソースファイルのコンパイルすべてが単一のコンパイルである必要はなく、それぞれが -xipo オプションを指定するコンパイルで終了する可能性があります。

    以下の例ではコンパイルとリンクを別々のステップで実行しています。

    example% CC -xipo -xO4 -c part1.cc part2.cc

    example% CC -xipo -xO4 -c part3.cc

    example% CC -xipo -xO4 -o prog part1.o part2.o part3.o

    コンパイルステップで生成されたオブジェクトファイルには、その中でコンパイルされた追加の解析情報があります。これにより、リンクステップで行うクロスファイル最適化を許可します。

    相互の関連性:

    -xipo オプションは少なくとも最適化レベル -xO4 を必要とします。 同じコンパイル行で -xipo オプションおよび -xcrossfile オプション両方を使用できません。

    警告:

    コンパイルおよびリンクが別々のステップで行う際には、両方のステップで -xipo を指定する必要があります。-xipo を指定しないでコンパイルしたオブジェクトは、-xipo でコンパイルしたオブジェクトに自由にリンクできます。以下の例で示すように -xipo でコンパイルされた場合でも、ライブラリは、クロスファイル内部手続き解析に加わりません。

    example% CC -xipo -xO4 one.cc two.cc three.cc

    example% CC -xar -o mylib.a one.o two.o three.o

    example% CC -xipo -xO4 -o myprog main.cc four.cc mylib.a

    この例では、内部手続き最適化は one.cc、two.cc と three.cc の間、および main.cc と four.cc の間で行われ、main.cc あるいは four.cc と mylib.a のルーチンの間では行われません。最初のコンパイルは、未定義のシンボルについて警告を生成しますが、内部手続き最適化は、コンパイルとリンクステップであるため、実行されます。

    -xipo オプションは、ファイルの最適化を実行するために必要な追加情報により、かなり大規模なオブジェクトファイルを生成します。しかし、この追加情報は最後の実行可能バイナリファイルの一部にはなりません。実行可能プログラムの大きさの増加は、追加された最適化によります。

-xjobs=n
    (SPARC) 複数のプロセッサでコンパイルします。

    -xjobs オプションを指定すると、コンパイラが処理を行うために 作成するプロセスの数を設定できます。このオプションによって、 マルチ CPU のマシンにおける構築時間を削減できます。現在は、 -xjobs は -xipo オプションとともにしか働きません。 -xjobs=n を指定した場合、内部手続きオプティマイザは、 複数のファイルをコンパイルするのために起動する、 コードジェネレータの最大数として n を使用します。

    一般に n の安全な値は利用可能なプロセッサ数の 1.5 倍です。 利用可能なプロセッサの数の何倍もの数を指定すると、生成された ジョブ間でのコンテキスト切り替えのオーバーヘッドが発生し、 パフォーマンスの低下につながります。また、値をあまり大きくすると、 スワップス空間などのシステム資源の限界を超過する可能性があります。

    -xjobs は必ず値を指定して使います。値を指定しないと エラー診断が出て、コンパイルが異常終了します

    コマンド行で -xjobs を複数指定すると、 一番右以外の指定は無効になります。

    たとえば、2 つのプロセッサを搭載したシステムの場合、 次のコマンドは、-xjobs オプションを指定せずに実行した場合よりも 高速にコンパイルを行います。

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

-xlang=language[,language]
    適切な実行時ライブラリをインクルードして、 指定された言語のための正しい実行時環境が確実に設定 されるようにします。

    language には、 f77、 f90、 f95 のいずれかを指定します。

    引数 -f90 と -f95 は同義です。

    相互の関連性:

    -xlang=f90 オプション指定には -library=f90 が、 -xlang=f77 オプション指定には -library=f77 が、それぞれ暗黙的に含まれています。 ただし、複数の言語を同時にリンクする場合は、 -library=f77 オプションおよび -library=f90 オプションだけでは十分ではありません。 正しい実行時環境の確実な設定は、 -xlang オプションでしか行えません。

    複合言語のリンクに使用するドライバを決定するには、以下の言語階層を使用してください。

    1. C++

    2. Fortran 95 (or Fortran 90)

    3. Fortran 77

    4. C または C99

    Fortran 95、Fortran 77、および C++ オブジェクトファイルを一緒にリンクする場合は、最上位の言語のドライバを使用してください。例えば、C++ および Fortran 95 オブジェクトファイルをリンクするには、以下の C++ コンパイラコマンドを使用してください。

    example% CC -xlang=f95...

    Fortran 95 および Fortran 77 オブジェクトファイルをリンクするには、以下のように、Fortan 95 ドライバを使用してください。

    example% f95 -xlang=f77...

    同じコンパイラコマンドでは、-xlang オプションと -xlic_lib オプションは使用できません。 -xlang を使用していて、Sun Performance Library にリンクする 必要がある場合は、代わりに -library=sunperf を使用してください。

    警告:

    -xnolib は、 -xlang とは一緒に使用しないでください。

    並列 Fortran オブジェクトと C++ オブジェクトを混在させる場合は、 リンク行に -mt フラグを指定しなければなりません。

    関連項目:

    -library、 -staticlib

-xldscope={v}
    外部シンボル定義のためのデフォルトのリンカースコープを変更します。 このデフォルトを変更することで実装がよりよく隠蔽され、 共用ライブラリをより高速かつ安全に使用できるようになります。

    値

    v は次のいずれかの値です。

    値   意味

    global
        シンボル定義は、最も限定的でないリンカースコープである 大域リンカースコープとなります。 シンボル参照はすべて、そのシンボルが定義されている最初の動的ロードモジュール における定義と結合します。外部シンボルのデフォルトのリンカースコープです。

    symbolic
        シンボル定義は、大域リンカースコープよりも限定的な シンボリックリンカースコープとなります。 リンクしようとする動的ロードモジュール内からのシンボル参照はすべて、 そのモジュール内で定義されたシンボルに結合します。 モジュール外については、シンボルは大域なものとなります。 このリンカースコープはリンカーオプション -Bsymbolic と 対応します。C++ ライブラリでは -Bsymbolic は使えませんが、 -xldscope=symbolic オプションは問題なく使えます。

    hidden
        隠蔽リンカースコープは、シンボリックや大域リンカースコープよりも 限定的です。動的ロードモジュール内の参照はすべて、 そのモジュール内の定義に結合します。 モジュールの外からはこのシンボルは見えません。

    デフォルト

    -xldscope を指定しない場合、コンパイラは -xldscope=global を仮定します。 値を付けずに -xldscope を使った場合は、 コンパイラでエラーとなります。 コマンド行にこのオプションのインスタンスを複数指定すると、 最も右側のインスタンスに達するまで、前のインスタンスが 上書きされていきます。

    警告

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

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

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

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

    __hidden または __symbolic 指定子で宣言した ライブラリ関数は、ライブラリ構築時にインライン生成される可能性が あります。これらがクライアントからオーバーライドされることは、サポート されていません。詳細については『C++ ユーザーズガイド』の 第 4 章「言語拡張」を参照してください。

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

    関連項目

    -xinline、-xO、-xcrossfile、ld(1)

-xlibmieee
    例外の場合、数学ルーチンに対して IEEE 745 値を返すように libm に指示します。 libm のデフォルトの動作は XPG 準拠です。

-xlibmil
    選択したライブラリルーチンを最適化用にインライン化します。

    一部の libm ライブラリルーチンには、インラインテンプレートがあります。このオプションは、 浮動小数点オプションと現在使用しているプラットフォームに対して、 最速の実行可能ファイルを生成するインラインテンプレートを選択します。

    注 — このオプションは、C++ インライン関数には影響しません。

-xlibmopt
    最適化された数学ルーチンのライブラリを使用します。

    最適化された数学ルーチンのライブラリを使用して、通常、より高速実行できる コードを生成します。通常の数学ライブラリを使用した場合と比べて、結果が 多少異なる場合があります。その場合は、通常、最終ビットが異なっています。

    このライブラリオプションを指定するときは、コマンド行での順序は関係ありません。

    相互の関連性:

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

    関連項目:

    -fast および -xnolibmopt の項も参照してください。

-xlic_lib=sunperf
    SPARC: Sun Performance Library とリンクします。

    この -l のようなオプションは、 ソースファイルおよびオブジェクトファイルの後のコマンド行の終わりに 置かれる必要があります。

    -library=sunperf オプションは Sun Performance Library のリンクに推奨します。このオプションにより、ライブラリが正しい順序でリンクされることが保証されるからです。さらに、-library=sunperf オプションは位置に依存せず (コマンド行のどこにでも置くことができます)、-staticlib を使用して Sun Performance Library に静的にリンクできます。-staticlib オプションは、-Bstatic -xlic_lib=sunperf -Bdynamic の組み合わせよりも便利です。

    相互の関連性:

    同じコンパイラコマンドで -xlang オプションと -xlic_lib オプションは使用できません。-xlang を使用していて、Sun Performance Library にリンクする必要がある場合は、かわりに -library=sunperf を使用してください。

    同じコンパイラコマンドで -library=sunperf と -xlic_lib=sunperf は使用できません。

    Sun Performance Library に静的にリンクするには、以下の例で示すように、-library=sunperf および -staticlib=sunperf オプションを使用することをお勧めします。

    example% CC -library=sunperf -staticlib=sunperf ...

    -library=sunperf のかわりに -xlic_lib=sunperf オプションを使用することを選択した場合は、以下の例で示すように -Bstatic オプションを使用してください。

    example% CC ... -Bstatic -xlic_lib=sunperf -Bdynamic ...

    関連項目:

    -staticlib

-xlicinfo
    ライセンスサーバー情報を表示します。

    このオプションは、ライセンスサーバー名と、ライセンスを所持する ユーザーのユーザー ID を返します。

-xlinkopt[=level]
    (SPARC) 再配置可能オブジェクトファイルに対してリンク時に最適化を実行します。

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

    最適化のレベルは以下のとおりです。

    0   ポストオプティマイザは無効です (これはデフォルトです)。

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

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

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

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

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

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

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

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

    リンクオプティマイザはインクリメンタルリンカー ild とともに 使うことはできません。 -xlinkopt はデフォルトのリンカーを ld に設定します。 インクリメンタルリンカーを -xildon で明示的に有効にすると、 両方が指定された場合に -xlinkopt が無効になります。

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

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

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

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

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

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

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

-Xm -features=iddollar を使用してください。

-xM 指定の C++ プログラムでプリプロセッサのみを実行し、 メークファイル依存を生成し、その結果を標準出力に送るよう要求します。 (メークファイルおよび依存性については make (1) を 参照してください)。

    関連項目:

    -xM1

    メークファイルおよび依存関係についての詳細は、 make(1) のマニュアルページを参照してください。

-xM1
    -xM とほぼ同じですが、 /usr/include のヘッダーファイルに関する依存関係は出力しません。このオプションは、コンパイラが提供するヘッダーファイルの依存関係を報告しません。

-xMerge
    (SPARC プラットフォーム)データセグメントをテキストセグメント と併合 (マージ) します。

    オブジェクトファイルのデータは読み取り専用です。このデータは、 ld -N を指定してリンクしない限り、プロセス間で共有されます。

-xmemalign[=ab]
    想定される最大のメモリ整列と、誤って整列されたデータがアクセスされたときの動作を 指定します。

    コンパイル時に整列が確定できるメモリアクセスの場合、 コンパイラがデータのその整列に対して、 適切なロード / ストア命令の並びを生成します。

    コンパイル時に整列が確定できないメモリアクセスの場合、 コンパイラは整列を想定して、必要なロード / ストア命令の並びを 生成しなければなりません。

    -xmemalign フラグを使用して、このような確定できない状況において コンパイラが想定するデータの最大メモリ整列を指定します。 また、誤って整列されたメモリのアクセスが発生したときに、 実行時に続いて行なうエラー処理を指定することができます。

    値:

    a に対して指定可能な値は次のとおりです。

        1   最大 1 バイトの整列を仮定します。

        2   最大 2 バイトの整列を仮定します。

        4   最大 4 バイトの整列を仮定します。

        8   最大 8 バイトの整列を仮定します。

        16  最大 16 バイトの整列を仮定します。

    b に対して指定可能な値は次のとおりです。

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

        s   シグナル SIGBUS を出します。

        f   4 以下の整列の場合はシグナル SIGBUS を出します。 その他の場合はアクセスを解釈して実行を継続します。

    デフォルト:

    -xmemalign フラグが指定されない場合のデフォルトは次のとおりです。

        -xmemalign=4s ( -xarch=generic,v7,v8,v8a, v8plus,v8plusa の場合)

        -xmemalign=8s ( -xarch=v9,v9a の場合)

    -xememalign が値を指定せずに使われた場合のデフォルトは次のとおりです。

        -xmemalign=1i (すべてのプラットフォーム)

-xnativeconnect [=n]
    ネイティブコネクタツール (NCT) 用のコンパイルを可能にします。

    インタフェース情報をオブジェクトファイルと後続の共用ライブラリに埋め込み、共用ライブラリが Java を変換して認識できるようにするには、-xnativeconnect オプションを使用します。CC -G を使用して共用ライブラリを構築する場合も、-xnativeconnect を含める必要があります。

    -xnativeconnect を使用してコンパイルする場合、ネイティブコードインタフェースの最大外部可視性を指定します。NCT を使用すると、Java コードと JNI コードの自動生成が可能になります。 NCT と -xnativeconnect をともに使用することで、 C++ 共用ライブラリの関数を Java コードから呼び出せるようになります。 NCT の使用方法の詳細については、オンラインヘルプを参照してください。

    このオプションは累積されません。コンパイラは、最後に指定された設定を使用します。たとえば、CC -xnativeconnect=inlines first.o -xnativeconnect=interfaces second.o -O -G -o library.so を指定すると、コンパイラはこのオプションを -xnativeconnect=no%inlines,interfaces に設定します。

    -g と -xnativeconnect を両方使用したときコンパイルが実行されない場合、-g オプションを使用せずにコンパイルしてみてください。

    デフォルト:

    n は、[{%all|%none}][,][[no%]inlines][,][[no%]interfaces]] です。

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

    o -xnativeconnect

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

    o -xnativeconnect=inlines

        -xnativeconnect=inlines コマンドは、参照されたインライン関数の行外のインスタンスを強制的に生成します。ネイティブコネクタの一部として生成された外部関数をこれらの行外のインスタンスに結合できます。すべての呼び出しサイトにおけるこれらの関数の通常のインライン化は、影響を受けません。

    o -xnativeconnect=intefraces

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

    注意:

    -xnativeconnect を使用する場合、-compat=4 を使用してコンパイルしないでください。引数なしで -compat を指定すると、コンパイラはこのオプションを -compat=4 に設定することを覚えておいてください。-compat を指定しないと、コンパイラはこのオプションを -compat=5 に設定します。また -compat=5 を出力して、明示的に互換モードを設定できます。

-xnolib
    デフォルトのシステムライブラリとのリンクを無効にします。

    通常、C++ コンパイラは、C++ プログラムをサポートするために、 一部のシステムライブラリとリンクします。このオプションを指定すると、 デフォルトのシステムサポートライブラリとリンクするための -llib オプションは ld に渡されません。

    通常 (このオプションを指定しないで)、C++ コンパイラはいくつかのシステムサポートライブラリにリンクして、C++プログラムをサポートします。このオプションを指定すると、デフォルトのシステムサポートライブラリをリンクするための -llib オプションは ld に渡されません。

    通常、コンパイラは以下の順序でシステムサポートライブラリにリンクします。

    o   標準モード (デフォルトモード):

        -lCstd -lCrun -lm -lw -lcx -lc

    o   互換モード (-compat[=4]):

        -lC -lm -lw -lcx -lc

    -l オプションの順序は重要です。-lc 以前に -lm、-lw、および -lcx オプションが指定される必要があります。

    注 — -mt オプションを指定する場合はコンパイラは通常、-lm とリンクする以前に -lthread とリンクします。

    デフォルトでリンクされるシステムサポートライブラリを決定するには、-dryrun オプションでコンパイルしてください。例えば、以下のコマンドからの出力です。

    example% CC foo.cc -xarch=v9 -dryrun

    出力に以下を含んでいます。

    -lCstd -lCrun -lm -lw -lc

    -xarch=v9 が指定された場合、-lcx はリンクされません。

    例:

    C アプリケーションライブラリインタフェース (つまり必要な C のサポートだけを 組み込んだ C++ プログラム) に合わせるためのコンパイル処理が最小限で済むように、 次のコードを使用します。

    example% CC -xnolib test.cc -lc

    汎用命令セットでシングルスレッドアプリケーションに libm を静的にリンクするには、次のコマンドを使用します。

    o   標準モード:

        example% CC -xnolib test.cc -lCstd -lCrun -Bstatic -lm -Bdynamic -lw -lcx -lc

    o   互換モード:

        example% CC -compat -xnolib test.cc -lc -Bstatic -lm -Bdynamic -lw -lcx -lc

    相互の関連性:

    libm.a および libc.a などの静的システムライブラリは、-xarch=v9、-xarch=v9a または -xarch=v9b でリンクされる場合は有効ではありません。

    -xnolib を指定する場合、すべての必要なシステムサポートライブラリを特定の順番で 手動でリンクしなければなりません。システムサポートライブラリは最後に リンクしなければなりません。

    -xnolib が指定されると、 -library は無視されます。

    警告:

    C++ 言語の多くの機能を使用するには、 libC (互換モード) または libCrun (標準モード) を使用する必要があります。

    システムサポートライブラリのセットは安定していないため、今後のリリースで変更される可能性があります。

    -lcx は、64 ビットコンパイルモードではサポートされていません。

-xnolibmil
    コマンド行の -xlibmil を取り消します。

    このオプションを -fast と併用すると、最適化された数学ライブラリとのリンクを無効にします。

-xnolibmopt
    最適化された数学ライブラリを使用しないようにします。

    相互の関連性:

    このオプションは、コマンド行で -fast オプションを指定した後に使用してください。例を示します。

    example% CC -fast -xnolibmopt ...

-xOn
    最適化レベル (n) を指定します (大文字の O の後に、数字の 1、2、3、4、5 の いずれかを指定します)。

    デフォルトでは最適化は行われません。ただし、このデフォルトは 最適化レベルを指定しない場合にのみ当てはまります。 最適化レベルを指定した場合には、最適化を無効にするオプションは ありません。

    最適化レベルを設定しないようにするには、最適化レベルを暗に 意味するようなオプションはどれも指定しないようしてください。 たとえば -fast は -xO5 に最適化レベルを設定する マクロオプションです。最適化レベルを暗に意味するその他のオプションも すべて、最適化が設定されたという警告メッセージを出します。 最適化をまったく行なわないでコンパイルする方法は、 コマンド行からすべてのオプションを削除するか、最適化レベルを 指定するファイルを作成することだけです。

    一般的に、プログラムをコンパイルする際の最適化のレベルが上がるほど、 実行時のパフォーマンスも上がります。しかし、最適化レベルが上がるほど、 コンパイル時間と実行可能ファイルのサイズは増えます。

    -xOn に指定できるレベルは 5 つあります。次の節では、SPARC プラットフォーム、 IA プラットフォーム、 およびその他の各プラットフォームの場合での各レベルの違いを説明します。

    値:

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

    メモリーが不足した場合、オプティマイザはもう一度より低いレベルの最適化で 処理しようとし、その後のルーチンのコンパイルを元のレベルで再開します。

    -xO1
        最小の最適化 (ピープホール) だけを行います。

    -xO2
        基本的な局所的および大域的な最適化を行います。このレベルには、 帰納変数の削除、 局所的および大域的な共通の式の一部の削除、 代数の簡約化、 コピーの伝播、 定数の伝播、 ループ不変式の最適化、 レジスタの割り当て、 基本的なブロックのマージ、 末尾再帰の削除、 デッドコードの削除、 末尾呼び出しの削除、 および複雑な数式の展開が含まれます。

        このレベルでは、外部変数または間接変数の参照または定義は最適化されません。 一般的に、このレベルでは、コードのサイズが最小になります。

        -O と -xO2 は同じです。

    -xO3
        -xO2 レベルで実行する最適化に加え、外部変数に対する参照と定義も最適化します。 このレベルでは、ポインタ割り当ての影響は追跡されません。 volatile により適切に保護されないデバイスドライバ、または、シグナルハンドラの内部から 外部変数を変更するプログラムをコンパイルするときには、 -xO2 を使用します。

        一般的に、 -xO3 では、コードのサイズが増えます。 スワップ領域が不足している場合は、 -xO2 を使用してください。

    -xO4
        -xO3 レベルで行われる最適化に加え、同じファイルに含まれる関数の 自動インライン化も行います。この自動インライン化は、通常、実行速度を上げますが、 その逆の結果になる場合もあります。一般的に、このレベルでは、 コードのサイズが増えます。

    -xO5
        最高レベルの最適化を行います。コンピュータ時間の大部分を使用する、 プログラムのごく一部だけに適しています。より多くのコンパイル時間を要するか、 実行時間を改善する確実性が低い最適化アルゴリズムを使用します。 このレベルの最適化は、プロファイルのフィードバックと併用すると、 パフォーマンスが上がる確率が高まります。-xprofile を参照してください。

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

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

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

        -O と -xO2 は同義です。

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

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

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

    相互の関連性:

    -g または -g0 を使用するとき、最適化レベルが -xO3 以下の場合、最大限のシンボリック情報とほとんど完全な最適化が 得られます。末尾呼び出しの最適化とバックエンドインライン化は無効です。

    -g または -g0 を使用するとき、最適化レベルが -xO4 以上の場合、最大限のシンボリック情報と完全な最適化が得られます。

    でデバッグしても、 -xOlevel は抑止されません。しかし、 -xOlevel は、 -g をある程度制限します。たとえば、 -xOlevel オプションを使用すると dbx からの変数が表示できなくなるために、デバッグがやりづらくなります。それでも、 dbx の where コマンドを使用すれば、シンボルによる追跡は行えます。 詳細は、『dbx コマンドによるデバッグ』を参照してください。

    -xcrossfile オプションは、 -xO4 または -xO5 と一緒に使用したときだけ有効です。

    -xinline オプションは、-xO3 の下の最適化レベルに影響しません。-xO4 において、オプティマイザによりインライン化される関数が決定されます。これは、-xinline オプションの指定に関わらず行われます。-xO4 において、コンパイラは、インライン化された関数でパフォーマンスを改善するものを決定しようとします。-xinline で関数のインライン化を行う場合は、実際にパフォーマンスが悪くなる可能性があります。

    警告:

    一つの手続きの中に何千ものコードが存在する非常に大きな手続きで -xO3 または -xO4 で最適化を行う場合、オプティマイザは莫大な量のメモリーを要求します。マシンのパフォーマンスが悪くなる場合もあります。

    このパフォーマンス低下を避けるために、単一のプロセスで使用できる仮想メモリーの量を制限するために limit コマンドを使用します (csh(1) のマニュアルページを参照)。例えば、仮想メモリーを 16 メガバイトに制限するには、以下のように指定します。

    example% limit datasize 16M

    このコマンドにより、オプティマイザは、データ空間が 16 メガバイトに達した場合に回復しようとします。

    制限は、マシンで使用可能なスワップ空間全体より大きくなることはありません。大規模なコンパイルが行われている間にマシンが通常に使用できる程度に小さくする必要があります。

    最適なデータのサイズは、必要とされる最適化の程度、実メモリーの量、使用できる仮想メモリーによります。

    実際のスワップ空間を検索するには、swap -1 と入力します。

    実際の実メモリーを検索するには、dmesg | grep mem と入力します。

    関連項目:

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

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

-xopenmp [= i]
    (SPARC) -xopenmp オプションを使用すると、OpenMP 指令との 明示的並列化が可能になります。

    値

    i は parallel、stubs、または none のいずれかです。

    o -xopenmp=parallel

        -xopenmp だけを指定した場合、コンパイラは このオプションを -xopenmp=parallel に設定します。-xopenmp=parallel は OpenMP プラグマを認識します。これは SPARC のみに適用されます。-xopenmp=parallel での最適化レベルは、-xO3です。プログラムの最適化レベルがより低いレベルから -xO3 に変更された場合、コンパイラは警告を出力します。

    o -xopenmp=stubs

        -xopenmp=stubs コマンドは、OpenMP API ルーチン用にスタブルーチンとリンクします。連続して実行するためにアプリケーションをコンパイルする必要がある場合は、このオプションを使用してください。-xopenmp=stubs コマンドは、_OPENMP プリプロセッサトークンも定義します。

    o -xopenmp=none

        -xopenmp=none コマンドは、OpenMP プラグマの認識を有効にしません。プログラムの最適化レベルは変更されず、プリプロセッサトークンも事前定義されません。

    デフォルト

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

    -xopenmp を指定してこれに引数をつけなかった場合、 コンパイラは -xopenmp=parallel と設定します。

    警告

    コンパイルとリンクを別々のステップで実行する場合、リンクのステップにも -xopenmp を指定してください。 これはとくに OpenMP 指令を含むライブラリをコンパイルするときに 重要です。

    既知の制限

    以下のリストは、C++ コンパイラでの OpenMP 機能の既知の制限の詳細です。

    o 入れ子の並列化のサポートなし

        C++ コンパイラは、OpenMP 2.0 ドラフト標準に定義された入れ子の 並列化をサポートしません。

    o ループインデックス修正のチェックなし

        コンパイラは、ループインデックス用の OpenMP がループ本体の中で修正されていないかどうか確認しません。

    o チャンクサイズのチェックなし

        コンパイラは、実行時の障害が原因で発生するゼロ値や負の値のチェックをコンパイル時に実行しません。

    o 短縮文節に使用されている過負荷演算子のチェックなし

        コンパイラは、縮約文節に引数として使用される演算子が多重定義されているかどうかを検出しません。

    o 現在再検討中のエラーメッセージテキスト

        OpenMP エラーメッセージシステムは再検討中です。メッセージの中には、不正確であったり無用のものもあります。

-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 を指定すると、Solaris オペレーティング環境が ページサイズを設定します。 -xpagesize に引数を指定しない場合、 -xpagesize=default と同じことになります。

    このオプションは -xpagesize_heap および -xpagesize_stack のためのマクロです。この 2 つのオプションは -xpagesize と同じく 8K、64K、512K、4M、 32M、256M、2G、16G、default を 引数として受け付けます。 -xpagesize=n と指定して上記の 2 つのオプションに 同じ値を設定することができ、あるいはこれらを別々に指定して異なる 値に設定することも可能です。

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

-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 と同じ意味になります。

    このオプションを使ってコンパイルすることは、 mpss.so.1 への 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 と同じ意味になります。

    このオプションを使用してコンパイルすることは、 mpss.so.1 への 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 参照)と併せて 使うことにより、この機能の利点を得ることができます。

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

    有効なプリコンパイル済みヘッダーファイルの名前には必ず接尾辞 .Cpch が付いて います。pch_filename を指定するときには自分でこの接尾辞を 付けるか、コンパイラに付けてもらいます。たとえば、 CC -xpch=collect:foo a.cc と指定すると、プリコンパイル済みヘッダーファイルは、 foo.Cpch という名前になります。

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

    既存のプリコンパイル済みヘッダーファイルは、以下のことが当てはまるとき のみ使用するようにします。もしも次のいずれかが 当てはまらない場合には、プリコンパイル済みヘッダーファイルを 再作成したほうがよいでしょう。

    o プリコンパイル済みヘッダーファイルのアクセスに使用するコンパイラが、 プリコンパイル済みヘッダーファイルを作成したコンパイラと同じ。 あるバージョンで作成されたプリコンパイル済みヘッダーファイルが、 パッチのインストールによる違いも含めてそのコンパイラの別のバージョンで 利用できるとは限りません。

    o -xpch オプションを除いて、-xpch=use で指定する コンパイラオプションは、プリコンパイル済みヘッダーファイルを作成したときの 指定と合っている必要があります。

    o -xpch=use で指定するインクルードヘッダーが、 プリコンパイル済みヘッダー作成時に指定した一連のヘッダーと同じ。

    o -xpch=use で指定するインクルードヘッダーの中身が プリコンパイル済みヘッダー作成時に指定されたインクルードヘッダーの 中身と同じ。

    o 現在のディレクトリ (つまり、コンパイルが行なわれていて、所定の プリコンパイル済みヘッダーファイルを使用しようとしているディレクトリ) が、プリコンパイル済みヘッダーファイルが作成されたディレクトリと 同じ。

    o -xpch=collect で指定したファイルにあった、 #include 指令を含む最初のプリプロセス指令の並びが、 -xpch=use で指定するファイルにあるプリプロセス指令の並びと 同じ。

    活性文字列 (viable prefix)
    プリコンパイル済みヘッダーファイルを複数のソース間で共用するために、 これらのソースファイルには最初のトークンの並びとして 一連の同じインクルードファイルを使用していなければなりません。 この最初のトークンの並びは活性文字列として知られています。 活性文字列は、同じプリコンパイル済みヘッダーファイルを使用する ソースファイルすべてで一貫したものとして解釈されなければなりません。 活性文字列は、各ソースファイルの最初のトークンで始まり、#pragma hdrstop か、-xpchstop オプションで指定された ヘッダーファイルの #include 指令の最後のトークンで終わります。

    ソースファイルの活性文字列は、コメントと以下のいずれかの プリプロセッサ指令からのみ構成されます。

    #include #if/ifdef/ifndef/else/elif/endif
    #define/undef
    #ident (もしも同じならば、そのまま続けられます)
    #pragma (同じ場合)

    これらはいずれもマクロを参照できます。 #else、#elif、#endif 指令は 活性文字列の中で合致するものでなければなりません。

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

    プリコンパイル済みヘッダーファイルに組み込まれるヘッダーファイルは、 次の制約に違反してはなりません。これらの制約のいずれかに違反する プラグマをコンパイルした場合、その結果は予測できません。

    o ヘッダーファイルは完全な宣言のみを含む。つまり、 どのファイルの宣言、C++ 名前空間、C++ リンケージ宣言も、 有効な宣言として独立していなければなりません。 struct S; といった不完全な型宣言はそれ自体は、 有効な宣言です。 完全な型宣言は別のファイルでも指定できます。 C++ の名前空間やリンケージ宣言は別のファイルで再オープンしたり 拡張したりできます。

    o ヘッダーファイルにはインライン化されていなかったりテンプレート化 されていなかったりする関数を含まない。つまり、 すべての関数定義がインラインかテンプレートです。

    o 変数定義はすべて、マニフェスト定数初期設定子を伴う (暗黙の) 静的 const 変数に対する。

    o ヘッダーファイルでは __DATE__ および __TIME__ を 使用してはなりません。このプリプロセッサマクロを使用すると、 結果は予測できません。

    o ヘッダーファイルには #pragma hdrstop が含まれていては なりません。

    o ヘッダーファイルでは可延接頭辞に __LINE__ および __FILE__ を使用してはなりません。 インクルードヘッダーには __LINE__ と __FILE__ を使うことが許されています。

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

-xpchstop=file
    ここでの file は、プリコンパイル済みヘッダーファイルの作成時の 最後のインクルードファイルです。 コマンド行に -xpchstop を指定することは、 cc コマンドで指定したソースファイルのそれぞれで、 ファイルをインクルードする include 指定子 の後に、hdrstop プラグマ (-xhelp=readme を参照) を 置くのと同じことです。

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

-xpg
    gprof プロファイラによるプロファイル用にコンパイルします。

    -xpg オプションは自己プロファイルコードをコンパイルし、 gprof でのプロファイル用のデータを収集します。 このオプションは実行時記録メカニズムも持っており、プログラムが正常に終了すると、 gmon.out ファイルを生成します。

    この作業はパフォーマンスアナライザでも実行できます。 analyzer(1) のマニュアルページを参照してください。

    警告:

    コンパイルとリンクを別々に行う場合、コンパイル時に -xpg を使用したときは、リンク時にも -xpg を使用しなければなりません。

-xport64[=v]
    このオプションを使用すると、コードを 64 ビット環境に容易に移植できます。 具体的には、V7 などの 32 ビットアーキテクチャから V9 などの 64 ビットアーキテクチャにコードを移植するときによく見られる、 型 (ポインタを含む) の切り上げ、符号拡張、ビットパッキング といった問題をこのオプションが警告します。

    値:

    v は次のいずれかの値です。

    値   意味

    no  32 環境から 64 ビット環境へのコードの移植に関する警告を生成しません。

    implicit
        暗黙の変換に関する警告だけを生成します。明示的なキャストが存在する 場合には警告を生成しません。

    full
        32 ビット環境から 64 ビット環境へのコードの移植に関する警告をすべて 生成します。64 ビットの値の切り上げ、ISO の値保持の規則に基づいた 64 ビットへの符号拡張、ビットフィールドのパッキングの変更などが 含まれます。

    デフォルト:

    -xport64 を指定しない場合、デフォルトは -xport64=no に なります。-xport64 を指定して、フラグは指定しない場合、 デフォルトは -xport64=full となります。

    関連項目: -xarch

-xprefetch[=a[,a]]
    (SPARC プラットフォーム) UltraSPARC II (-xarch=v8plus、 v8plusa、v8plusb、v9、 v9a、v9bのいずれか) などの、先読み機能をサポートするアーキテクチャ上で 先読み命令を有効にして調整します。

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

    値   意味

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

    no%auto
        自動生成を無効にします。

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

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

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

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

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

    -xprefetch、 -xprefetch=auto、および -xprefetch=yes を使用すると、コンパイラは必要に応じて先読み命令をコード中に 挿入します。これによって、先読み機能をサポートするアーキテクチャでは パフォーマンスが向上する場合があります。

    大規模マルチプロセッサで、計算集約型コードを実行する場合、-xprefetch=latx:factor を使用すると便利です。このオプションでは、先読み命令と計数により指定された関連するロードまたはストア間のデフォルトの潜在期間を調整するようコードジェネレータに指示します。

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

    注意

    仮定される先読みの潜在期間は、ロード命令とストア命令では 異なる場合があります。

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

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

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

    デフォルト:

    -xprefetch が指定されていない場合は、 -xprefetch=no%auto,explicit が仮定されます。

    -xprefetch だけが指定されている場合は、 -xprefetch=auto,explicit が仮定されます。

    引数なし、あるいは、 auto または yes の引数付きの -xprefetch で明示的に変更しない限り、デフォルトでは no%auto が仮定されます。 たとえば、 -xprefetch=explicit は -xprefetch=explicit,no%auto と同じです。

    no%explicit または no で明示的に変更しない限り、デフォルトでは explicit が仮定されます。 たとえば、 -xprefetch=auto は -xprefetch=auto,explicit と同じです。

    -xprefetch または -xprefetch=yes によって自動先読み実行が有効に設定されているにも関わらず、 潜在期間の値が指定されていない場合は、 latx:1.0 が仮定されます。

    相互の関連性:

    このオプションは上書きされずに累積されます。

    ヘッダーファイル sun_prefetch.h によって、明示的な先読み命令を指定するマクロが使用できます。 先読み指令は、実行可能ファイル中の、マクロとほぼ同じ位置に 挿入されます。

    明示的な先読み指令を使用するには、正しいアーキテクチャ上で、 sun_prefetch.h をインクルードし、コンパイラコマンドには -xprefetch を使用しないか、 -xprefetch、 -xprefetch=auto,explict、 -xprefetch=explicit、 -xprefetch=yes のいずれかを指定しなければなりません。

    マクロを呼び出して sun_prefetch.h ヘッダーファイルをインクルードしたにも関わらず -xprefetch=no%explicit または -xprefetch=no を指定した場合は、明示的な先読み命令は実行可能ファイル中には 挿入されません。

    -xchip の設定は、仮定される潜在期間の決定に影響を及ぼします。つまり、 latx:factor の設定も影響を受けます。

    latx:factor サブオプションは、自動先読みが有効になっている場合にのみ有効です。つまり、 latx:factor は、 yes または auto と一緒に使用されない限り、無視されます。

    警告:

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

    コンパイラは、広範囲に渡るマシンおよびアプリケーションで最良のパフォーマンス が得られるように先読みのメカニズムを調整しているため、 latx:factor サブオプションは、パフォーマンスのテストで明らかにメリットがあると 認められた場合にのみ使用してください。 仮定される先読みの潜在期間は、リリースごとに異なる可能性があります。 したがって、リリースが変わるたびに、潜在期間の係数 (factor) がパフォーマンスに 及ぼす影響をテストすることを、強くお勧めします。

-xprefetch_level=l
    -xprefetch=auto で決定された先読み命令の自動挿入を制御します。-xprefetch=auto を指定する場合、デフォルトは -xprefetch_level=2 です。

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

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

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

-xprofile=p
    実行時プロファイルデータを収集するか、これらのデータで最適化を行います。

    p には、 collect[:name]、 use[:name]、 tcov のいずれかを指定します。

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

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

    値:

    collect[:name]
        後でオプティマイザが -xprofile=use で使用できるように、 実行頻度の情報を収集および保存します。 コンパイラは、文の実行頻度を測定するためのコードを生成します。

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

        -xprofile=collect:name でコンパイルしたプログラムによって、 実行時のフィードバック情報を保存するための name.profile ディレ クトリが実行時に作成されます。 フィードバックデータは、このサブディレクトリ中の feedback ファイルに 保存されます。フィードバック情報の位置は $SUN_PROFDATA および $SUN_PROFDATA_DIR 環境変数を使用して変更可能です。 詳細については、この節の最後にある 「環境変数」 の項を参照してください。 プログラムを複数回実行した場合、実行頻度のフィードバックデータは feedback ファイルに蓄積されるので、前回のデータは失われません。

        コンパイルとリンクを別々のステップで実行する場合、 -xprofile=collect を指定してコンパイルされたオブジェクトファイル は、必ずリンクも -xprofile=collect を指定して実行しなければ なりません。

    use[:name]
        有効な最適化を行うために実行頻度データを利用します。

        name には、フィードバックデータが格納されている .profile ディレクトリの名前を指定してください。name の 指定を省略すると、a.out.profile が フィードバックデータのあるディレクトリとみなされます。

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

        ソースファイル、その他のコンパイラオプションは、 feedback ファイルを生成したプリコンパイル済みプログラムのコンパイル時に 使用したオプションと同じものを指定する必要があります。 -xprofile=collect:name でコンパイルした場合、-xprofile=use:name による最適化コンパイルでは 同じ名前の name を指定する必要があります。

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

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

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

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

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

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

        注: — -xO4 を使用したために関数のインライン化が存在する場合、 -xprofile=tcov によって生成されるコードカバレージレポートは不正確である可能性があります。

    環境変数:

    環境変数 $SUN_PROFDATA および $SUN_PROFDATA_DIR を設定すると、 -xprofile=collect でコンパイルされたプログラムがプロファイルデータを 置く場所を制御できます。 上記の変数が設定されていない場合は、プロファイルデータは 現在のディレクトリの name.profile/feedback というファイルに保存されます。 name は実行可能ファイルの名前、または、 -xprofile=collect:name フラグで指定された名前に置き換えられます。

    環境変数が設定されていると、 -xprofile=collect で収集されたデータは $SUN_PROFDATA_DIR/$SUN_PROFDATA のディレクトリに置かれます。

    これらの環境変数は、 tcov で記述されたプロファイルデータファイル のパスおよび名前も、同様に制御します。 詳細については、 tcov(1) のマニュアルページを参照してください。

-xprofile_ircache[=path]
    (SPARC) -xprofile_ircache[=path] を -xprofile=collect|use とともに使用すると、 collect 段階で保存されたコンパイルデータを再利用することで、 use 段階でのコンパイル時間が改善されます。

    大きなプログラムの場合、中間データが保存されているので、 use 段階でのコンパイル時間が著しく向上します。 保存データによってディスクスペース要求がある程度 増えることに注意してください。

    -xprofile_ircache[=path] を使用すると、 path がキャッシュ化されたファイルが保存されている場所を 上書きします。デフォルトでは、このファイルはオブジェクトファイルと 同じディレクトリに保存されます。パスを指定すると、collect 段階と use 段階がそれぞれ別のディレクトリで実行される場合に便利です。

    コマンドは一般的に次のような順で指定します。

    example% CC -xO5 -xprofile=collect -xprofile_ircache t1.cc t2.cc
    example% a.out // run collects feedback data
    example% CC -xO5 -xprofile=use -xprofile_ircache t1.cc t2.cc

-xprofile_pathmap=collect_prefix:use_prefix
    -xprofile_pathmap オプションは、-xprofile=use と共に使用します。 この -xprofile_pathmap は、以下の条件に当てはまり、コンパイラが -xprofile=use でコンパイルされたオブジェクトファイルの プロファイルデータを見つけられない場合に使います。

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

-xregs=r[,r...]
    (SPARC プラットフォームのみ) スクラッチレジスタの使用を制御します。

    コンパイラは一時記憶領域で使用できるレジスタ (スクラッチレジスタ) が多いほど、 高速なコードを生成できます。このオプションによって、使用可能なスクラッチレジ スタが追加されますが、追加することが適当でない場合もあります。

    r には、次の値のいずれか 1 つを指定するか、または複数を コンマで区切って指定します。

    [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 を指定しない場合、 -xregs=appl,float が仮定されます。

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

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

-xsafe=mem
    (SPARC プラットフォーム) メモリーに関するトラップが発生しないとみなします。

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

    警告:

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

    相互の関連性:

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

    v8plus、 v8plusa、 v8plusb、 v9、 v9a、 v9b

-xsb
    WorkShop ソースコードブラウザ用の情報を生成します。

    このオプションにより、 CC ドライバは、 ソースブラウザの SunWS_cache サブディレクトリにシンボルテーブル情報を追加生成します。

    関連項目:

    -xsbfast

-xsbfast
    コンパイルせずに、ソースブラウザ情報だけを生成します。

    このオプションでは、 ccfe の段階だけを実行して、 ソースブラウザの SunWS_cache サブディレクトリにシンボルテーブル情報を追加生成します。 オブジェクトファイルは生成されません。

-xspace
    (SPARC プラットフォーム) コードサイズが大きくなるような最適化は行いません。

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

    このオプションはマクロです。 -xtarget の値は、 -xarch、 -xchip、 および -xcache オプションの値のセットに展開されます。 fpversion(1) コマンドを使用して、実行中のシステムの -xtarget=native の展開を判断します。 展開される値については、『C++ ユーザーズガイド』 の -xtarget に関する項目を参照してください。

    -xtarget によって、 -xarch、-xchip、 -xcache の組み合わせを素早く簡単に指定することができます。 -xtarget は、展開されて初めて意味をなすものです。

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

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

    -xtarget=native64 は「-xarch=native64, -xchip=native64, -xcache=native」と指定することと同じです。

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

    -xtarget=generic64 は「-xarch=generic64, -xchip=generic64, -xcache=generic」と指定することと同じです。

    値：

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

    値   意味

    native
        ホストシステムで最高のパフォーマンスを得ることができます。

        コンパイラはホストシステムで最高のパフォーマンスが得られるコー ドを生成します。コンパイラが動作しているマシンで使用できるアー キテクチャ、チップ、キャッシュの属性を指定します。

    native64
        ホストの環境 (64 ビットアーキテクチャを想定) で、最高のパフォーマンスを得る ためのパラメータを設定します。

    generic
        汎用アーキテクチャ、チップ、キャッシュで最高のパフォーマンスが得られます。

        コンパイラは、-xtarget=generic を
        -xarch=generic -xchip=generic
        -xcache=generic に展開します。 これはデフォルト値です。

    generic64
        ほとんどの 64 ビットプラットフォームアーキテクチャで、最高のパフォーマンスを得る ためのパラメータを設定します。

    platform-name
        指定したシステムにおいて最高のパフォーマンスが得られます。

        platform-name に指定できる有効な値は、次のとおりです。

        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, ultra2e、ultra2i, ultra1/140, ultra1/170, ultra1/200, ultra2/1170, ultra2/1200, ultra2/1300, ultra2/2170, ultra2/2200, ultra2/2300, ultra3, entr2, entr2/1170, entr2/2170, entr2/1200, entr2/2200, entr150, entr3000, entr4000, entr5000, entr6000

        プラットフォーム名についての詳細は、『C++ ユーザーズガイド』の -xtarget に関する項目を参照してください。

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

        o   native

        o   generic

        o   386 (Intel 80386 マイクロプロセッサで最高のパフォーマンスが得られるように、 コードを生成します)

        o   486 (Intel 80486 マイクロプロセッサで最高のパフォーマンスが得られるように、 コードを生成します)

        o   pentium (Pentium マイクロプロセッサで最高のパフォーマンスが 得られるように、コードを生成します)

        o   pentium_pro (Pentium Pro マイクロプロセッサで最高のパフォーマンスが得られるように、コードを生成します)

    相互の関連性:

    SPARC または UltraSPARC V9 で 64 ビット Solaris 7 または Solaris 8 ソフトウェアを コンパイルするときは、 -xarch=v9、 -xarch=v9a、 -xarch=v9b のいずれかのフラグを指定します。 -xtarget=ultra、 ultra2、または ultra3 の指定は必要ありません (指定する場合は、この設定では不十分です)。 -xtarget を指定するときは、 -xtarget の後に、 -xarch=v9、 -xarch=v9a、 -xarch=v9b のいずれかを指定する必要があります。たとえば、次のとおりです。

    -xtarget=ultra2 ... -xarch=v9

    この指定がないと、 -xtarget の指定により、 -xarch の値が、 v8 に戻されます。

-xthreadvar[=o]
    (SPARC) __thread 宣言指定子とともに働き、 スレッドローカルな記憶領域に関するコンパイラの機能が使用されます。 __thread 指定子でスレッド変数を宣言した後で、 -xthreadvar を指定すると、動的 (共用) ライブラリの位置依存コード (非 PIC コード) で、スレッドローカルな記憶領域の 使用が可能になります。 __thread の使用法の詳細については、 『C++ ユーザーズガイド』 を参照してください。

    値

    o は次のいずれかの値です。

    値   意味

    [no%]dynamic
        動的ロードのための変数をコンパイルします[しません]。 スレッド変数へのアクセスは、-xthreadvar=no%dynamic の 場合に著しく向上しますが、動的ライブラリの中ではオブジェクトファイルを 使用できません。 つまり、実行可能ファイルの中でオブジェクトファイルを 使用できないということです。

    デフォルト

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

    -xthreadvar 指定して引数を指定しない場合、 オプションは -xthreadvar=dynamic に設定されます。

    相互の関連性

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

    Solaris 8 ソフトウェアの場合、__thread を使うオブジェクトは -mt を指定してコンパイルしなければならず、また -mt -L/usr/lib/lwp -R/usr/lib/lwpsoftware で リンクしなければなりません。

    Solaris 9 ソフトウェアの場合、__thread を使うオブジェクトは、 -mt を指定してコンパイルおよびリンクしなければ なりません。

    警告

    位置依存コードが動的ライブラリ内にある場合は、 -xthreadvar を指定しなければなりません。

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

    関連項目

    -xcode、-KPIC、-Kpic

-xtime
    さまざまなコンパイルパスの実行時間を報告するように CC ドライバに指示します。

-xtrigraphs[={yes|no}]
    ISO/ANSI C 標準規格で定義されているように、3 文字表記シーケンスの 認識を有効または無効にします。

    -xtrigraphs=yes は、ソースコード中の 3 文字表記シーケンスの認識を有効にします。

    -xtrigraphs=no は、ソースコード中の 3 文字表記シーケンスの認識を無効にします。

    デフォルト:

    -xtrigraphs オプションの指定がない場合は、 -xtrigraphs=yes が仮定されます。

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

-xunroll=n
    可能な場合はループの展開を有効にします。

    このオプションは、コンパイラがループを最適化 (展開) するかどうかを 指定します。

    n を 1 にすると、コンパイラはループを展開しません。

    n が 1 より大きい整数の場合、 -xunroll=n により、コンパイラはループを 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++ の規格が構文の意味を定義すれば 変更できます。

    -xustr=ascii_ustf16_ushort を指定して、 U"ASCII_string" 文字列リテラルを指定しない場合、 それはエラーにはなりません。

    必ずしもすべてのファイルがこのオプションでコンパイルされる必要は ありません。

    次に、「U」が先頭に付いた引用符で囲まれた文字列ストリングの例を 示します。また、-xustr を指定したコマンド行も示します。

    example% cat file.cc
    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.cc -c

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

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

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

-xwe
    ゼロ以外の終了状態を返すことによって、すべての警告をエラーとして扱います。

-z arg
    リンクエディタのオプションです。

    詳細は、 ld(1) のマニュアルページおよび Solaris の『リンカーとライブラリ』を参照してください。

  PRAGMAS

以下はコンパイルシステムが認識する

SPARC のみ:

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

注意事項
C++ コンパイラは静的ライブラリ libC.a および libCrun.a を含んでいます。ただし、それらに対応するバンドルされた共有ライブラリ libC.so.5 および libCrun.so.1 は、バージョン 7 および 8 の Solaris 動作環境で、Sun WorkShop C++ (5.0) コンパイラと Sun WorkShop 6 C++ (5.1) コンパイラと同期しません。 Solaris 7 および Solaris 8 のオペレーティング環境でコンパイラを 共有ライブラリとともに正常に機能させるには、適切な OS パッチを インストールしなければなりません。 README を参照してください。

詳細を参照するには、 CC -xhelp=readme と入力してください。

ファイル

file.a
    静的ライブラリ

file.C
    入力ファイル

file.cc
    入力ファイル

file.c++
    入力ファイル

file.cpp
    入力ファイル

file.cxx
    入力ファイル

file.o
    オブジェクトファイル

file.so
    動的 (共有) ライブラリ

a.out
    リンク後の出力

関連項目
analyzer(1)、 as(1)、 c++filt(1)、 cc(1)、 csh(1)、 dbx(1)、 gprof(1)、 ild(1)、 ld(1)、 more(1)、 nm(1)、 prof(1)、 tcov(1)

『C++ ユーザーズガイド』
『C++ 移行ガイド』
『プログラミング言語 C++』第 2 版、B. Stroustrup 著、トッパン
『プログラミング言語 C』第 2 版、B.W. Kernighan、D.M. Richie 共著、共立出版
Solaris の『リンカーとライブラリ』
『International Standard (ISO/IEC FDIS 14882)』の 「Programming Languages — C++」