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