On Tue, Oct 23, 2018 at 2:20 PM Mills, Richard Tran <[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? > 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. 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/~knepley/>
