- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
I'm changing the huge system code with MKL which was work with IMSL.
The default real kind of the code is set to 8 (/real_size:64).
I used double precision MKL functions like
PROGRAM ...
IMPLICIT NONE
REAL A, B, ...
CALL DGEEV(A,B,...)
END PROGRAM
When compiled first with MKL library, almost 1,000 warnings (warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic name.) show up but it disappears when compiled again.
I wonder this warning signs affect the code results.
best regards,
1 解決策
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
You should expect such problems to arise whenever you try to combine some of routines compiled with /real_size:64 with other routines (your own, or in libraries such as MKL) which were compiled with, in effect, /real_size:32.
The problem is compounded by you use of the specific subroutine DGEEV rather than the generic subroutine GEEV. If you had called GEEV, the compiler would have produced a call to the correct specific subroutine based on the types of the actual arguments (after they had been promoted because of the /real_size:64 option).
The problem is compounded by you use of the specific subroutine DGEEV rather than the generic subroutine GEEV. If you had called GEEV, the compiler would have produced a call to the correct specific subroutine based on the types of the actual arguments (after they had been promoted because of the /real_size:64 option).
コピーされたリンク
1 返信
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
You should expect such problems to arise whenever you try to combine some of routines compiled with /real_size:64 with other routines (your own, or in libraries such as MKL) which were compiled with, in effect, /real_size:32.
The problem is compounded by you use of the specific subroutine DGEEV rather than the generic subroutine GEEV. If you had called GEEV, the compiler would have produced a call to the correct specific subroutine based on the types of the actual arguments (after they had been promoted because of the /real_size:64 option).
The problem is compounded by you use of the specific subroutine DGEEV rather than the generic subroutine GEEV. If you had called GEEV, the compiler would have produced a call to the correct specific subroutine based on the types of the actual arguments (after they had been promoted because of the /real_size:64 option).
