SET_XERBLA - override the error-handler without linker stuff - #1407
SET_XERBLA - override the error-handler without linker stuff#1407mohawk2 wants to merge 8 commits into
SET_XERBLA - override the error-handler without linker stuff#1407Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1407 +/- ##
=======================================
Coverage 69.36% 69.36%
=======================================
Files 6122 6122
Lines 486337 486381 +44
Branches 23268 23268
=======================================
+ Hits 337330 337372 +42
- Misses 148569 148571 +2
Partials 438 438
Continue to review full report in Codecov by Harness.
|
|
Hi @mohawk2, I like the idea a lot, since it would solve all the problems we currently have with error testing (e.g., it doesn't work with shared Windows libs or two-level namespaces) and make it easier for users to use a custom xerbla on all platforms. A few things to consider:
|
|
There is also a possibility of defining it as a weak symbol so tests can override the regular one. that can limit the surgery to only xerbla. overall I don't think xerbla is a good way to report errors back but it is what it is for now. |
Yes, that's how it's currently done in the CBLAS test suite. Won't work on Windows, though. Also, doing that in Fortran would depend on the compilers supporting it (nagfor doesn't without major hacks, ifx & flang maybe). |
|
I do use it on windows albeit on a C translation and Clang.
ah then nevermind. Sorry for the noise |
Ah, you're right; Clang and Intel do support it on Windows for static libraries. Did you try it with a shared library? Because last time I checked, that was the blocker. |
|
Thank you all for your quick responses! As noted in my edit of the PR description, I'm intending to add CBLAS and LAPACKE equivalents. I'll ponder the names, I hadn't properly checked prior art and will do so now. I'll ponder the idea of different BLAS and LAPACK handlers - is it really true that the current implementation essentially has two similarly-named symbols that are each are getting overridden by the user-supplied one? If so, that seems horrible. I might need to make differently-named entry points for each that call each other, since the user expectation will be a full override for both. |
Yes, I think using the same REGISTER_XERBLA symbol name in BLAS and LAPACK could mean it only replaces one of the handlers (if we use separate shared libraries). My sugestion would be to have the separate symbols and then one symbol that does both and lives in LAPACK. Something like this: Edit: One issue would be that when we are compiling LAPACK with a vendor BLAS lib and they don't implement |
My pondering came up with a similar result, but not identical (see below). The above discussion included the point that prior art (
Edit 1: specify that subroutine xerbla(srname, info)
character*(*), intent(in) :: srname
integer, intent(in) :: info
procedure(xerbla_interface), pointer :: active_callback => null(), cb_ret
procedure(xerbla_interface) :: cb
abstract interface
subroutine xerbla_interface(srname, info)
character*(*), intent(in) :: srname
integer, intent(in) :: info
end subroutine
end interface
if (associated(active_callback)) then
call active_callback(srname, info)
else
print *, 'I am the main xerbla'
end if
return
entry set_xerbla(cb)
active_callback => cb
return
entry get_xerbla(cb_ret)
cb_ret => active_callback
return
end subroutine
subroutine xerbla_replacement(srname, info)
character*(*), intent(in) :: srname
integer, intent(in) :: info
print *, 'I am the replacement xerbla'
end subroutine
program hello
implicit none
external xerbla_replacement, set_xerbla, xerbla
procedure(), pointer :: already_cb
interface
subroutine get_xerbla(cb_ret)
procedure(), pointer :: cb_ret
end subroutine
end interface
call xerbla('Hello, World!', 5)
call get_xerbla(already_cb)
call set_xerbla(xerbla_replacement)
call xerbla('Hello, World!', 5)
call set_xerbla(already_cb)
call xerbla('Hello, World!', 5)
end program helloPrototype code using a module xerbla_callbacks
implicit none
private
public :: active_callback, xerbla_interface
procedure(xerbla_interface), pointer :: active_callback => null()
interface
subroutine xerbla_interface(srname, info)
character*(*), intent(in) :: srname
integer, intent(in) :: info
end subroutine
end interface
end module xerbla_callbacks
subroutine set_xerbla(cb)
use xerbla_callbacks
implicit none
procedure() :: cb
active_callback => cb
end subroutine set_xerbla
subroutine get_xerbla(cb_ret)
use xerbla_callbacks
procedure(xerbla_interface), pointer :: cb_ret
cb_ret => active_callback
end subroutine get_xerbla
subroutine xerbla(srname, info)
use xerbla_callbacks
character*(*), intent(in) :: srname
integer, intent(in) :: info
if (associated(active_callback)) then
call active_callback(srname, info)
else
print *, 'I am the main xerbla'
end if
end subroutine
subroutine xerbla_replacement(srname, info)
character*(*), intent(in) :: srname
integer, intent(in) :: info
print *, 'I am the replacement xerbla'
end subroutine
program hello
use xerbla_callbacks
implicit none
external xerbla_replacement, set_xerbla, xerbla
procedure(), pointer :: already_cb
interface
subroutine get_xerbla(cb_ret)
procedure(), pointer :: cb_ret
end subroutine
end interface
call xerbla('Hello, World!', 5)
call get_xerbla(already_cb)
call set_xerbla(xerbla_replacement)
call xerbla('Hello, World!', 5)
call set_xerbla(already_cb)
call xerbla('Hello, World!', 5)
end program hello
Yes, that sounds like a good approach. |
|
My thinking so far on a CBLAS approach (The LAPACKE version will be mutatis mutandis, so will not be addressed separately). CBLAS has an actual
For the CBLAS versions of the 3 procedures plus
|
mohawk2
changed the title
REGISTER_XERBLA - override the error-handler without linker stuffSET_XERBLA - override the error-handler without linker stuff
3 participants
Description
Currently, to override BLAS/LAPACK's handling of errors involves defining a
xerbla_(or sometimesxerbla) symbol in your library/executable. This may not work in 2-level namespace environments like macOS.Instead, this PR allows you to call
SET_XERBLA(Fortran) with a replacement handler, orNULL()to reset to default. There is also anGET_(library)_XERBLA. This does not address that the new handler must be a Fortran-compatible routine.There are CBLAS (
cblas_set_xerbla) and LAPACKE (LAPACKE_set_xerbla) handlers on the way, but I'm putting this up for review as I believe it already adds value.I have marked below that the documentation has been updated, because I added a paragraph in the doc-comments of
xerbla.f. If more is needed, please let me know.EDIT: updated function names.
Checklist