May I know the reason?
Hi @CaoZhongZ . That's because internally we don't handle exceptions and rely on status codes for error handling. Xbyak was updated recently to also provide status codes instead of exceptions, and you can find much more details here https://github.com/herumi/xbyak/pull/98
Hmmmm, actually the exception was for debugging. if there is no exception, we don't know all the hidden errors in the assembly like jump should be near instead of short. It mean for program "not to handle", functioning much like a compilation error. At least it triggers debugger stop and shows error message. Do oneDNN try to eliminate the use of exception?
The errors can still be debugged, instead of using catch throw you set a breakpoint here https://github.com/oneapi-src/oneDNN/blob/f57921d3b7f18c07d2c07168fccad13749cb647f/src/cpu/x64/xbyak/xbyak.h#L307.
Yes, the goal was to eliminate the use of exceptions internally, and use status codes.
Update: the Xbyak exceptions should not reach the end user. For debugging purposes you could either set a breakpoint as shown above, or you could rebuild the library with the macro disabled.
Okey, just surprised by not having error message anymore. Thanks.