bugGNU Octave - Bugs: bug #57033, Replace CXSPARSE with SPQR

 
 

bug #57033: Replace CXSPARSE with SPQR

Submitter:  Rik <rik5>
Submitted:  Thu 10 Oct 2019 04:57:19 PM UTC
   
 
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 07 Feb 2021 10:41:06 AM UTC, comment #49: 

I pushed another change that considers SPQR's dependency on the cholmod library in the configure check:
https://hg.savannah.gnu.org/hgweb/octave/rev/2a4998b97990

Markus Mützel <mmuetzel>
Group administrator
Sat 09 Jan 2021 10:39:12 AM UTC, comment #48: 

The major issues seem to be ironed out. So I'll close this report as fixed.
If new, undiscovered issues should arise, new reports could be opened, or we could re-open this report.

Markus Mützel <mmuetzel>
Group administrator
Thu 07 Jan 2021 03:51:30 PM UTC, comment #47: 

I took a stab at option 1 because I figured that we'd probably need many of the changes anyway.
Because the matrix type conversion functions that previously were added to liboctave/util/oct-sparse.cc are quite specific for being used with SPQR after these changes, I moved them to liboctave/numeric/sparse-qr.cc and made them static in that file.

After these changes, Octave compiles and passes the test suite on my 64bit Ubuntu Linux when it is configured for 64bit indices or for 32bit indices. (I haven't tried to build for 32bit Windows. But I hope that'll work, too.)

Since this fixes some build issues, and we can also rename functions or move them around in follow up changes, I pushed to the default branch here:
https://hg.savannah.gnu.org/hgweb/octave/rev/fed765133d53

I hope this concludes the most important changes for the bug here.

Markus Mützel <mmuetzel>
Group administrator
Thu 07 Jan 2021 02:37:21 PM UTC, comment #46: 

I'm okay with resolving this in the most straightforward way possible.  It seems easiest to just detect at configure/compilation time that this is a mixed 64-bit/32-bit system and disable SPQR and use CXSPARSE instead.

Rik <rik5>
Group administrator
Thu 07 Jan 2021 12:05:57 PM UTC, comment #45: 

It turned out that bug #59833 was caused by the issue discussed here in the last comments.

After the change from comment #44, Octave successfully compiles on 64bit systems when it was configured with `--disable-64`. However, `qr` fails with error -4 (CHOLMOD_INVALID /* failure: invalid input */).

It turns out SPQR requires the integer type to be long:
https://github.com/DrTimothyAldenDavis/SuiteSparse/blob/master/SPQR/Include/spqr.hpp#L125

// Return if Common is NULL or invalid
#define RETURN_IF_NULL_COMMON(result) \
{ \
    if (cc == NULL) \
    { \
        return (result) ; \
    } \
    if (cc->itype != ITYPE || cc->dtype != DTYPE) \
    { \
        cc->status = CHOLMOD_INVALID ; \
        return (result) ; \
    } \
}


Where ITYPE is unconditionally defined to CHOLMOD_LONG:
https://github.com/DrTimothyAldenDavis/SuiteSparse/blob/master/SPQR/Include/spqr.hpp#L95

Atm, I see the following options:

  1. Copy over all integers to arrays of the correct type and use the cholmod functions for long integers unconditionally (instead of the ones matching Octave's integer type using `CHOLMOD_NAME`). Copy the result back over to Octave's integer type (performing the necessary checks).
  2. Don't use SPQR if Octave uses 32bit indices on 64bit systems. Fall back to CXSparse instead.
  3. Leave it as is (after the compilation bug is fixed). I.e., display the error if the user calls `qr` and we try to use SPQR. That would mean that `qr` would cease to be able to solve some input it was previously able to solve.
Markus Mützel <mmuetzel>
Group administrator
Wed 06 Jan 2021 11:38:38 PM UTC, comment #44: 

The attached patch adds more checks on converting between different integer types and uses the necessary integer pointer types.

I'm unsure where to add the new function `from_size_t` and whether that is a good name for a function that checks whether the input can be safely converted from `size_t` to `octave_idx_type`.
The function `from_suitesparse_long` is probably in the correct file (oct-sparse.h). But same doubt about the name.

Compiles for me with gcc on Ubuntu, and the test suite passes.
I haven't tested if this would fix building for the Win32 target.

(file #50671)

Markus Mützel <mmuetzel>
Group administrator
Wed 06 Jan 2021 09:15:55 PM UTC, comment #43: 

Replying to comment #41:

Correct, you can't just cast an array of int32 to be an array of int64.  So yes, we have to make a copy if the sizes don't match and check that values are in range if copying array values from a larger type to a smaller type.

The const_cast could also a be trouble if this function really can modify its argument.  And if it doesn't, then why are we casting away const here?

John W. Eaton <jwe>
Group administrator
Wed 06 Jan 2021 09:15:01 PM UTC, comment #42: 

Please, dis-regard the last sentence of the last comment. I confused myself. CHOLMOD (and possibly other SuiteSparse libraries) has functions for long and "normal" integers. We just use the ones that match Octave's index type.

SuiteSparse seems to have functions only for long integers. So the main part of that comment still is valid, I think...

Markus Mützel <mmuetzel>
Group administrator
Wed 06 Jan 2021 09:08:34 PM UTC, comment #41: 

I tried to implement something like outlined in comment #40.

The member m_E is passed as an argument to functions from SPQR and from CXSparse.
For SPQR: https://hg.savannah.gnu.org/hgweb/octave/file/d8cb0f06ffb1/liboctave/numeric/sparse-qr.cc#l263

      SuiteSparseQR<double> (order, SPQR_DEFAULT_TOL, A.nrow,
                             const_cast<cholmod_sparse*> (&A), &m_R, &m_E, &m_H,
                             &m_HPinv, &m_Htau, &m_cc);

With the signature:

template <typename Entry> SuiteSparse_long SuiteSparseQR
(
    // inputs, not modified
    int ordering,           // all, except 3:given treated as 0:fixed
    double tol,             // only accept singletons above tol
    SuiteSparse_long econ,  // number of rows of C and R to return
    cholmod_sparse *A,      // m-by-n sparse matrix
    // outputs
    cholmod_sparse **R,     // the R factor
    SuiteSparse_long **E,   // permutation of 0:n-1, NULL if identity
    cholmod_sparse **H,     // the Householder vectors (m-by-nh)
    SuiteSparse_long **HPinv,// size m; row permutation for H
    cholmod_dense **HTau,   // size nh, Householder coefficients
    cholmod_common *cc      // workspace and parameters
) ;

(Some `static_cast`s seem to be missing here in our code.)

For CXSparse: https://hg.savannah.gnu.org/hgweb/octave/file/d8cb0f06ffb1/liboctave/numeric/sparse-qr.cc#l700

          CXSPARSE_DNAME (_ipvec)
            (m_E, &(static_cast<double*> (QTB->x)[j * b_nr]), &x_vec[j * ncols],
             ncols);

With the signature (for systems with OCTAVE_ENABLE_64 not defined):

int cs_di_ipvec (const int *p, const double *b, double *x, int n) ;


So `m_E` must be of type `SuiteSparse_long*` (i.e. convertible to `ptrdiff_t*`) for the one function and `int*` for the other. On 64bit systems, those types are incompatible.
The only solution I can think of at the moment is copying the content of m_E to a new array of the correct type.
Is there a better solution?

If OCTAVE_ENABLE_64 is defined, the signature of the used function is:

cs_long_t cs_dl_ipvec (const cs_long_t *p, const double *b, double *x, cs_long_t n) ;

where `cs_long_t` is `SuiteSparse_long`.
So the types coincidently match.


Also, thinking about it, I'm no longer sure if our definition of `octave::suitesparse_integer` is correct. At least, if the intent was to follow CHOLMOD's BLAS_INT (which looks eerily similar), the conditions shouldn't be OCTAVE_ENABLE_64, but rather whether OCTAVE_SIZEOF_F77_INT_TYPE is 4 or 8...

Markus Mützel <mmuetzel>
Group administrator
Wed 06 Jan 2021 07:54:52 PM UTC, comment #40: 

I don't have an overview over all SuiteSparse libraries we are using and how they handle integers. So, I don't know why `octave::suitesparse_integer` is defined the way it is. But it doesn't look like that definition is correct for SPQR.
On the other hand, CHOLMOD has the following "define"s in its headers:

#if defined (LONGBLAS) || defined (BLAS64)
#define BLAS_INT SuiteSparse_long
#else
#define BLAS_INT int
#endif


It looks like we are following what CHOLMOD calls `BLAS_INT` with our `octave::suitesparse_integer`. Changing the definition of `octave::suitesparse_integer` to always match `SuiteSparse_long` would probably break how we are using CHOLMOD.

SPQR doesn't seem to have a dedicated type for Fortran integers. It might still be saver to check that we don't pass indices that would be too large for Fortran. But I'm not sure if that is necessary...

I'm more worried about conversions from `SuiteSparse_long` to `octave_idx_type` instead of the other way round because the former might have a larger size than the latter. IIUC, `SuiteSparse_long` has at least the same size as `octave_idx_type`.
While dense matrices of that size would probably quickly cause memory issues, large sparse matrices might be more common...

We have `to_suitesparse_intptr` and `to_octave_idx_type_ptr` for conversions between suitesparse_int* and octave_idx_type*. These functions throw an error if the sizes of these integer types don't match.
We could add similar functions for conversions between SuiteSparse_long* and octave_idx_type*. But that would mean that users would see errors if Octave's index size wouldn't match the pointer size on their system.
IIRC, we support that configuration, do we?

When we are copying over element-by-element from SuiteSparse_long arrays to an Octave array, a function that is similar to `to_f77_int` could be helpful (probably checking against flintmax<double>, i.e. 2^53?).

Markus Mützel <mmuetzel>
Group administrator
Wed 06 Jan 2021 04:25:48 PM UTC, comment #39: 

I don't know that we have a separate function for this action now, but I guess it should be similar to the to_f77_int function defined in the liboctave/util/f77-fcn.h

Are there different types of integers used in SuiteSparse?  Maybe the definition of octave::suitesparse_integer just needs to be adjusted to match the definition of SuiteSparse_long?  Of course, we may still need to check for overflow when converting from octave_idx_type to suitesparse_integer, similar to the checks made when converting to F77_INT.

John W. Eaton <jwe>
Group administrator
Wed 06 Jan 2021 11:25:33 AM UTC, comment #38: 

The 32bit Windows builds are failing with this change.
The reason is that the index (permutation) arguments of the functions in SPQR are pointers to `SuiteSparse_long`. That type is defined by SuiteSparse to have the same size as `ptrdiff_t` on all platforms. They seem to be using `int64_t` for Win64 and `long` for all other platforms.
In our code, we are using pointers to `octave::suitesparse_integer` which we define to either `SuiteSparse_long` for OCTAVE_ENABLE_64 or `int` otherwise.
Even if `long` and `int` have the same size for win32 targets (ILP32), the compiler fails on implicitly casting the respective pointers.
That cast would really be safe for win32 targets.

On the other hand, when building for a 64bit target with Octave's indexing type being set to 32bit, assignments from type `SuiteSparse_long` to `octave_idx_type` should be carefully checked. It doesn't look like this is done currently.

Do we already have functions that could be used for both of these issues?

Markus Mützel <mmuetzel>
Group administrator
Tue 05 Jan 2021 01:11:29 PM UTC, comment #37: 

I should have tested again with CXSparse after I made the changes to fix compilation without CXSparse.

Follow-up change here:
https://hg.savannah.gnu.org/hgweb/octave/rev/18ad3c01fc2a

Markus Mützel <mmuetzel>
Group administrator
Tue 05 Jan 2021 12:44:38 PM UTC, comment #36: 

Re comment #32: Some member functions of the sparse_qr_rep class don't have implementations with SPQR (only with CXSPARSE). I don't know if it's principally impossible to replace those implementations using SPQR or if this just isn't done yet.
For a test, I marked all tests that are conditional on HAVE_CXSPARSE in qr.cc with the runtime condition you propose, configured with `--without-cxsparse` and ran the test suite.
This also revealed some other issues. (I'll probably push a separate patch and/or open a new report for those.)
All of the BISTs in qr.cc however still passed. I guess that either those member functions aren't used (and could be removed?) or we just don't have BISTs for them.
Anyway, I opted to adopt the solution you proposed.

Re comment #33: I guess that is settled then. :-)

Re comment #34: I don't know how different distributions organize and install the SuiteSparse headers. Just looking at how we test for the other SuiteSparse library headers, it looks like we should check other locations, too. But I guess, it would also be ok to wait for complaints.

Re comment #35: I'll leave that for follow up changes.

The patch still isn't perfect. But imho, it is a big improvement compared to what we have currently. So, I pushed it here:
https://hg.savannah.gnu.org/hgweb/octave/rev/66f162b6fa03

Thanks again to Simon Hau who did the hard lifting with the initial implementation.

Markus Mützel <mmuetzel>
Group administrator
Tue 05 Jan 2021 12:15:52 AM UTC, comment #35: 

Regarding issue #4, negative array dimensions: Although the C++ for a dim_vector is made of octave_idx_type which is an int type and can therefore be negative, no array dimension should be negative.  If you try then a zero is substituted, at least in the parts of Octave I checked.  For example,


size (ones (2,3, -2, 4))
ans = [2 3 0 4]


Rik <rik5>
Group administrator
Mon 04 Jan 2021 11:23:53 PM UTC, comment #34: 

Regarding issue #3, extra locations for header file: Do we know that this is an issue?  Or do we only suspect this is an issue?  Unless we know there is a problem, the easiest thing to do would be to just use the existing code.  If user's find that they can't compile there will be complaints on the bug tracker and we can then verify what other locations need to be added.

Rik <rik5>
Group administrator
Mon 04 Jan 2021 11:21:07 PM UTC, comment #33: 

Regarding issue #2, a templated test to detect the SPQR library: is that really necessary?  We just need to determine that the SPQR library is present and if there are 100 functions in the library we can use any one of them to detect the libraries presence.  We don't actually have to test for the function we are using from the library.

Rik <rik5>
Group administrator
Mon 04 Jan 2021 11:18:38 PM UTC, comment #32: 

Regarding issue #1, duplicate BIST tests: it was my understanding that using SPQR is not just higher performance, it actually gets the correct answer.  If this is the case then one choice would be to drop support for CXSPARSE and only support SPQR.  If that change is made then we can easily change the BIST tests to


%!testif HAVE_SPQR


If that is not possible then we can still just use one BIST test, but we can't use a static test for a library because the syntax for %!testif only supports ANDing of multiple libraries.  In that case, we can change to a runtime configuration test.


%!testif ; __have_feature__ ("SPQR") || __have_feature__ ("CXSPARSE")


Rik <rik5>
Group administrator
Mon 04 Jan 2021 11:01:39 PM UTC, comment #31: 

In one sense I'm not surprised.  At one point I cleaned up a bunch of memory issues related to cholmod that were pointed out by the ASAN leak detector.  This was in 2016 and 2017.

At this point, I think it is worthwhile to commit the changes to the development branch and continue further work there.  Otherwise, the sources are going to continue to drift away from the patch and require another rebasing operation.

This bug report can remain open while we address the issues raised in comment #30.

Rik <rik5>
Group administrator
Mon 04 Jan 2021 08:19:19 PM UTC, comment #30: 

I believe I finally found the reason for the crashes: There was a double free of the cholmod_common object in some of the member functions and the sparse_qr_rep class destructor.
After fixing that, the test suite and the commands from comment #16 no longer cause a crash.

I rebased the patch to the current tip, cleaned it up a bit more and added the API tags.

The following issues are still open:
- BISTs are duplicated for HAVE_CXSPARSE and HAVE_SPQR.
- A better configure check is needed that checks for the templated function `SuiteSparseQR_min2norm<double>` (instead of checking for the function `SuiteSparseQR_C`).
- Should we check for the header in more locations (e.g. SuiteSparseQR.hpp, ufsparse/SuiteSparseQR.hpp, spqr/SuiteSparseQR.hpp, ...)?
- I'm not sure if an array dimension can ever be negative. Maybe the respective error messages should be re-worded.
- It feels a little bit like the private static member function `min2norm_solve` isn't really a member function of the `sparse_qr`. Instead, its implementation is completely independent of that class. I'm not sure if it should be a member of that class or a standalone function. But maybe that is the nature of a static member function...

Anyway, attached is a new version of the patch.

(file #50648)

Markus Mützel <mmuetzel>
Group administrator
Sat 12 Sep 2020 09:55:08 AM UTC, comment #29: 

I tested the patch again by applying file #48691 on top of hg id 07c0df93ff9d.
In the meantime, I updated to Ubuntu 20.04.1 which packages suitesparse 5.7.1.
Running the following commands still crashes Octave:

a = [0, 2, 1; 2, 1, 2];
[q, r] = qr (a);
n = 20;  d = 0.2;
a = sprandn (n,n,d) + speye (n,n);
[c,r] = qr (a, ones (n,1));


Part of the "gdb" output is:

octave:1> a = [0, 2, 1; 2, 1, 2];
octave:2> [q, r] = qr (a);
octave:3> n = 20;  d = 0.2;
octave:4> a = sprandn (n,n,d) + speye (n,n);
octave:5> [c,r] = qr (a, ones (n,1));

Thread 6 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe8a91700 (LWP 611210)]
__GI___libc_free (mem=0xffff00001fa0) at malloc.c:3102
3102        malloc.c: No such file or directory.
(gdb) bt
#0  __GI___libc_free (mem=0xffff00001fa0) at malloc.c:3102
#1  0x00007ffff2ba36b7 in SuiteSparse_free () at /usr/lib/x86_64-linux-gnu/libsuitesparseconfig.so.5
#2  0x00007ffff2c6eb7d in cholmod_l_free () at /usr/lib/x86_64-linux-gnu/libcholmod.so.3
#3  0x00007ffff2c6994b in cholmod_l_free_work () at /usr/lib/x86_64-linux-gnu/libcholmod.so.3
#4  0x00007ffff5d7d21a in octave::math::sparse_qr<SparseMatrix>::sparse_qr_rep::~sparse_qr_rep() (this=0x7fffd8201290, __in_chrg=<optimized out>)
    at ../liboctave/numeric/sparse-qr.cc:346
#5  0x00007ffff5d88ef1 in octave::math::sparse_qr<SparseMatrix>::~sparse_qr() (this=<optimized out>, __in_chrg=<optimized out>) at ../liboctave/numeric/sparse-qr.cc:2782
#6  octave::math::sparse_qr<SparseMatrix>::~sparse_qr() (this=<optimized out>, __in_chrg=<optimized out>) at ../liboctave/numeric/sparse-qr.cc:2782
#7  0x00007ffff7708cdb in Fqr(octave_value_list const&, int) (args=..., nargout=<optimized out>) at ../liboctave/array/MSparse.h:74
#8  0x00007ffff6fa277d in octave_builtin::execute(octave::tree_evaluator&, int, octave_value_list const&) (this=0x7fffd80e2cf0, tw=..., nargout=2, args=...)
    at ../libinterp/octave-value/ov-builtin.cc:59
#9  0x00007ffff7008c22 in octave_function::call(octave::tree_evaluator&, int, octave_value_list const&) (this=0x7fffd80e2cf0, tw=..., nargout=2, args=...)
    at ../libinterp/octave-value/ov-fcn.cc:57
#10 0x00007ffff71e40fc in octave::tree_index_expression::evaluate_n(octave::tree_evaluator&, int) (this=0x7fffd81f1390, tw=..., nargout=2)
    at ../libinterp/parse-tree/pt-idx.cc:526
#11 0x00007ffff71b6609 in octave::tree_multi_assignment::evaluate_n(octave::tree_evaluator&, int) (this=0x7fffd8455440, tw=...) at ../libinterp/parse-tree/pt-assign.cc:201
#12 0x00007ffff71b90a0 in octave::tree_multi_assignment::evaluate(octave::tree_evaluator&, int) (this=<optimized out>, tw=..., nargout=<optimized out>)
    at ../libinterp/parse-tree/pt-assign.h:163


So nothing seems to have changed with the newer upstream packages.

Interestingly, I can't reproduce with a debug build configured with these flags:

../configure CPPFLAGS=-I/usr/include/hdf5/serial LDFLAGS="-L/usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/hdf5/serial" --prefix=${HOME}/usr FFLAGS=-g CFLAGS=-g CXXFLAGS=-g


So could it be some compiler optimization is causing this? Any way to prevent that?

@Simon: Are you able to reproduce in the meantime?

Markus Mützel <mmuetzel>
Group administrator
Fri 11 Sep 2020 11:32:31 PM UTC, comment #28: 

I pushed the following changeset on stable and merged with default:

http://hg.savannah.gnu.org/hgweb/octave/rev/2c367a9c9660

That should fix the problem with onCleanup in the qr.cc-tst file.

John W. Eaton <jwe>
Group administrator
Fri 11 Sep 2020 08:41:48 AM UTC, comment #27: 

Thanks.
I opened bug #59097 for that issue.

Markus Mützel <mmuetzel>
Group administrator
Thu 10 Sep 2020 01:50:55 PM UTC, comment #26: 

octave:2> test qr.cc-tst
PASSES 57 out of 57 tests
warning: onCleanup: error caught while executing cleanup function:
'restore_rand_states' undefined near line 7, column 7
octave:3> _octave_config_info_ ("hg_id")
ans = c435048c2796


No it is with better hg_id...

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Thu 10 Sep 2020 01:47:06 PM UTC, comment #25: 

I still get the warning with the stable branch (if that is what you are asking):

octave:1> _octave_config_info_ ("hgid")
error: _octave_config_info_: no info for 'hgid'
octave:2> test qr.cc-tst
PASSES 57 out of 57 tests
warning: onCleanup: error caught while executing cleanup function:
'restore_rand_states' undefined near line 7, column 7
octave:3>

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 10 Sep 2020 08:01:18 AM UTC, comment #24: 

@Dmitri: Does the test in comment #22 still fail for you?

Markus Mützel <mmuetzel>
Group administrator
Sat 09 May 2020 10:00:05 AM UTC, comment #23: 

@Dmitri: jwe is currently working on a rewrite for the function handle class in bug #57439. Maybe that will also fix the bug you describe in comment #22.
If it won't, we should open another bug report for that.

Markus Mützel <mmuetzel>
Group administrator
Fri 01 May 2020 06:44:15 PM UTC, comment #22: 

BTW, without the patch I get the worning



octave:1> test qr.cc-tst
PASSES 57 out of 57 tests
warning: onCleanup: error caught while executing cleanup function:
'restore_rand_states' undefined near line 7, column 7
octave:2>


Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Fri 01 May 2020 05:51:42 PM UTC, comment #21: 

On CentOS 8.1 I get SegFault during make check:


 libinterp/corefcn/psi.cc-tst ................................... pass   30/30
  libinterp/corefcn/qr.cc-tst ....................................fatal: caught signal Segmentation fault -- stopping myself...
/bin/sh: line 1: 29100 Segmentation fault      (core dumped) /bin/sh ../run-octave --no-init-file --silent --no-history -p /home/dima/src/octave/gcc_def/test/mex /home/dima/src/octave/gcc_def/../test/fntests.m /home/dima/src/octave/gcc_def/../test
make[3]: *** [Makefile:31569: check-local] Error 139
make[3]: Leaving directory '/home/dima/src/octave/gcc_def'
make[2]: *** [Makefile:27706: check-am] Error 2
make[2]: Leaving directory '/home/dima/src/octave/gcc_def'
make[1]: *** [Makefile:27414: check-recursive] Error 1
make[1]: Leaving directory '/home/dima/src/octave/gcc_def'
make: *** [Makefile:27708: check] Error 2


The coredump in logs:


May 01 13:40:45 ryzen systemd-coredump[2955]: Process 1761 (lt-octave-gui) of user 1001 dumped core.

                                              Stack trace of thread 1761:
                                              #0  0x00007fde3f741f01 _ZN11QMetaObject12invokeMethodEP7QObjectPKcN2Qt14ConnectionTypeE22QGenericReturnArgument16QGenericArgumentS7_S7_S7_>
                                              #1  0x00007fde42324970 n/a (/home/dima/src/octave/gcc_def/libgui/.libs/liboctgui.so.6.0.0)
May 01 13:46:34 ryzen systemd[1]: Started Process Core Dump (PID 29580/UID 0).
May 01 13:46:34 ryzen systemd-coredump[29581]: Process 29100 (lt-octave-gui) of user 1001 dumped core.

                                               Stack trace of thread 29242:
                                               #0  0x00007f68158d3f21 __libc_free (libc.so.6)
                                               #1  0x00007f681b50f227 SuiteSparse_free (libsuitesparseconfig.so.4)
                                               #2  0x00007f681c482fca cholmod_l_free (libcholmod.so.3)
                                               #3  0x00007f681c47aa37 cholmod_l_free_work (libcholmod.so.3)
                                               #4  0x00007f681f18a121 n/a (/home/dima/src/octave/gcc_def/liboctave/.libs/liboctave.so.8.0.0)
                                               #5  0x00007f68227e46c8 n/a (/home/dima/src/octave/gcc_def/libinterp/.libs/liboctinterp.so.8.0.0)


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 01 May 2020 05:21:31 PM UTC, comment #20: 

I tried again after wiping ccache's cache (in case it was corrupt somehow). After that, I followed the same steps that you listed in comment #19 but I applied the patch (bug57033_spqr_rev6.patch) on top of hg id 18bd65ad4e7d.

Octave still crashes during "make check". Also the minimal steps from comment #16 still cause a crash.

I don't see any obvious differences in the config.log file either.
You are using Java 8, I have Java 11. But that shouldn't make a difference.

It would be interesting to know if anyone else is seeing the same crash or if it is just me.

Markus Mützel <mmuetzel>
Group administrator
Fri 01 May 2020 02:59:34 PM UTC, comment #19: 

I executed the following steps inside my Octave repository
*) reverted all changes
*) updated to changeset 1f07b80db239
*) applied the patch
*) called ./bootstrap
*) created a .build directory

cd .build
 ../configure CPPFLAGS=-I/usr/include/hdf5/serial LDFLAGS="-L/usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/hdf5/serial"
make all -j3
./run-octave

 
All tests in .build/libinterp/corefcn/qr.cc-tst and
.build/libinterp/corefcn/sparse.cc-tst passed. The minimal steps to reproduce the error didn't cause problems.

I attached my config.log and a diff of our log files. Most of the differences are based on different tmp-file names, directory names etc. We use slightly different kernel-releases and you use the ccache tool. I also searched the diff for "spqr" and "suitesparse" but the result didn't help me.

(file #48982)

Simon <sim79>
Thu 16 Apr 2020 12:03:55 PM UTC, comment #18: 

I'm on Ubuntu 19.10, too, with the same SuiteSparse packages:

$ apt list --installed *suitesparse*
Listing... Done
libsuitesparse-dev/eoan,now 1:5.4.0+dfsg-1 amd64 [installed,automatic]
libsuitesparseconfig5/eoan,now 1:5.4.0+dfsg-1 amd64 [installed,automatic]
$ apt list --installed *spqr*
Listing... Done
libspqr2/eoan,now 1:5.4.0+dfsg-1 amd64 [installed,automatic]


I applied the patch again on top of hg id 1f07b80db239.
With that, Octave still crashes with a segmentation fault for the steps in comment #16.

I used the following commands to build in a subfolder ".build":

../configure CPPFLAGS=-I/usr/include/hdf5/serial LDFLAGS="-L/usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/hdf5/serial"
make all -j3


I'll also attach my config.log in case that will help to find differences between our systems.

IICU, the error message you are seeing says that the manual couldn't be build.
Maybe someone else has a better idea. But if that happened to me, I'd try a "make maintainer-clean", "bootstrap", "configure", "make all" cycle to see if that fixes the issue.

(file #48847)

Markus Mützel <mmuetzel>
Group administrator
Thu 16 Apr 2020 10:06:24 AM UTC, comment #17: 

I couldn't reproduce the error. I applied the rev6-patch to changeset 8619dc0d3749. My OS is Ubuntu 19.10 and suitesparse-version is 5.4.0, see following apt-cache-output

Package: libsuitesparse-dev
Architecture: amd64
Version: 1:5.4.0+dfsg-1
Source: suitesparse


If I call "make check RUN_OCTAVE_OPTIONS=-g",  I get this output

make  check-recursive
make[1]: Entering directory '/home/simon/octave_src/octave'
Making check in libgnu
make[2]: Entering directory '/home/simon/octave_src/octave/libgnu'
make  check-recursive
make[3]: Entering directory '/home/simon/octave_src/octave/libgnu'
make[4]: Entering directory '/home/simon/octave_src/octave/libgnu'
make[4]: Nothing to be done for 'check-am'.
make[4]: Leaving directory '/home/simon/octave_src/octave/libgnu'
make[3]: Leaving directory '/home/simon/octave_src/octave/libgnu'
make[2]: Leaving directory '/home/simon/octave_src/octave/libgnu'
make[2]: Entering directory '/home/simon/octave_src/octave'
  TEXI2DVI doc/interpreter/octave.dvi
/usr/bin/texi2dvi: etex exited with bad status, quitting.
make[2]: *** [Makefile:31085: doc/interpreter/octave.dvi] Error 1
make[2]: Leaving directory '/home/simon/octave_src/octave'
make[1]: *** [Makefile:27415: check-recursive] Error 1
make[1]: Leaving directory '/home/simon/octave_src/octave'
make: *** [Makefile:27709: check] Error 2

gdb is not started although it is available on my system. Looking at the lines 27415 and 27709 of the makefile didn't help me. I searched the makefile for the string "RUN_OCTAVE_OPTIONS" and came to the (possibly wrong) conclusion that "make check RUN_OCTAVE_OPTIONS=-g" executes

../run-octave -g  --no-init-file --silent --no-history -p /home/simon/octave_src/octave/test/mex /home/simon/octave_src/octave/test/fntests.m /home/simon/octave_src/octave/test

inside the test-directory of the Octave-repository. If I execute this command, gdb starts and the tests in qr.cc-tst and sparse.cc-tst pass without errors. 
I also executed the minimal steps to reproduce the error. But they didn't cause any problems.

Can you give me additional information to reproduce the error?

Simon <sim79>
Sun 29 Mar 2020 10:41:06 AM UTC, comment #16: 

The test suite is crashing with a segfault on this test:

%!testif HAVE_CXSPARSE
%! n = 20;  d = 0.2;
%! ## initialize generators to make behavior reproducible
%! rand ("state", 42);
%! randn ("state", 42);
%! a = sprandn (n,n,d) + speye (n,n);
%! [c,r] = qr (a, ones (n,1));
%! assert (r\c, full (a)\ones (n,1), 10e-10);


Running the test alone doesn't crash Octave for me.
Minimal steps to reproduce for me are:

a = [0, 2, 1; 2, 1, 2];
[q, r] = qr (a);
n = 20;  d = 0.2;
a = sprandn (n,n,d) + speye (n,n);
[c,r] = qr (a, ones (n,1));


Digging a little bit with gdb, the segfault occurs on the attempt to free "cc->Flag".
It could be that something isn't correctly cleaned up for the dense case. Or some initialization is missing for the sparse case.
I'm no suitesparse expert though.


Wrt the testif syntax: Are you sure the complex syntax with "||" works before the semicolon? I only found it used after the semicolon.
I could only find examples where HAVE_* feature tests are combined with a comma, which seems to imply an "&&".
Testing the syntax, any symbol can be used to separate the HAVE_* features, and they all are interpreted as "&&" (including "||").

Markus Mützel <mmuetzel>
Group administrator
Sat 28 Mar 2020 08:24:57 PM UTC, comment #15: 

I think from Octave's perspective the underlying library shourdn't matter.  Hence, the BIST tests for qr() or whatever function should be executed if either CXSPARSE or SPQR is available.

The %!test syntax supports complex expressions such as


%!testif HAVE_CXSPARSE || HAVE_SPQR


But, first thing is that the code shouldn't segfault.

Rik <rik5>
Group administrator
Sat 28 Mar 2020 12:47:03 PM UTC, comment #14: 

Thanks for the update.

The attached patch includes some minor style review (mostly white spaces) and restores the lost commit message.

It compiles without errors. But crashes during "make check".
Running the test suite with gdb ("make check RUN_OCTAVE_OPTIONS=-g"), I see the following top of the back trace when the crash occurs:

(gdb) bt
#0  0x00007ffff518a8a0 in __GI___libc_free (mem=0xffff00001fbf) at malloc.c:3102
#1  0x00007ffff2e2d733 in SuiteSparse_free () at /usr/lib/x86_64-linux-gnu/libsuitesparseconfig.so.5
#2  0x00007ffff2ef78ea in cholmod_l_free () at /usr/lib/x86_64-linux-gnu/libcholmod.so.3
#3  0x00007ffff2ef281f in cholmod_l_free_work () at /usr/lib/x86_64-linux-gnu/libcholmod.so.3
#4  0x00007ffff5e742da in octave::math::sparse_qr<SparseMatrix>::sparse_qr_rep::~sparse_qr_rep() (this=0x7fffcd0a6090, __in_chrg=<optimized out>) at ../liboctave/numeric/sparse-qr.cc:346
#5  0x00007ffff5e7ffb1 in octave::math::sparse_qr<SparseMatrix>::~sparse_qr() (this=<optimized out>, __in_chrg=<optimized out>) at ../liboctave/numeric/sparse-qr.cc:2782
#6  0x00007ffff5e7ffb1 in octave::math::sparse_qr<SparseMatrix>::~sparse_qr() (this=<optimized out>, __in_chrg=<optimized out>) at ../liboctave/numeric/sparse-qr.cc:2782
#7  0x00007ffff774c2ab in Fqr(octave_value_list const&, int) (args=..., nargout=<optimized out>) at ../liboctave/array/MSparse.h:74
#8  0x00007ffff70592b0 in octave_builtin::call(octave::tree_evaluator&, int, octave_value_list const&) (this=<optimized out>, tw=..., nargout=2, args=...)
    at ../libinterp/octave-value/ov-builtin.cc:65
#9  0x00007ffff7248141 in octave::tree_index_expression::evaluate_n(octave::tree_evaluator&, int) (this=0x7fffcd0bf9d0, tw=..., nargout=2) at /usr/include/c++/9/ext/new_allocator.h:89


This is with Ubuntu 19.10 and suitesparse 5.4.0.

One more doubt I have: Should the BISTs that depend on CXSPARSE be replicated for SPQR so that they run on systems with SPQR but without CXSPARSE?

(file #48691)

Markus Mützel <mmuetzel>
Group administrator
Fri 13 Mar 2020 10:53:10 PM UTC, comment #13: 

added documentation of new features to doc string

(file #48596)

Simon <sim79>
Sun 23 Feb 2020 02:25:51 PM UTC, comment #12: 

"qr.cc" was moved from dldfcn to corefcn. That caused the patch to no longer apply cleanly.
The attached patch is rebased on the current tip of the default branch. It also cleans up some minor issues (like reverted copyright blocks).

It compiles for me and all BISTs pass.

Could you please add some documentation of the new features to the doc string of qr?

(file #48481)

Markus Mützel <mmuetzel>
Group administrator
Fri 10 Jan 2020 03:39:18 PM UTC, comment #11: 

This is good.  I don't think I can fit it in to the 6.1 release, but immediately afterwards.

Rik <rik5>
Group administrator
Fri 10 Jan 2020 12:22:23 AM UTC, comment #10: 

I appended a new patch (it contains rev2-patch).

Changes:
Economy versions of C, Q and R are returned if qr(...,0) is called.
Column permutation of A is returned as (vector|matrix) if qr(...,("vector"|"matrix")) is called.
Additional tests if HAVE_SPQR is set.

(file #48196)

Simon <sim79>
Mon 30 Dec 2019 01:47:45 PM UTC, comment #9: 

I appended bug57033_spqr_rev2.patch. Tests in qr.cc-tst and sparse.tst are passed, but some warnings are issued.

Changes:
1) Removed fill-reducing ordering for calls [R] = qr(A), [Q,R] = qr(A) and [C,R] = qr(A,B).
2) If last argument of qr is "vector", a permutation vector is returned. Otherwise a permutation matrix is returned.

(file #48139, file #48140)

Simon <sim79>
Sat 14 Dec 2019 01:29:10 AM UTC, comment #8: 

It would be nice to have a review soon.  Otherwise, it won't be able to make it in to the 6.1 release.

Rik <rik5>
Group administrator
Sun 01 Dec 2019 04:03:54 PM UTC, comment #7: 

I cleaned up your patch (mostly white space changes) and wanted to push it.
To silence the shadowing warnings, I renamed the local variable "S" and removed the property "econ" that doesn't seem to be used.

Unfortunately with the patch, some of the tests for "qr" fail. I attached a log file with the failing tests. Could you please have a look?
Could you also please base any changes on the attached patch? It took a considerable amount of time to get there.

Do you want to be added to the list of contributors at the beginning of the manual?

(file #47957, file #47958)

Markus Mützel <mmuetzel>
Group administrator
Fri 18 Oct 2019 09:16:30 PM UTC, comment #6: 

Hello,
here are some additional notes on the test script.

Let A be a sparse m x n matrix. The test script is divided into four sections.
In the first section the QR-factorization [Q,R,E] = qr(A) is calculated. E is an array of size n that represents a (fill-reducing) column permutation of A. The script creates a permutation matrix P from E (with Q*R = A*P) and checks whether Q*R*P' - A is small. 
In the second section some overdetermined systems A*x = b (m > n) are solved by calling x = qr(A,b). The script prints norm (A*x - b,2). Usually the values of norm(A*x - b,2) are between 1.0 and 6.0. The n columns of A span a subspace of the m-dimensional vector space. If b lies outside this subspace, there is no x with A * x = b. Only an approximation A*x of b can be calculated.
In the third section some underdetermined systems A*x = b (m < n) are solved by calling x = qr(A,b). The script prints norm(A*x - b,2). Usually the values of norm(A*x - b,2) have the order of magnitude -16. If m < n, there is a high chance that a column-subset of A spans the complete m-dimensional vector space. In this case, there exists x with A*x = b and norm(A*x - b,2) is very small. If no such subset exists, the value of norm (A*x - b,2) is large (> 0.1).
The fourth section checks whether the QR-factorization for a dense A still works.

Simon

Simon <sim79>
Sun 13 Oct 2019 03:14:43 PM UTC, comment #5: 

Thanks, Rik.

The attached patch adds a test for -lspqr to configure. However, I don't know how to check for a function from a template. Instead I checked for the C function "SuiteSparseQR_C" which happens to live in the same library.
Also some more logic could probably be added to make sure that we don't link to CXSparse in case SPQR can be used. (If this is what we want to do.)
There is a comment in configure.ac that the order of the suitesparse flags matters on some systems. The current order works on my system (Ubuntu). I don't know what the "correct" order is though.

The patch applies on top of the patch from comment #0. Feel free to merge the patches if you want to.

During compilation, I see a few shadowed declaration warnings:

../liboctave/numeric/sparse-qr.cc: In member function ‘SPARSE_T octave::math::sparse_qr<SPARSE_T>::sparse_qr_rep::R(bool) const [with SPARSE_T = SparseMatrix]’:
../liboctave/numeric/sparse-qr.cc:371:59: warning: declaration of ‘econ’ shadows a member of ‘octave::math::sparse_qr<SparseMatrix>::sparse_qr_rep’ [-Wshadow]
     sparse_qr<SparseMatrix>::sparse_qr_rep::R (bool econ) const
                                                           ^~~~~
../liboctave/numeric/sparse-qr.cc:130:23: note: shadowed declaration is here
       octave_idx_type econ;
                       ^~~~
../liboctave/numeric/sparse-qr.cc: In member function ‘RET_T octave::math::sparse_qr<SPARSE_T>::sparse_qr_rep::wide_solve(const RHS_T&, octave_idx_type&) const [with RHS_T = SparseMatrix; RET_T = SparseMatrix; SPARSE_T = SparseMatrix; octave_idx_type = long int]’:
../liboctave/numeric/sparse-qr.cc:1059:23: warning: declaration of ‘S’ shadows a member of ‘octave::math::sparse_qr<SparseMatrix>::sparse_qr_rep’ [-Wshadow]
       cholmod_sparse *S;
                       ^
../liboctave/numeric/sparse-qr.cc:132:57: note: shadowed declaration is here
       typename cxsparse_types<SPARSE_T>::symbolic_type *S;
                                                         ^
../liboctave/numeric/sparse-qr.cc: In member function ‘SPARSE_T octave::math::sparse_qr<SPARSE_T>::sparse_qr_rep::R(bool) const [with SPARSE_T = SparseComplexMatrix]’:
../liboctave/numeric/sparse-qr.cc:1542:66: warning: declaration of ‘econ’ shadows a member of ‘octave::math::sparse_qr<SparseComplexMatrix>::sparse_qr_rep’ [-Wshadow]
     sparse_qr<SparseComplexMatrix>::sparse_qr_rep::R (bool econ) const
                                                                  ^~~~~
../liboctave/numeric/sparse-qr.cc:130:23: note: shadowed declaration is here
       octave_idx_type econ;
                       ^~~~


The tests from the .zip file also produce some results and don't crash for me. I'm also not sure how to interpret the results though.

I'll try to cross-build for Windows next.

(file #47661)

Markus Mützel <mmuetzel>
Group administrator
Sat 12 Oct 2019 11:48:21 PM UTC, comment #4: 

So I can get it to compile by adding "-lspqr" to the environment variable LDFLAGS and then re-configuring and compiling.

This suggests only that some more work has to be done with the configuration and build system to check for the existence of libspqr during configuration, and then to add "-lspqr" to the LIBS variable.

With the compiled version I was able to run test_spqr.m in the zip file.  I don't know what output it is supposed to produce, but it doesn't segfault or do anything bad.

Rik <rik5>
Group administrator
Sat 12 Oct 2019 11:18:47 PM UTC, comment #3: 

I also fail to compile on Linux.  This is with suitesparse-dev-5.1.2.  It is failing at the link stage.  It may be that the SQPR routines are in a different package such as libspqr2 (but I have that installed), or that some different link flags need to be set.


Rik <rik5>
Group administrator
Sat 12 Oct 2019 10:47:42 AM UTC, comment #2: 

I tried to compile with this patch (to eventually try with a cross-build on Windows). However, the linker fails to resolve some references:

  CXXLD    src/octave-cli
/usr/bin/ld: liboctave/.libs/liboctave.so: undefined reference to `cholmod_dense_struct* SuiteSparseQR_qmult<double>(int, cholmod_sparse_struct*, cholmod_dense_struct*, long*, cholmod_dense_struct*, cholmod_common_struct*)'
/usr/bin/ld: liboctave/.libs/liboctave.so: undefined reference to `cholmod_sparse_struct* SuiteSparseQR_min2norm<double>(int, double, cholmod_sparse_struct*, cholmod_sparse_struct*, cholmod_common_struct*)'
/usr/bin/ld: liboctave/.libs/liboctave.so: undefined reference to `long SuiteSparseQR<double>(int, double, long, cholmod_sparse_struct*, cholmod_sparse_struct**, long**, cholmod_sparse_struct**, long**, cholmod_dense_struct**, cholmod_common_struct*)'
/usr/bin/ld: liboctave/.libs/liboctave.so: undefined reference to `long SuiteSparseQR<std::complex<double> >(int, double, long, cholmod_sparse_struct*, cholmod_sparse_struct**, long**, cholmod_sparse_struct**, long**, cholmod_dense_struct**, cholmod_common_struct*)'
/usr/bin/ld: liboctave/.libs/liboctave.so: undefined reference to `cholmod_sparse_struct* SuiteSparseQR_qmult<double>(int, cholmod_sparse_struct*, cholmod_dense_struct*, long*, cholmod_sparse_struct*, cholmod_common_struct*)'
/usr/bin/ld: liboctave/.libs/liboctave.so: undefined reference to `cholmod_dense_struct* SuiteSparseQR_qmult<std::complex<double> >(int, cholmod_sparse_struct*, cholmod_dense_struct*, long*, cholmod_dense_struct*, cholmod_common_struct*)'
/usr/bin/ld: liboctave/.libs/liboctave.so: undefined reference to `cholmod_dense_struct* SuiteSparseQR_min2norm<std::complex<double> >(int, double, cholmod_sparse_struct*, cholmod_dense_struct*, cholmod_common_struct*)'
/usr/bin/ld: liboctave/.libs/liboctave.so: undefined reference to `cholmod_sparse_struct* SuiteSparseQR_min2norm<std::complex<double> >(int, double, cholmod_sparse_struct*, cholmod_sparse_struct*, cholmod_common_struct*)'
/usr/bin/ld: liboctave/.libs/liboctave.so: undefined reference to `cholmod_dense_struct* SuiteSparseQR_min2norm<double>(int, double, cholmod_sparse_struct*, cholmod_dense_struct*, cholmod_common_struct*)'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:15663: src/octave-cli] Error 1
make[2]: Leaving directory '/home/osboxes/Repositories/Octave/octave-1/.build'
make[1]: *** [Makefile:27400: all-recursive] Error 1
make[1]: Leaving directory '/home/osboxes/Repositories/Octave/octave-1/.build'
make: *** [Makefile:11032: all] Error 2


My steps were:
1) Update octave repo to hg id 3fe26656e73c
2) Apply the patch from comment #0.
3) Run "make maintainer-clean"
4) Complete "bootstrap"-"configure"-"make all" cycle.

This was on Ubuntu 19.04 with libsuitesparse-dev 5.4.0.
I understand that this is an incomplete patch. Please, let me know if it is too early to try it on a cross-build for Windows.
Otherwise: What do I have to do to get this to compile and link (on Ubuntu-Linux as a first step)?

Markus Mützel <mmuetzel>
Group administrator
Thu 10 Oct 2019 04:58:44 PM UTC, comment #1: 

I filed this issue report to keep track of a promising patch to implement SPQR for sparse operations in Octave.  I've added the author of the patch (Simon) to the CC list for this bug, as well as Marco and Kai who I believe are interested in this topic.

Rik <rik5>
Group administrator
Thu 10 Oct 2019 04:57:19 PM UTC, original submission:  


I appended a test patch and a zip file. The zip file contains the script test_spqr.m with test cases.  Two test cases use SuiteSparse test matrices in Matrix Market Format. So I added the test matrices and MatrixMarketUtils to the zip file. I hope the patch will work on your system. 

The current status of the patch is
1) QR factorization can be calculated for sparse (real|complex) matrices.
2) least square and min2norm solutions can be calculated for sparse (real|complex) matrices.

Remarks
1) I will improve code formatting. I didn't apply the GNU coding standards consistently.
2) Probably the error handling and validation of parameters can be improved.
3) The solve methods for least square and min2norm are moved from class sparse_qr_rep to class sparse_qr. I can change this if necessary.
4) Macros HAVE_SUITESPARSE_SPQR_H and HAVE_SPQR are defined in oct-sparse.h. I don't know how to put them into config.h.
5) I didn't do any tests on Windows or Mac.
6) SPQR stores the results of the QR factorization either in a collection of data structures (H, R, HPinv, HTau) or in one "big" structure of type SuiteSparseQR_factorization. Unfortunately, there is no user-callable SPQR function to extract H, R, HPinv and HTau from a SuiteSparseQR_factorization-object. At least I didn't find one.

The implementation of the R-,C-,Q- and V-methods in class sparse_qr_rep is based on H, R, HPinv and HTau (calculated in the constructor). For the implementation of the solve methods the function SuiteSparseQR_min2norm is very convenient. This function uses the SuiteSparseQR_factorization and does not reuse H, R, HPinv and HTau. So for a matrix A I do one QR factorization in order to get R, Q etc. and a further factorization to solve Ax = b.

In the old implementation of sparse_qr_rep there was only one QR factorization in the constructor. The solve methods and the calculation of R, C, Q and V based on this single factorization. Therefore I think that the old approach is more efficient than my implementation.

I am thankful for tips or comments how to proceed.

Simon

Rik <rik5>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #48982:  simon_config.zip added by sim79 (178KiB - application/zip)
file #48847:  config.zip added by mmuetzel (114KiB - application/x-zip-compressed)
file #48691:  bug57033_spqr_rev6.patch added by mmuetzel (72KiB - application/octet-stream)
file #48596:  bug57033_spqr_rev5.patch added by sim79 (72KiB - text/x-patch)
file #48481:  bug57033_spqr_rev4.patch added by mmuetzel (66KiB - application/octet-stream)
file #48196:  bug57033_spqr_rev3.patch added by sim79 (77KiB - text/x-patch)
file #48139:  bug57033_spqr_rev2.patch added by sim79 (54KiB - text/x-patch)
file #48140:  bug57033_tests_rev2.log added by sim79 (4KiB - text/x-log)
file #47957:  bug57033_failing_tests.log added by mmuetzel (124KiB - application/octet-stream)
file #47958:  bug57033_spqr_rev1.patch added by mmuetzel (63KiB - application/octet-stream)
file #47661:  bug57033_spqr_configure.patch added by mmuetzel (4KiB - application/octet-stream)
file #47640:  test_spqr_20191006.patch added by rik5 (61KiB - text/x-patch)
file #47641:  test_spqr_20191006.zip added by rik5 (1MiB - application/zip)

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by sim79 (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  • -email is unavailable- added by rik5 (New patch to reimplement sparse operations with SPQR)
  • -email is unavailable- added by rik5 (New patch to reimplement sparse operations with SPQR)
  • -email is unavailable- added by rik5 (New patch to reimplement sparse operations with SPQR)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 23 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-01-09 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2021-01-07 mmuetzel Dependencies- bugs #59833 is dependent
    2021-01-06 mmuetzel Attached File- Added bug57033_integer_types.patch, #50671
    2021-01-05 mmuetzel StatusPatch Submitted Ready For Test
    2021-01-04 mmuetzel Attached File- Added bug57033_spqr_rev7.patch, #50648
    2020-05-01 sim79 Attached File- Added simon_config.zip, #48982
    2020-04-16 mmuetzel Attached File- Added config.zip, #48847
    2020-03-28 mmuetzel Attached File- Added bug57033_spqr_rev6.patch, #48691
    2020-03-13 sim79 Attached File- Added bug57033_spqr_rev5.patch, #48596
    2020-02-23 mmuetzel Attached File- Added bug57033_spqr_rev4.patch, #48481
    2020-01-10 sim79 Attached File- Added bug57033_spqr_rev3.patch, #48196
    2019-12-30 sim79 Attached File- Added bug57033_spqr_rev2.patch, #48139
        Attached File- Added bug57033_tests_rev2.log, #48140
    2019-12-01 mmuetzel Attached File- Added bug57033_failing_tests.log, #47957
        Attached File- Added bug57033_spqr_rev1.patch, #47958
    2019-10-13 mmuetzel Dependencies- bugs #51950 is dependent
    2019-10-13 mmuetzel Attached File- Added bug57033_spqr_configure.patch, #47661
    2019-10-10 rik5 Attached File- Added test_spqr_20191006.patch, #47640
        Attached File- Added test_spqr_20191006.zip, #47641
        Carbon-Copy- Added -email is unavailable-
        Carbon-Copy- Added -email is unavailable-
        Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code