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. 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.) 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/>
