Yeah, I don't think there is anything wrong with checking INTEL_MKL_VERSION for this purpose.
"Balay, Satish" <[email protected]> writes: > On Tue, 23 Oct 2018, Mills, Richard Tran wrote: > >> On 10/23/18 2:31 PM, Matthew Knepley wrote: >> On Tue, Oct 23, 2018 at 2:20 PM Mills, Richard Tran >> <[email protected]<mailto:[email protected]>> wrote: >> Barry, Satish, and others, >> >> In MKL 2018 update 2, the old, non-inspector executor sparse BLAS interfaces >> were deprecated in favor of the newer, inspector-executor versions. To keep >> lots of warnings from being generated, I put in some preprocessor code to >> avoid using these interfaces in AIJMKL, and the hack-y way I did this was >> simply based on whether PETSC_HAVE_MKL_SPARSE_SP2M is defined, since >> mkl_sparse_sp2m() was introduced in this same update and I needed a >> configure test for the presence of this function anyway. >> >> I now want to change the mkl_sparse_sp2m.py test to not define >> PETSC_HAVE_MKL_SPARSE_SP2M for versions of MKL prior to 2019, because I >> determined that the way I am using mkl_sparse_sp2m() is unsafe prior to this >> version. Since this will break my current logic for determining which MKL >> routines are deprecated, this seems like a good time to handle the >> deprecation in a better way. > > Check HAVE_MPI_WIN_CREATE_FEATURE code. Its probably messy - but the idea is > - 'PETSC_HAVE_MKL_SPARSE_SP2M' should not be overloaded with this additional > constranits. > > however 'PETSC_HAVE_MKL_SPARSE_SP2M_FEATURE' - can be used [flag set only > when additional constraints are satisfied]. > >> >> I did some cursory grepping through the BuildSystem packages files, and it >> looks (?) like we don't have some examples to follow on how to handle >> deprecated library functions. What I'd like to do is compile a test that >> calls one of the deprecated functions and then checks for warning messages >> from the compiler, but I don't know the variants of all of the warning >> messages that compilers might emit, and I think some compilers won't give >> any. If there isn't a good way to do such a test, I could >> >> * Rely on the version information in mkl_version.h, OR >> * (The easiest solution) Check to see if MKL_DEPRECATED is defined. (This >> was introduced when the old sparse BLAS interfaces were deprecated.) > > Assuming the feature works with this version check across all MKL impls > [linux, mac, win] - I migh just do the version check. Processing warnings is > fragile. > [note there is a version check for HAVE_MPI_WIN_CREATE_FEATURE] > > Satish >> >> I do not understand this one. You check for a #define, which happens to >> coincide with the change? >> Yes, MKL_DEPRECATED is a macro that is defined in MKL and used to tag the >> prototypes of the deprecated functions. This appears to be the first time >> that this macro has been used, so it coincides with the change. >> >> Is there a "best practice" for how we should handle such things in PETSc? >> >> Relying on compiler warnings seems bad unless its something that compilers >> are guaranteed to emit. >> Yeah. The motivation is to eliminate compiler warnings, but I don't know >> exactly what the warnings will be or whether a given compiler will even emit >> anything... >> >> --Richard >> >> Matt >> >> --Richard >> >> >> -- >> What most experimenters take for granted before they begin their experiments >> is infinitely more interesting than any results to which their experiments >> lead. >> -- Norbert Wiener >> >> https://www.cse.buffalo.edu/~knepley/<http://www.cse.buffalo.edu/%7Eknepley/> >> >>
