PDSYEVR (ScaLAPACK, LP64) returns INFO=0 with M=0 on a single MPI rank, and prints "DSTEGR2 paramete

[rizzo]

Hello,

I've hit what looks like a defect in MKL's ScaLAPACK `pdsyevr` on a single MPI rank. A self-contained reproducer (two small Fortran programs + the stored matrices) is attached as mkl_pdsyevr_dstegr2_report.zip; REPORT.md inside has the full write-up.

**Summary**

`pdsyevr` ("V", "A", "L"), called on a specific 240x240 real symmetric standard-form matrix on a 1x1 BLACS grid (one MPI process, `OMP_NUM_THREADS=1`), prints an internal diagnostic

```

{ 0, 0}: On entry to

DSTEGR2 parameter number -202 had an illegal value

```

and then returns `INFO = 0` with the eigenvalue count `M = 0` instead of `M = 240`. The eigenvalues written to `W` are nevertheless correct (they agree to machine precision with 2- and 4-process runs of the same matrix), so the computation itself completes; only the returned count `M` is wrong and an unexpected PXERBLA-style message is emitted for an internal routine. The same call on the same matrix at 2 and 4 processes is clean (`INFO = 0`, `M = 240`, no message). The single-rank failure is deterministic — 20 of 20 runs.

**Why I think this is a defect**

1. For `RANGE = "A"`, a successful `pdsyevr` (`INFO = 0`) should return `M = N`. Returning `M = 0` with `INFO = 0` gives the caller no way to detect the failure. A caller that sizes downstream work from `M` — e.g. the number of eigenvector columns to back-transform in a generalized problem — then silently processes zero eigenvectors with no error indication. That is exactly how it first surfaced for me (in a generalized eigenproblem inside a larger application).

2. The parameter index `-202` is not a valid argument position for `DSTEGR2` (it has far fewer than 202 arguments), so this is not a caller-facing argument error; it indicates MKL's internal MRRR path invoked `DSTEGR2` with an argument that failed the routine's own validation. Because the public `pdsyevr` arguments are valid and documented — byte-identical to the 2- and 4-process calls that succeed — the inconsistency is internal to the single-process MRRR code path.

**Environment**

- MKL 2025.3, Product Build 20251007, LP64 interface (`libmkl_scalapack_lp64`, `libmkl_blacs_intelmpi_lp64`, `libmkl_intel_lp64`).

- Threading layer `libmkl_intel_thread` with `OMP_NUM_THREADS=1`.

- Intel MPI (oneAPI 2025.3), `ifx` via `mpiifx`.

- Host: 2x AMD EPYC 9654 (Genoa), Linux.

**Reproducing (from the attached zip)**

```

./build.sh

export OMP_NUM_THREADS=1

mpiexec -n 1 ./mrrr_repro_evr mrrr_aprime.bin # message + INFO=0, M=0

mpiexec -n 2 ./mrrr_repro_evr mrrr_aprime.bin # clean, INFO=0, M=240

mpiexec -n 4 ./mrrr_repro_evr mrrr_aprime.bin # clean, INFO=0, M=240

```

`mrrr_repro_evr` reads one stored 240x240 matrix and makes a single `pdsyevr` call (workspace sized from the `LWORK = -1` / `LIWORK = -1` query, then zero-initialized). Call arguments: `JOBZ="V"`, `RANGE="A"`, `UPLO="L"`, `N=240`, `IA=JA=IZ=JZ=1`, `VL=VU=0.0`, `IL=1`, `IU=240`, block size `MB=NB=32`. A second program, `mrrr_repro`, runs the full `pdsygst(1,"L")` -> `pdsyevr("V","A","L")` sequence from the stored Hamiltonian and Cholesky factor and prints the identical message.

Observed `np = 1` output:

```

Intel(R) oneAPI Math Kernel Library Version 2025.3-Product Build 20251007 for Intel(R) 64 architecture applications

n=240 mb=32 nb=32 nproc=1

pdsyevr query info=0

{ 0, 0}: On entry to

DSTEGR2 parameter number -202 had an illegal value

pdsyevr info=0 m=0

w(1)= -9.252989077474355E-01 w(n)= 9.457626123323363E-01

```

The eigenvalues match the `np = 2` run in the leading digits, confirming the spectrum is computed correctly; only `M` and the spurious message are wrong. The matrix has tightly clustered eigenvalues in this case, which is the regime that stresses the MRRR algorithm `DSTEGR2` implements.

**Question / requested resolution**

Is this a known issue, or is there something in the single-process argument setup I should be doing differently? If it is a defect, I'd expect either (a) `pdsyevr` to return the correct `M = N` on the 1x1 grid and suppress the spurious message, or (b) if the internal argument inconsistency is genuine, for it to surface as a non-zero `INFO` rather than `INFO = 0` with `M = 0`.

Happy to provide any further detail. Thanks.