Well, apparently CXSPARSE does compute QR decomposition with two outputs, but not with three outputs.

[q,r,p] = qr (speye (3))
q =

  -1   0   0
   0  -1   0
   0   0  -1

r =

Compressed Column Sparse (rows = 3, cols = 3, nnz = 3 [33%])

  (1, 1) -> -1
  (2, 2) -> -1
  (3, 3) -> -1

p = Compressed Column Sparse (rows = 0, cols = 0, nnz = 0)

This is a whole different issue from the one here and I will open a new bug report for that.

Oops, a typo.  I meant without SPQR.

Interestingly, there is a subtle difference.

With SPQR & CHOLMOD:

octave:1> [q,r] = qr (speye (3))
q =

   1   0   0
   0   1   0
   0   0   1

r =

Compressed Column Sparse (rows = 3, cols = 3, nnz = 3 [33%])

  (1, 1) -> 1
  (2, 2) -> 1
  (3, 3) -> 1

With CXSPARSE

octave:1> [q,r] = qr (speye (3))
q =

  -1   0   0
   0  -1   0
   0   0  -1

r =

Compressed Column Sparse (rows = 3, cols = 3, nnz = 3 [33%])

  (1, 1) -> -1
  (2, 2) -> -1
  (3, 3) -> -1

The multiplication of Q and R recovers the original matrix, but with CXSPARSE each of the matrices has been multiplied by -1.

> I'll try building my local version with SPQR and see if it picks up CXSPARSE instead.

I might be misunderstanding that sentence. But to try to reproduce, you might need to configure with `--without-spqr`.

AFAICT, the buildbots that are compiling with clang++ are still using the C++ library from GCC (i.e., libstdc++). So, there is no issue with linking to C++ libraries that are packaged by Debian.
And SPQR is appearing in the configure summary:
https://buildbot.octave.org/#/builders/19/builds/1134/steps/5/logs/stdio

  SPQR CPPFLAGS:                 -I/usr/include/suitesparse
  SPQR LDFLAGS:
  SPQR libraries:                -lspqr

I seem to recall that we intentionally configured the GitHub CI to use the C++ library from LLVM (i.e., libc++) instead to get better coverage.

That GitHub runner should have used CXSparse instead:
https://github.com/gnu-octave/octave/actions/runs/12092031603/job/33721233088#step:8:1171

    CXSPARSE CPPFLAGS:
    CXSPARSE LDFLAGS:
    CXSPARSE libraries:            -lcxsparse

Is it expected that `qr` gives different results depending on whether the internal implementation happens to use SPQR or CXSparse?

It looks like this caused (or revealed?) test errors on the Ubuntu runners using Clang:
https://github.com/gnu-octave/octave/actions/runs/12092031603/job/33721233088#step:13:65340

>>>>> processing /home/runner/work/octave/octave/.build/libinterp/corefcn/qr.cc-tst
***** test <*66488>
 ## Orientation of 'p' output
 [q, r, p] = qr (eye (3));
 assert (size (p), [3, 3]);
 [q, r, p] = qr (speye (3));
 assert (size (p), [3, 3]);
 [q, r, p] = qr (eye (3), 'vector');
 assert (size (p), [1, 3]);
 [q, r, p] = qr (speye (3), 'vector');
 assert (size (p), [1, 3]);
 [q, r, p] = qr (eye (3), 'econ');
 assert (size (p), [3, 3]);
 [q, r, p] = qr (speye (3), 'econ');
 assert (size (p), [3, 3]);
 [q, r, p] = qr (eye (3), 0);
 assert (size (p), [1, 3]);
 [q, r, p] = qr (speye (3), 0);
 assert (size (p), [1, 3]);
!!!!! regression: https://octave.org/testfailure/?66488
ASSERT errors for:  assert (size (p),([3, 3]))

  Location  |  Observed  |  Expected  |  Reason
    (1)           0            3         Abs err 3 exceeds tol 0 by 3
    (2)           0            3         Abs err 3 exceeds tol 0 by 3

Maybe relevant: These runners build without SPQR (because of incompatibilities between libstdc++ that is used by the SPQR library distributed by Ubuntu and libc++ that is used to build Octave on that runner configuration).

With Matlab R2024b:

>> [q,r,p] = qr(speye(3),'econ')

q =

  3×3 sparse double matrix (3 nonzeros)

   (1,1)        1
   (2,2)        1
   (3,3)        1


r =

  3×3 sparse double matrix (3 nonzeros)

   (1,1)        1
   (2,2)        1
   (3,3)        1


p =

  3×3 sparse double matrix (3 nonzeros)

   (1,1)        1
   (2,2)        1
   (3,3)        1

>> [q,r,p] = qr(eye(3),'econ')

q =

     1     0     0
     0     1     0
     0     0     1


r =

     1     0     0
     0     1     0
     0     0     1


p =

     1     0     0
     0     1     0
     0     0     1

>>

Could someone test the following code in Matlab?

[q,r,p] = qr(speye(3),'econ')

Matlab reports:

>> size(zzz)                                                  

ans =                                                         
     3     3  

The main issue I'm worried about is that
  qr( ..., 0) is supposed to be the same as qr( ..., 'vector')
It is for full matrices, but not for sparse.

This lead to a bug in eidors, which we fixed by using the 'vector' form. However, the documentation says they're the same.

qr( ...,0) should be equal to qr( ..., 'vector').
But we have
 [q,r,p]= qr(speye(3),'vector'); size(p) % 3x1, but matlab is 1x3
 [q,r,p]= qr(speye(3),0); size(p)        % 3x3, but matlab is 1x3
However, this is OK for non-sparse qr
 [q,r,p]= qr(eye(3),'vector'); size(p) % 3x1, correct
 [q,r,p]= qr(eye(3),0); size(p)        % 3x1, correct
Tests in octave 9.2:
 [q,r,p]= qr(speye(3)); % correct
 [q,r,p]= qr(eye(3)); % correct