A bug in SGESVDX

[slaonetlib]

There looks like a bug in SGESVDX in Lapack3.6.1 (also in 3.6.0):

At the beginning, SGESVDX check the NORM of A and then calls SLASCL to modify the values of the elements if they are extreme (line 506-514). At the end calls SLASCL to adjust back the values of elements of S if A has been modified (line 817-814). The problem is that, in many cases, S is not changed even A is modified. That means that the modification in A does not get transfered into S. There should be no adjustment need for S. And this unnecessary adjustment causes overflow or underflow in many cases. An exampleis:

JOBU='V', JOBVT='V', RANGE='V', N=1, and A and S have some big numbers. A gets modifiled but S does not change (look at the call to SBDSVDX). Calling to SLASCL at the end causes overflow.

Workaround: check if S is changed before calling to SLASCL at the end. This may not be real fix.

Thanks,
Shandong Lao

[oamarques]

I have tried to reproduce the aforementioned experiment: JOBU='V', JOBVT='V', RANGE='V', N=1. I have multiplied A by big numbers (using machine parameters from LAMCH) and GESVDX worked just fine, in single and double precisions. (The scaling done in GESVDX is similar to the one done in GESVD so I am wondering what could go wrong). Could I have the code that is invoking GESVDX and leading to the overflow so I can see what is going on?
Osni

[oamarques]

I was expecting Shandong Lao to send me a code that shows the anomaly he has reported. (Based on his description of the problem, I have not been able to reproduce it.) I suggest we close this bug.
Osni