バージョン A.03.33 の新機能

OpenMP 標準のサポート

このリリースでは、OpenMP C/C++ API 仕様のバージョン 1.0 を完全にサポートします。この仕様は、http://www.openmp.org/specs で入手できます。

OpenMP プラグマを認識させるには、aCC の起動時に +Oopenmp コマンド行オプションを使用してください。このオプションは任意の最適化レベルで有効です。

	注記: 現時点では、+Onoparallel はソース内の OpenMP プラグマに影響を与えませんが、+Oautopar を無効にします。

マルチスレッド化が行われるため、-mt を +Oopenmp と併用する必要があります (そうしないと、特に -AA を指定している場合に実行時に異常終了することがあります)。

OpenMP プラグマを使用するには、libomp およびlibcps ランタイムサポートライブラリがコンパイルシステムと実行システムの両方に存在する必要があります。コンパイラドライバは、リンク時に自動的にlibomp およびlibcps ランタイムサポートライブラリをリンクします。

これらのライブラリは、次のパッチを適用することによって、インストールされます。

多数のスレッドでの実行時のメモリー不足を避けるために、OpenMP プラグマのリンク時に -N オプションを使用することをお勧めします。

OpenMP をサポートするこの最初の aCC では、OpenMP 構文のデバッギング位置情報が正しくない場合があります。さらに、threadprivate プラグマによってマークされたシンボルが、デバッガに認識されないことがあります。この制限事項を回避するには、代わりにシンボル宣言内に __thread 記憶クラス指定子を使用してください。

   #if defined(__HP_aCC) && !defined(__THREAD)
   #  define __THREAD __thread
   #else
   #  define __THREAD
   #endif
 
   __THREAD int tprvt;
   #pragma omp threadprivate(tprvt)

また、OpenMP は、aC++ の ANSI C モード (-Ae) でもサポートされます。

OpenMP の既知の問題

firstprivate 変数は、ループ繰り返し数の計算後に初期化されます。その結果、繰り返し数が firstprivate 変数の値に依存するループは正しく実行されません。次に例を示します。

int n = 100; #pragma omp for firstprivate(n) for (int i = 0; i < n; i++) { // n のプライベートコピーが // ループの繰り返し数が計算される前に初期化されないため、 // ループの繰り返し数は不確定になります。 }

コンパイルエラーの最大数を制御する aCC_MAXERR

aCC_MAXERR 環境変数によって、コンパイルを終了する前にコンパイラに報告させるエラーの最大数を設定できます。現在のデフォルト値は 12 ですが、ゼロより大きい任意の値を設定できます。

コンパイラは、エラーから回復できないこともあるため、

699 Error limit reached: halting compilation

ではなく、

445 Cannot recover from earlier errors

のメッセージが表示されることもあります。

エラーの最大数を 100 とした例を次に示します。

    $export aCC_MAXERR=100
    $aCC -c buggy.c

malloc の Small Block Allocator

使用しているシステムに合った aCC ラインタイムパッチと libc パッチをインストールすることによって、aC++ ランタイムでは、malloc の Small Block Allocator (SBA) が有効になります (前述の「必須パッチ」の項を参照)。これによって、ヒープパフォーマンスが向上します。

詳細は、malloc(3) および mallopt(3) のマンページを参照してください。

デフォルト値は、次のとおりです。

M_MXFAST = 512 バイト

M_NLBLKS = 100

M_GRAIN = 8 バイト

デフォルトを変更したい場合は、環境変数 _M_SBA_OPTS を使用できます。形式は、次のとおりです。

export _M_SBA_OPTS=<maxfast>:<numlblks>:<grain>

既存のアプリケーションがすでに mallopt を呼び出している場合は、アプリケーションが mallopt を呼び出すときには libCsup がすでに mallopt を呼び出して小ブロックを割り当てているため、mallopt はエラーを返します。

上記のデフォルトを使用する場合や、すでに _M_SBA_OPTS を使用している場合は、エラーを無視します。デフォルトがパフォーマンスを損なう場合は、_M_SBA_OPTS にアプリケーションが使用する値を設定するか、次のように指定することによってこの機能を無効にします。

export _M_SBA_OPTS=0:0:0

メモリーリークが潜在するアプリケーションでは失敗することがあります。SBA が無効なときにアプリケーションがサイズの小さすぎるブロックを割り当てる場合は、ブロックは、割り当てられたブロックの最後のオーバーランによって失敗しないようにパディングされます。SBA が有効な場合は、次の隣接バイトが制御情報用に使用され、オーバーランはヒープを破壊して異常終了します。

Gather/Scatter プリフェッチプラグマ

指定したキャッシュ行をプリフェッチするプラグマがサポートされるようになりました。このプラグマの動作は、+Odataprefetch に似ていますが、prefetch プラグマは、キャッシュに格納された添え字付き配列の特定要素にアクセスできます。さらに、有効な lvalue は引き数として使用できますが、プラグマの目的は、配列処理のサポートです。

例

次の関数は、aCC コマンドに +O2 +Odataprefetch +DA2.0 (または +DA2.0W) を指定してコンパイルした場合に、ia と b をプリフェッチしますが、a[ia[i]] はプリフェッチしません。

void testprefc2(int n, double *a, int *ia, double *b) { for (int i=0; i<n, i++) { b[i]=a[ia[i]]; } }

このルーチンを次のように変更します。

#define USER_SPECIFIED 30 void testprefc2(int n, double *a, int *ia, double *b) { int dist=(int)USER_SPECIFIED; int nend=max(0,n_dist); /* so as not to read past the end of ia */ for(i=0;i<nend;i++) /* original loop is for (i=0;i<n;i++)*/ { # pragma prefetch ia[i+4*dist] # pragma prefetch a[ia[i+dist]] b[i]=a[ia[i]]; } /* finish up last part with no prefetching */ for (int i=nend;i<n;i++) b[i]=a[ia[i]]; }

2 つのプラグマ文によって、a[ia[i]] がプリフェッチされます。コンパイラは、元のコードのループと同様に、ループを引き続きアンロールすることに注意してください。

カーネルがサイズの大きいページを割り当てることができないようにプリフェッチプラグマを使用すると、問題が発生することがあります。サイズの大きいページがないと、Translation Lookaside Buffer (TLB) のパフォーマンスが損なわれることがあります。最適なページサイズは、アプリケーションによって異なりますが、平均的な推奨ページサイズは 4MB です。

特定のページアドレスが TLB バッファーにない場合は、TLB フォルトが発生します。このバッファーには、キャッシュ内で最近フェッチされたページの絶対アドレスに対する仮想アドレスのマッピングが含まれます。TLB フォルトは、特定の仮想ページアドレスに対する参照がバッファー内で絶対アドレスに変換されなかった場合に発生します。

すべての TLB とプリフェッチ機能が動作しているときでも、システムのメモリー帯域幅によって制約を受けます。PA-RISC システムにすべてのメモリースロットをロードできないと、高帯域幅が縮小されることがあります。メモリーコントローラは、すべてのスロットがロードされている場合に、最高のバンクインタリービングを得ることができます。

SDK/XDK のサポート

SDK/XDK 機能によって、別の場所にインストールされたコンポーネント、ヘッダーファイル、およびライブラリを選択することができます。次の環境変数の一方または両方を設定する必要があります。

_declspec のサポート

このリリースでは、キーワードとして __declspec(dllimport) および __declspec(dllexport) をサポートします。これらのキーワードは、Microsoft Windows コンパイラと同じ意味で、Microsoft Windows コンパイラで開発されたアプリケーションを簡単に HP-UX システムに移植できます。

これらのキーワードのサポートによって、共有ライブラリのパフォーマンスが強化され、HP_DEFINED_EXTERNAL プラグマを使用しなくても、エクスポートされないシンボルを隠すことができます。

構文および意味

__declspec ( extended-attribute ) declarator extended-attribute: dllimport | dllexport

1. 外部リンケージを持つシンボルを __declspec(dllexport) としてコンパイラに対して宣言すると、シンボルは現在のロードモジュール (共有ライブラリ) からエクスポートされ、他のロードモジュールから認識可能になります。

2. 外部リンケージを持つシンボルを __declspec(dllimport) としてコンパイラに対して宣言すると、シンボルは共有ライブラリ内で定義され、現在のロードモジュール外にあるシンボルとなります。

3. __declspec(dllexport) または __declspec(dllimport) キーワードを指定したクラスを宣言すると、すべてのメンバー関数と静的データメンバーがエクスポートまたはインポート用にマークされます。

4. 外部リンケージを持つシンボルだけが、これらのキーワードを使って宣言されます。

5. dllexport または dllimport としてクラスのメンバーを選択的に指定することは有効ですが、クラス自体がエクスポートまたはインポートされる場合は許可されません。

コマンド行オプション-Bhidden および-Bhidden_def

HP-UX システム上の aC++ コンパイラの現在の動作では、デフォルトで外部リンケージを持つすべてのシンボルをエクスポートします。容易に __declspec(dllexport) でマークされたシンボルだけをエクスポートして残りのシンボルを隠すために、デフォルトで次の 2 つのオプションを使用します。

コマンド行オプション-Bhidden_def

このオプションは、__declspec(dllexport) で宣言されたシンボルや HP_DEFINED_EXTERNAL プラグマで指定されたシンボル以外の、変換単位内で定義されているすべてのシンボルを隠します。

隠されるようにマークされたすべての関数 (変換単位内で定義された関数および参照される関
数) は、同じロードモジュール内で定義されていると考えられるため、コンパイラは、直接呼び出しを生成することによって、これらの関数への呼び出しを最適化できます。しかし、同じロードモジュール内で定義されていない関数については、PLT によって間接呼び出しを生成するようにコンパイラに指示する必要があります。これは、HP_DEFINED_EXTERNAL プラグマを使って行い、次のいずれかの方法を選択できます。

1. 現在の変換単位内で定義されたシンボルを隠し、( HP_DEFINED_EXTERNAL プラグマを使って指定された関数以外の) 定義されていない関数への呼び出しを最適化します。

2. 現在の変換単位内で定義されたシンボルを隠しますが、定義されていない関数への呼び出しを最適化しません。この場合は、HP_DEFINED_EXTERNAL については考慮する必要はありません。

	注記: これらの機能を使用するには、次のリンカーパッチをインストールする必要があります。 PHSS_24303 (HP-UX 11.00 の場合) PHSS_24304 (HP-UX 11.11 の場合) main 関数は常にエクスポートされます。 コンパイラが生成した vtables と typeids は常にエクスポートされます。 -Bhidden または-Bhidden_def オプションが使用されるときは常にコンパイラは __HP_WINDLL マクロを定義します。このマクロは条件付きコンパイル用に使用できます。次に例を示します。 #ifdef __HP_WINDLL # define DLLEXPORT __declspec(dllexport) # define DLLIMPORT __declspec(dllimport) #else # define DLLEXPORT # define DLLIMPORT #endif クラスのインラインメンバー関数が、そのクラスが定義されている共有ライブラリ外から呼び出され、その関数が同じクラスの別のメンバーを参照することになる場合は、参照されるメンバーもエクスポートされることを確認する必要があります。エクスポートされないと、リンカーは解決できません。 共有ライブラリに定義されているクラスの仮想メンバー関数が必要に応じて確実にエクスポートされるようにします。仮想メンバー関数がエクスポートされず、別のクラスがこのクラスから派生しているが、これらの仮想関数をオーバーライドしない場合は、リンク時のエラーが発生します。以下の例 8 を参照してください。

プロファイルベースの最適化 (PBO) オプション +Oprofile

このリリースでは、PBO の利便性が機能拡張されました。コンパイルフェーズでコンパイラの中間コードの代わりに直接 PA-RISC マシンコード (SOM) を生成するように選択できるようになりました。旧バージョンのコンパイラでは、PBO オプション (+I、+P) を指定するとコンパイルフェーズで、中間コードを生成し、リンクフェーズで最終的な PA-RISC マシンコードを生成していました。この動作の結果、多数のファイルが PBO オプションでコンパイルされる場合に、すべてのファイルのコード生成がリンクフェースで行われました。

これによる明らかなデメリットは、1 つのファイルだけが変更された場合でも +Oreusedir= が指定されていない場合に、その他のすべてのファイルのコード生成がリンクフェーズで行われることです。これによって、コンパイルとリンクの時間が著しく長くなります。新しい +Oprofile オプションセットを指定することによって、このデメリットを回避できます。

以下のオプションでは、+I、+P、+O4 オプションのように ISOM (中間コード .o ファイル) を生成しません。したがって、これらのオプションは ISOM をビルドするオプションよりも速く再ビルドしますが、+I フェーズでビルドされた ISOM からは、+P フェーズで再リンクされることはありません。また、新しいオプションは、+O4 オプションによるクロスモジュールの最適化をサポートしません。ソースによる再ビルドを行わない PBO ビルドプロセスでは、これらの新しいオプションを利用できませんが、SOM に変換するために現在スクリプトを使って ISOM ごとに ld -r コマンドを実行しているプロセスでは、スクリプトを実行する代わりに aCC ドライバにこれらの新しいオプションを指定することによって実行できます。

+Oprofile の新しいオプションは次のとおりです。

+Oprofile=prediction:static

この実行可能ファイルの静的分岐予測を選択します。+Ostaticprediction と同じです。

	注記: 新しいオプションを使って最適化を実行するときは、次の点に注意してください。 新しいオプションは -c (コンパイルのみ) を指定した場合にだけ使用できます。指定しないと、旧バージョンのコンパイラと同様に最適化が実行されます。 新しいオプションは、+O4 より下の最適化レベルで使用できます。+O4 では、コンパイラはメッセージを表示することなく、+Oprofile を +I または +P に置き換えます。 同じコマンドで最適化の実行時に新しいオプションと古いオプションを併用することはできません。たとえば、同じコマンド行では、+Oprofile と +I/+P/+df は使用できません。 +P によるリンクフェーズの代わりに +Oprofile=use でコンパイルするときには、flow.data ファイルが存在する必要があります。

スレッドローカルストレージの初期化

スレッド private 変数の静的なリンク時の初期化 (POD のみ) がサポートされています。旧バージョンのコンパイラでは、初期化されていないスレッド private 変数だけがサポートされていました。

次に例を示します。

  __thread int j = 2; // allowed with this release
  int main()
     j = 20;
  }

スレッド private メモリーは実行時に割り当てられるため、スレッド private 変数の仮想変数は、アドレスのコンパイル時の評価が必要な状況で使用してはいけません。次に、誤った使用例を示します。

例 1:

  __thread int tpv_1;
  __thread int *ptr = &tpv_1;   //incorrect

例 2:

  __thread int tpv_1;
  int *ptr = &tpv_1;            //incorrect

+O[no]inline=list オプション

リスト形式を使用できます。extern C 関数名を含むか、マングル名でなければなりません。

prefixinclude 検索を実行するために機能拡張された-I-オプション

-I- オプションは、prefixinclude 検索を行うために機能拡張されました。-I- オプションだけでは、引用符や山かっこで囲まれた検索パス上にない、親ファイルの引用符で囲まれたインクルードが関係している場合には処理できません。prefixinclude 検索では、インクルードしている親ファイル内の #include 指令にディレクトリ接頭辞を使用することによって、インクルードするファイルのディレクトリがインクルード検索リスト上にない場合もサポートします。

-I- を指定しない場合は、親の #include 指令でディレクトリ接頭辞を使用すると、コンパイラは、最上位レベルのソースファイルのディレクトリからのディレクトリオフセットを参照します。-I- を指定した場合は、同様に親ファイルにディレクトリ接頭辞を使用すると、検索リスト上のディレクトリと比較したオフセットが実際には定義されます。これは、子の #include "..." 指令で明示的にディレクトリ接頭辞を指定する場合と等価です。実際、ソースの #include 指令をこのように変更することによって、プリプロセッサで prefixinclude をサポートしなくても、インクルードされるファイルが見つかります。

次に、例を示します。

 $ ls
 a.c incl/ mk
 $ ls incl
 f.h x.h y.h
 
 $ cat a.c
 #include "incl/f.h"
 
 $ cat incl/f.h
 #include "incl/y.h"
 #include "x.h"
 
 $ cat incl/x.h
 int x;
 
 $ cat incl/y.h
 int y;
 
 $ aCC -c -I. a.c
 $ # previous versions of aC++
 $ aCC -c -I. -I- -I. a.c
 "./incl/f.h", line 2: Error: Could not open include file "x.h".

	注記: a.c は -I. によって正常にコンパイルされますが、-I. -I- -I. では、-I. で x.h を見つけることはできないことに注意してください。

実際には、prefixinclude 機能では、サブディレクトリ接頭辞 (この場合は incl) は、インクルードするファイルの #include "..."形式のインクルードから継承されます。したがって、インクルードファイルが "prefix/includer" または <prefix/includer> としてインクルードされていた場合は、"prefix/includer" によってインクルードされたファイル "includee" は最初に "prefix/includee" を使って検索されます。失敗した場合は、次に "includee" を使って検索されます。適切な -I パスをそれぞれ使用します。

#include <...> ファイルの検索は、prefixinclude によって影響を受けません。#include "..." ファイル検索だけが拡張されました。

HP_LONG_RETURN および +DA1.1 の最適化機能の向上

HP_LONG_RETURN および +DA1.1 のコードは、+Oentrysched を使用すると最適化されます (非静的メンバー関数のコードでは常に、HP_LONG_RETURN が有効になります)。+eh の使用時に +Oentrysched を指定すると問題が発生することがあります。したがって、+Oentrysched は +noeh を指定した場合のみ使用することをお勧めします。