[petsc-dev] Testing for deprecated MKL functions?

[Matthew Knepley]

On Tue, Oct 23, 2018 at 2:20 PM Mills, Richard Tran <rtmills at anl.gov> 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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20181023/8be6423f/attachment.html>