- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page