3

私のプロジェクトでは、g++とnvcc（cudaコンパイラ）の2つの異なるC++コンパイラを使用しています。nvccオブジェクトファイルからスローされた例外がg++オブジェクトファイルでキャッチされないことに気づきました。

C ++例外は、同じマシンでバイナリ互換であると想定されていますか？何がそのような行動を引き起こす可能性がありますか？

try { kernel_= new cuda:: Kernel(); }
catch (...) { kernel_= NULL; }

// nvcc object
cuda:: Kernel:: Kernel () {
  ...
  if (! impl_) throw;
}

他のすべては機能しているようです（C ++オブジェクト、演算子）。正直なところ、私は例外をよく知らないので、上記のコードに間違いがあるかもしれません。

4

3 に答える 3

7

一晩で2つの「いいえ」の答えを出して申し訳ありませんが、「いいえ」、C ++例外（またはそのことについてはクラス）には標準のバイナリレイアウトがありません。2つの異なるコンパイラ間でC++クラス/例外を使用しようとすると、単一定義規則に違反します。

これを回避するには、オブジェクトファイル間でC APIのみを許可します（Cには標準のABI-アプリケーションバイナリインターフェイスがあるため）。または、いずれかのコンパイラですべてのコードをコンパイルできます。ただし、最後のビットがNVCCで可能かどうかはわかりません。

質問の編集に応じて：他のすべてが機能しているようです（C ++オブジェクト、演算子） ：ほとんどの場合に機能しているように見えるものがたくさんあります。これは、未定義の動作を呼び出さないという意味ではありません。

于 2010-04-12T02:58:52.760 に答える
6

nvccは、通常のc ++コンパイラのラッパーであり、基本的にはcuda構文をコンパイル可能なものに変換するためのプリプロセッサです。--verboseフラグを使用して、どのコンパイラが使用されているかを確認できます。

たとえば、私のマシンでコンパイルします

// test.cpp
int main(){return 0;}

nvcc -v与えると

#$ _SPACE_= 
#$ _MODE_=DEVICE
#$ _HERE_=/usr/local/cuda/bin
#$ _THERE_=/usr/local/cuda/bin
#$ TOP=/usr/local/cuda/bin/..
#$ PATH=/usr/local/cuda/bin/../open64/bin:/usr/local/cuda/bin/../bin:/Library/Frameworks/Python.framework/Versions/Current/bin:/Users/me/bin:/usr/local/aspell/bin:/usr/local/noweb:/usr/local/icon/bin:/usr/local/dmd/bin:/usr/local/cuda/bin:/usr/local/sed/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
#$ INCLUDES="-I/usr/local/cuda/bin/../include"  
#$ LIBRARIES=  "-L/usr/local/cuda/bin/../lib" -lcudart
#$ CUDAFE_FLAGS=
#$ OPENCC_FLAGS=
#$ PTXAS_FLAGS=
#$ gcc -c -x c++ "-I/usr/local/cuda/bin/../include"   -I. -m32 -malign-double -o "/tmp/tmpxft_000010af_00000000-1_test.o" "test.cpp" 
#$ g++ -m32 -malign-double -o "a.out" "/tmp/tmpxft_000010af_00000000-1_test.o"   "-L/usr/local/cuda/bin/../lib" -lcudart

ここにリストされているものと同じコンパイラ/フラグを使用すると、バイナリ互換性が得られるはずです

于 2010-04-12T03:34:12.987 に答える
2

C ++標準では、例外は言うまでもなく、バイナリ形式は指定されていません。これが機能することを期待する必要がある理由はありません。

于 2010-04-12T03:00:41.163 に答える