Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unbalanced stack in x86 amax_sse.S #96

Closed
IanRS opened this issue Apr 25, 2012 · 3 comments
Closed

Unbalanced stack in x86 amax_sse.S #96

IanRS opened this issue Apr 25, 2012 · 3 comments
Labels
Milestone

Comments

@IanRS
Copy link

IanRS commented Apr 25, 2012

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.

@xianyi
Copy link
Collaborator

xianyi commented Apr 25, 2012

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
Copy link
Author

IanRS commented Apr 26, 2012

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:
#96 (comment)

@xianyi xianyi closed this as completed in 5d657c6 Apr 26, 2012
@xianyi
Copy link
Collaborator

xianyi commented Apr 26, 2012

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

martin-frbg added a commit that referenced this issue Oct 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants