Calculate CUNMLQ LWORK consistently when K=0

[ndingle-arm]

Description

CUNMLQ's documentation says LWORK must be:

      If SIDE = 'L', LWORK >= max(1,N);
      if SIDE = 'R', LWORK >= max(1,M).

In the current implementation, however, when K=0 a workspace query will return LWORK=1 in WORK(1). This means a subsequent call to CUNMLQ with a workspace of that size will fail with INFO = -12.

The other ???MLQ routines return consistent values of LWORK when K=0 (that is, equal to or greater than NW) so this patch makes CUNMLQ's behaviour match theirs.

Checklist

• The documentation has been updated. No docs update needed -- this makes the implementation match the documentation.
• If the PR solves a specific issue, it is set to be closed on merge. No issue raised to close.

[martin-frbg]

Assuming that the caller then goes ahead and allocates a large work array as told, wouldn't a more efficient alternative be to amend the LWORK size test in CUNMLQ with a special case for K=0 ? (Or simply IF M.EQ.0 .OR. N.EQ.0 .OR. K .EQ.0) NW=0)

[ndingle-arm]

I was unsure why CUNMLQ handles workspace queries differently from ZUNMLQ and DORMLQ/SORMLQ when K=0. Those subroutines do not have the condition:

IF( m.EQ.0 .OR. n.EQ.0 .OR. k.EQ.0 ) THEN lwkopt = 1

so behave in accordance with the API specifications in their documentation (that is, they return a value of LWORK >= MAX(1,M) or MAX(1,N) regardless of the value of K).

Is there a need for CUNMLQ to have this special behaviour when K=0?

[martin-frbg]

Is there a need for CUNMLQ to have this special behaviour when K=0?
There's certainly no need - it just occured to me that it might be a useful optimization to not require a (potentially substantial) work array if it will not be used anyway. But this is beyond the scope of the correction you propose.

[ndingle-arm]

Thank you -- I'm not sure if I need to retrigger something to get the failing check to pass? It was an error in contacting the conda mirror, so nothing to do with the changes in the PR.

[martin-frbg]

Apparently I don't have the necessary permissions to trigger a rerun on Appveyor, so the quickest would be to close&reopen this PR so that all CI jobs get run again

[martin-frbg]

BTW git blame suggests that the differing behavior in CUNMLQ may have been accidental, probably resulting from a local optimization attempt that inadvertently became part of commit 34420f1 in the lapack-3.6.0 timeframe, roughly ten years ago.
(That commit appears to have been mainly concerned with making the work array bigger, to trick compilers into storing it in a thread-safe location. I wonder if this strategy may need revisiting at some point...)