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.