Closed IanRS closed 12 years ago
xianyi
commented
12 years ago Hi IanRS,
I just checked the codes. The samax subroutine called amax_sse.S. Because samax is not in Level 1 BLAS, we didn't test this function. I think this is an extension by Goto.
I will write a test case for this function.
Xianyi
IanRS
commented
12 years ago Hi Xianyi,
I used to use GotoBLAS, but that did not compile with the latest processors. Part way through patching it to consider Nehalem the same as an older model I found OpenBLAS, so I switched to that. In addition to being able to call the static library from C I also want to be able to use the Windows DLL from Delphi, so I am writing my own interface library, together with Delphi based reference functions and a test suite. I found this bug because I am going through every function in exports/gensymbol, including checking whether anything appears in @blasobjs that is not in @cblasobjs, and calling the Fortran routine directly for those.
There are a number of routines with code available that do not appear in the 'standard' BLAS, or at least not via the cblas interface. e.g. Although the iXamax (X=s/d/c/z) has a cblas interface, iXamin does not. Neither does Xamax, Xamin, iRmax, iRmin, Rmax, Rmin or Rcabs1. R = S or D, but not C or Z. Some of these are also supplied by the ATLAS BLAS library, sometimes with the prefix atlas instead of cblas, acknowledging that they are not part of the standard BLAS library, but may still be useful to users of that library. Regards, Ian
From: Xianyi Zhang reply@reply.github.com To: IanRS ian.shatwell@btinternet.com Sent: Wednesday, 25 April 2012, 15:26 Subject: Re: [OpenBLAS] Unbalanced stack in x86 amax_sse.S (#96)
Hi IanRS,
I just checked the codes. The samax subroutine called amax_sse.S. Because samax is not in Level 1 BLAS, we didn't test this function. I think this is an extension by Goto.
I will write a test case for this function.
Xianyi
Reply to this email directly or view it on GitHub: https://github.com/xianyi/OpenBLAS/issues/96#issuecomment-5332384
xianyi
commented
12 years ago Hi Ian,
Thank you for this report.
Because we plan to make a new release this week, we don't have enough time to support those functions.
I will add a feature request into next release version (0.1.2 or 0.2.0).
Xianyi
There is a call to RESTOREREGISTERS in the kernel/x86/amax_sse.S but no matching earlier call to SAVEREGISTERS. This means that the stack pointer is incorrect when the results are stored and the registers popped after label L999, and the ret tries to jump to a data location instead of back to the calling routine. RESTOREREGISTERS is not called by any other x86 kernel module so is probably safe to remove. Otherwise a SAVEREGISTERS should be inserted at line 79.