<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Oct 23, 2018 at 2:20 PM Mills, Richard Tran <<a href="mailto:rtmills@anl.gov">rtmills@anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div bgcolor="#FFFFFF" text="#000000">
Barry, Satish, and others,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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<br>
<br>
* Rely on the version information in mkl_version.h, OR<br>
* (The easiest solution) Check to see if MKL_DEPRECATED is defined. (This was introduced when the old sparse BLAS interfaces were deprecated.)<br></div></blockquote><div><br></div><div>I do not understand this one. You check for a #define, which happens to coincide with the change?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
Is there a "best practice" for how we should handle such things in PETSc?<br></div></blockquote><div><br></div><div>Relying on compiler warnings seems bad unless its something that compilers are guaranteed to emit.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
--Richard<br>
</div>

</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>