bugGNU Octave - Bugs: bug #58795, ode15i and ode15s fail for Windows...

 
 

bug #58795: ode15i and ode15s fail for Windows 32bit

Submitter:  Markus Mützel <mmuetzel>
Submitted:  Tue 21 Jul 2020 06:59:45 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
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 13 Sep 2020 10:13:43 AM UTC, comment #68: 

Tried again with a Windows 32bit build with the recent changes (Octave hg id 08049eff8733 and MXE Ooctave hg id b982f2df58cf):
"test ode15i" and "test ode15s" pass all tests without errors.

Closing as fixed.

Markus Mützel <mmuetzel>
Group administrator
Fri 11 Sep 2020 08:08:35 PM UTC, comment #67: 

I pushed this change on stable and merged with default:

http://hg.savannah.gnu.org/hgweb/octave/rev/45d958bc3437

John W. Eaton <jwe>
Group administrator
Fri 11 Sep 2020 04:35:56 PM UTC, comment #66: 

I'll fix the warning about the copy assignment operator.

John W. Eaton <jwe>
Group administrator
Fri 11 Sep 2020 04:11:31 PM UTC, comment #65: 

gcc builds 9beec32ba3d6 without any complaints. did now also a clang build and got same warning as mentioned in comment #64. but it comes many times in other .cc files as well. Anyway BISTs pass in both worlds without errors and my own test cases also pass.


Hg200 <hg200>
Fri 11 Sep 2020 12:17:27 PM UTC, comment #64: 

The only compiler warning I can see for "__ode15__.cc" is on the clang-fedora builder (same for clang-debian):
http://buildbot.octave.org:8010/#/builders/9/builds/1736/steps/6/logs/stdio

In file included from ../src/libinterp/dldfcn/__ode15__.cc:43:
../src/libinterp/parse-tree/parse.h:124:26: warning: explicitly defaulted copy assignment operator is implicitly deleted [-Wdefaulted-function-deleted]
      parent_scope_info& operator = (const parent_scope_info&) = default;
                         ^
../src/libinterp/parse-tree/parse.h:148:20: note: copy assignment operator of 'parent_scope_info' is implicitly deleted because field 'm_parser' is of reference type 'octave::base_parser &'
      base_parser& m_parser;
                   ^
1 warning generated.


But that doesn't look related to the issue here, and many other files including that header show the same warning.

Markus Mützel <mmuetzel>
Group administrator
Fri 11 Sep 2020 11:43:40 AM UTC, comment #63: 

I pushed the change here:
https://hg.savannah.gnu.org/hgweb/octave/rev/9beec32ba3d6

I hope there won't be too many changes necessary (in case the build bot are complaining). I also hope it is ok to do those in the repository if they were needed.

Marking as ready for test again.

Markus Mützel <mmuetzel>
Group administrator
Fri 11 Sep 2020 10:39:11 AM UTC, comment #62: 

Thanks.
Just to be sure: Are there any warnings from the compiler?

Markus Mützel <mmuetzel>
Group administrator
Fri 11 Sep 2020 10:20:23 AM UTC, comment #61: 

No problem ;-) Just for confirmation the patch file #49783 builds without errors and the BISTs are fine on Fedora 31.

Hg200 <hg200>
Fri 11 Sep 2020 08:57:36 AM UTC, comment #60: 

Sorry again.
You are right. That was the wrong patch.
Attached is the patch actually belonging here.

(file #49783)

Markus Mützel <mmuetzel>
Group administrator
Fri 11 Sep 2020 08:55:17 AM UTC, comment #59: 

The example in comment #57 might not have been the best to demonstrate the possible implications. It was just the first one I found with a (possibly) narrowing assignment that is un-checked.

Markus Mützel <mmuetzel>
Group administrator
Fri 11 Sep 2020 08:33:03 AM UTC, comment #58: 

Thanks for the explanation. I now understand the problem with the Blas / Lapack indexing.

Regarding comment #55: Is there anything i can / should test? The attached file #49780 seems to be related to bug #49503 and not to bug #58795?




Hg200 <hg200>
Thu 10 Sep 2020 07:21:18 PM UTC, comment #57: 

Thanks for the test.
Sorry, I wasn't clear what I wanted to have tested. I actually meant to ask for testing the attached patch. The verbatim block was just to show what I changed with respect to the patch that failed on the buildbots.

My Ubuntu 20.04.1 is 64bit. But still sunindextype is 32bit wide  on that system.

I might be misunderstanding how this is supposed to work. But afaics, sunindextype should be set to the same size as the integer type used in the BLAS/LAPACK libraries. That is still 32bit on most systems.
Otherwise, bad things could happen somewhere when unavoidably sunindextype has to be cast to "int" for calling the BLAS/LAPACK functions.

For example in sundials 4.1.0 in sunlinsol_lapackband.c:

int SUNLinSolSetup_LapackBand(SUNLinearSolver S, SUNMatrix A)
{
  int n, ml, mu, ldim, ier;

  /* check for valid inputs */
  if ( (A == NULL) || (S == NULL) )
    return(SUNLS_MEM_NULL);

  /* Ensure that A is a band matrix */
  if (SUNMatGetID(A) != SUNMATRIX_BAND) {
    LASTFLAG(S) = SUNLS_ILL_INPUT;
    return(LASTFLAG(S));
  }

  /* Call LAPACK to do LU factorization of A */
  n = SUNBandMatrix_Rows(A);
  ml = SUNBandMatrix_LowerBandwidth(A);
  mu = SUNBandMatrix_UpperBandwidth(A);
  ldim = SUNBandMatrix_LDim(A);
  xgbtrf_f77(&n, &n, &ml, &mu, SUNBandMatrix_Data(A),
             &ldim, PIVOTS(S), &ier);

  LASTFLAG(S) = (long int) ier;
  if (ier > 0)
    return(SUNLS_LUFACT_FAIL);
  if (ier < 0)
    return(SUNLS_PACKAGE_FAIL_UNREC);
  return(SUNLS_SUCCESS);
}


With among other the following declarations in sunmatrix_band.h:

SUNDIALS_EXPORT sunindextype SUNBandMatrix_Rows(SUNMatrix A);
SUNDIALS_EXPORT sunindextype SUNBandMatrix_Columns(SUNMatrix A);
SUNDIALS_EXPORT sunindextype SUNBandMatrix_LowerBandwidth(SUNMatrix A);
SUNDIALS_EXPORT sunindextype SUNBandMatrix_UpperBandwidth(SUNMatrix A);


That seems to have been fixed in the meantime by efectively forcing sunindextype to match the BLAS index type.
But it is only safe in older version if "sunindextype" was correctly configured when sundials was compiled.
That seems to be not the case for the sundials that is packaged for Fedora.
So to avoid a possible issue here, we need to make sure that the sunindextype variables we pass to sundials can safely be cast to the BLAS integer type.

Markus Mützel <mmuetzel>
Group administrator
Thu 10 Sep 2020 06:53:37 PM UTC, comment #56: 

I can reproduce the build problem with same error on my fedora 31. But I got lost already in comment #32. My understanding is that this function is defined as


./sundials-4.1.0/include/sunmatrix/sunmatrix_sparse.h
SUNDIALS_EXPORT sunindextype* SUNSparseMatrix_IndexValues(SUNMatrix A);


sunindextype's default on a 64 bit Linux is "long int". So i am rather wondering why the make can pass on Ubuntu without errors.

I have tested proposed changes in the verbatim environment in comment #55. I presume attached file #49780 contains some other stuff?. To be clear i have attached _ode15_.cc which i have tested. I have no errors and some of my random ode tests are fine and BISTs also pass:


octave:6> test "ode15s"
PASSES 39 out of 39 tests
octave:7> test "ode15i"
PASSES 48 out of 48 tests


(file #49781)

Hg200 <hg200>
Thu 10 Sep 2020 06:06:45 PM UTC, comment #55: 

Thanks for the info.
That version of Sundials uses "int" in the BLAS/LAPACK wrappers (in sundials_lapack.h).
It might be that that could lead to an integer overflow sizeof(sunindextype)>sizeof(int). It would if not checked carefully (like we try to do with octave::to_f77_int).
Presumably, that was fixed in a later version effectively forcing sunindextype to match the integer type used by the BLAS/LAPACK libraries. At least in sundials 5.3.0, the wrappers use sunindextype.

Compiling at hg id 0c9a5eae6c27 works for me on Ubuntu with sundials (3.1.2+dfsg-3ubuntu2).
In /usr/include/sundials/sundials_lapack.h, the BLAS/LAPACK wrappers also use "int". But I have "#define SUNDIALS_INT32_T 1" in sundials_config.h. IIUC, that means that sunindextype is "int".
So everything is fine.

It's getting more probable that this is a packaging/configuration error on Fedora.

If we want to support such systems, I guess we could continue to use "sunindextype *" for the variables in the error messages and still be careful to not pass integers that are larger than what the BLAS/LAPACK libraries can cope with:

    SUNMatZero_Sparse (Jac);
    sunindextype *colptrs = SUNSparseMatrix_IndexPointers (Jac);
    sunindextype *rowvals = SUNSparseMatrix_IndexValues (Jac);

    for (octave_f77_int_type i = 0; i < m_num + 1; i++)
      colptrs[i] = to_f77_int (jac.cidx (i));

    double *d = SUNSparseMatrix_Data (Jac);
    for (octave_f77_int_type i = 0; i < to_f77_int (jac.nnz ()); i++)
      {
        rowvals[i] = to_f77_int (jac.ridx (i));
        d[i] = jac.data (i);
      }


Could someone with an affected system please test the attached patch? Does it compile with those changes? Do we need an additional cast (from octave_f77_int_type to sunindextype), or will the compiler do that for us?

(file #49780)

Markus Mützel <mmuetzel>
Group administrator
Thu 10 Sep 2020 04:32:29 PM UTC, comment #54: 

fyi, sundials on fedora's buildbots:

sundials-4.1.0-11.fc32.src.rpm

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 10 Sep 2020 04:26:16 PM UTC, comment #53: 

The types seem to match on the Debian buildbots (and also on my Ubuntu). But they seem to be different on Fedora. E.g.:
http://buildbot.octave.org:8010/#/builders/11/builds/1732

There is still this note in the IDA manual (which isn't very enlightening to me) [1]:

> A user program which uses sunindextype to handle indices will work with both index storage types except for any calls to index storage-specific external libraries.


And jwe observed the following:

> The sundials wrappers for BLAS functions use sunindextype, so it appears that it should match the size used by BLAS.
> See the file sundials-5.3.0/include/sundials/sundials_lapack.h, for example.

And:

> Since it is used in the prototypes for calling BLAS/Lapack functions inside sundials, then it seems we are forced to make it match the size of the type used for BLAS integers (octave_f77_int_type).


So is this a packaging issue in Fedora? (Probably not very likely.)
Or an error in Sunlinsol?
Or is there more to it?

[1]: https://computing.llnl.gov/sites/default/files/public/ida_guide.pdf

Markus Mützel <mmuetzel>
Group administrator
Thu 10 Sep 2020 03:52:14 PM UTC, comment #52: 

The buildbots are failing with the following error:

In file included from ../src/libinterp/dldfcn/__ode15__.cc:43:
../src/libinterp/parse-tree/parse.h:124:26: warning: explicitly defaulted copy assignment operator is implicitly deleted [-Wdefaulted-function-deleted]
      parent_scope_info& operator = (const parent_scope_info&) = default;
                         ^
../src/libinterp/parse-tree/parse.h:148:20: note: copy assignment operator of 'parent_scope_info' is implicitly deleted because field 'm_parser' is of reference type 'octave::base_parser &'
      base_parser& m_parser;
                   ^
../src/libinterp/dldfcn/__ode15__.cc:484:26: error: cannot initialize a variable of type 'octave_f77_int_type *' (aka 'int *') with an rvalue of type 'sunindextype *' (aka 'long *')
    octave_f77_int_type *colptrs = SUNSparseMatrix_IndexPointers (Jac);
                         ^         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/libinterp/dldfcn/__ode15__.cc:485:26: error: cannot initialize a variable of type 'octave_f77_int_type *' (aka 'int *') with an rvalue of type 'sunindextype *' (aka 'long *')
    octave_f77_int_type *rowvals = SUNSparseMatrix_IndexValues (Jac);
                         ^         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning and 2 errors generated.


It looks like our assumption that sunindextype must match the size of integers used by the BLAS routines is not true.
I backed out the changeset here:
https://hg.savannah.gnu.org/hgweb/octave/rev/9dc9f15dac64

Markus Mützel <mmuetzel>
Group administrator
Thu 10 Sep 2020 03:40:56 PM UTC, comment #51: 

The new bug for the possible integer overflow is bug #59094.

Markus Mützel <mmuetzel>
Group administrator
Thu 10 Sep 2020 03:30:24 PM UTC, comment #50: 

I pushed the patch that overhauls the integer usage here:
https://hg.savannah.gnu.org/hgweb/octave/rev/0c9a5eae6c27

In that patch I also a FIXME note about the possible integer overflow. I'll open a new report for that to not stretch the scope of this report even further.

Marking as ready for test.

Markus Mützel <mmuetzel>
Group administrator
Thu 03 Sep 2020 02:57:26 PM UTC, comment #49: 

Gnulib has macros for checking whether integer operations overflow, or we could (conditionally) use things like __builtin_mul_overflow to multiply dimensions and check for overflow.

I recently noticed that one of the Octave dependencies (maybe it was Sundials?) was using the portable snippets library for this job.  Perhaps we could use that or at least borrow ideas from it.  See, for example,  https://github.com/nemequ/portable-snippets/tree/master/safe-math

I hope we can refactor so that we limit the number of places where checks like this are needed.

See also bug #58790.

John W. Eaton <jwe>
Group administrator
Thu 03 Sep 2020 01:17:27 PM UTC, comment #48: 

You wrote in comment #35 that "sunindextype" is used to interface to BLAS/LAPACK functions inside SUNDIALS. You concluded that this means that "sunindextype" must match the integer type used by the BLAS/LAPACK libraries, and must hence match "octave_f77_int_type".
I agree with that conclusion.

I think there is only one place where we have to check on conversion from "octave_idx_type" to "octave_f77_int_type".
I'm attaching an updated patch.

The following lines look fishy wrt integer overflow (in particular "m_num*m_num" --- "m_num" is of type "octave_f77_int_type"):

        // FIXME : one should not allocate space for a full Jacobian
        // when using a sparse format.  Consider allocating less space
        // then possibly using SUNSparseMatrixReallocate to increase it.
        m_sunJacMatrix = SUNSparseMatrix (m_num, m_num, m_num*m_num, CSC_MAT);


The prototype of that function is "SUNMatrix SUNSparseMatrix(sunindextype M, sunindextype N, sunindextype NNZ, int sparsetype)".

Is there something similarly straight-forward that we can do to avoid an integer overflow?

(file #49737)

Markus Mützel <mmuetzel>
Group administrator
Thu 03 Sep 2020 12:43:33 PM UTC, comment #47: 

To convert an octave_idx_type value to an octave_f77_int_type value, you can use octave::to_f77_int, declared in f77_fcn.h.  It throws an error if the value is too large.

Is sunindextype always supposed to match the integer type used by the BLAS and Lapack libraries?  If so, then Octave's F77_INT typedef should always the the same as sunindextype and using to_f77_int should be OK.  Otherwise, we may want to define another function that does the same job, but for sunindextype.



John W. Eaton <jwe>
Group administrator
Thu 03 Sep 2020 11:58:21 AM UTC, comment #46: 

I should have mentioned: AFAICT, there is no warning or error in case the the input should be larger than octave_f77_int_type allows.
Some checks are probably necessary. But I don't know how to do that properly. Maybe somewhere in or around "IDA::ColToNVec"?

Markus Mützel <mmuetzel>
Group administrator
Thu 03 Sep 2020 11:43:47 AM UTC, comment #45: 

I no longer see any errors for "test ode15i" on a Windows 32bit build from the stable branch (hg id f044b9951df5).

I also went through the integer type usage in "__ode15__.cc". Where according to the API of SUNDIALS IDA "sunindextype" should be used, I used "octave_f77_int_type".
In some places, the API uses "int" or "long int". In these places, I kept these types.
Where to me it seemed to be the most appropriate type, I used "octave_idx_type".


(file #49735)

Markus Mützel <mmuetzel>
Group administrator
Wed 26 Aug 2020 12:35:38 PM UTC, comment #44: 

Since the discussion became a little bit confusing, I'll re-state what I think is the last task left to close this bug:
Check where in "__ode15__.cc" we should use "octave_idx_type" or "octave_f77_int_type".

IIUC, we should replace all uses of "sunindextype" with "octave_f77_int_type". Not sure about the places where "int" and "long int" are used.

Markus Mützel <mmuetzel>
Group administrator
Fri 31 Jul 2020 06:00:44 PM UTC, comment #43: 

I pushed the following change to MXE Octave:
https://hg.octave.org/mxe-octave/rev/9f9ed6a325bd

With that changes, KLU is detected by SUNDIALS IDA also for native Linux.

Only one file needs to change to update SuiteSparse.

Markus Mützel <mmuetzel>
Group administrator
Thu 30 Jul 2020 06:43:46 PM UTC, comment #42: 

Re comment #40: I agree that we shouldn't use that change in MXE Octave. It was more meant as a test to see if SUNDIALS IDA would be able to link to the libraries that we built as part of SuiteSparse.
I'm also not very familiar with cmake. But maybe I can find some time to play around with it in the next few days.

Any help for "__ode15__.cc" would be much appreciated.

Markus Mützel <mmuetzel>
Group administrator
Thu 30 Jul 2020 06:40:10 PM UTC, comment #41: 
Markus Mützel <mmuetzel>
Group administrator
Thu 30 Jul 2020 06:20:26 PM UTC, comment #40: 

I understand that the change in comment #25 allows things to work.  I'm just pointing out that it is probably not a good long term solution.  Cmake is a bit of a mystery to me though, so I'm not sure I can help much.

I can look at the way integers are used in _ode15_.cc if that will help.

John W. Eaton <jwe>
Group administrator
Thu 30 Jul 2020 06:15:26 PM UTC, comment #39: 

I'd say go ahead and push the change to mxe-octave as it seems we should have sunindextype match the BLAS/fortran integer size.

John W. Eaton <jwe>
Group administrator
Thu 30 Jul 2020 06:03:46 PM UTC, comment #38: 

IIUC, sunindextype is used in the interface. It is used twice in "__ode15__.cc".

The attached patch for MXE Octave is a slightly adapted version of hg200's patch that sets the size of sunindextype according to ENABLE_FORTRAN_INT64.

(file #49585)

Markus Mützel <mmuetzel>
Group administrator
Thu 30 Jul 2020 06:02:27 PM UTC, comment #37: 

I also see some places in Octave's _ode15_.cc file where "int" and "long int" are used where I suspect octave_idx_type or octave_f77_int_type should be used.

John W. Eaton <jwe>
Group administrator
Thu 30 Jul 2020 05:56:21 PM UTC, comment #36: 

Re comment #29: I agree that it shouldn't be necessary to explicitly pass the full name and path to the libraries.
However, if I omit one of them (e.g. COLAMD_LIBRARY), cmake fails with the following error:

-- Looking for KLU libraries...
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
COLAMD_LIBRARY
    linked by target "ltest" in directory /home/osboxes/Documents/Repositories/Octave/mxe-octave-native/tmp-sundials-ida/sundials-5.3.0.build/KLUTest

CMake Error at config/SundialsKLU.cmake:59 (try_compile):
  Failed to generate test project build system.
Call Stack (most recent call first):
  CMakeLists.txt:1000 (include)


-- Configuring incomplete, errors occurred!



The failing code is probably:
https://github.com/LLNL/sundials/blob/master/config/FindKLU.cmake

Markus Mützel <mmuetzel>
Group administrator
Thu 30 Jul 2020 05:56:14 PM UTC, comment #35: 

Is sunindextype something internal to sundials (like Octave's octave_f77_int_type) or is it something that appears in the interface to sundials functions that we call?

Since it is used in the prototypes for calling BLAS/Lapack functions inside sundials, then it seems we are forced to make it match the size of the type used for BLAS integers (octave_f77_int_type).

If it also appears in the external interface of sundials functions, then we have to be careful in Octave to call sundials functions with octave_f77_int_type variables, same as we do for BLAS/Lapack and some other libraries.

John W. Eaton <jwe>
Group administrator
Thu 30 Jul 2020 05:50:37 PM UTC, comment #34: 

The sundials wrappers for BLAS functions use sunindextype, so it appears that it should match the size used by BLAS.

See the file sundials-5.3.0/include/sundials/sundials_lapack.h, for example.

I don't know why this would affect the w32 version of Octave and not the w64 versions.

John W. Eaton <jwe>
Group administrator
Thu 30 Jul 2020 05:14:24 PM UTC, comment #33: 

SUNDIALS IDA depends on LAPACK and SuiteSparse.
I'm not sure if sunindextype should (or must) match the index type of one or the other.
On [1], they write the following about v3.0.0:

> Addition of sunindextype option for 32- or 64-bit integer data index types within all SUNDIALS structures.
> > Sunindextype can be int64_t or int32_t or long long int and int depending on machine support for portable types.
> > The Fortran interfaces continue to use long_int for indices, except for their sparse matrix interface that now uses the new sunindextype.
> > Includes interfaces to PETSc, hypre, SuperLU_MT, and KLU with either 64-bit or 32-bit capabilities depending how the user configures SUNDIALS.


In their manual [2], they write:

> A user program which uses sunindextype to handle indices will work with both index storage types except for any calls to index storage-specific external libraries.


So that kind of sounds like it should match something. But I'm not sure if that is SuiteSparse_long or what SuiteSparse calls LONGBLAS and we call F77_INT.

It is currently only failing for Windows 32bit (where SuiteSparse_long is 32bit and F77_INT is 32bit). It didn't fail for hg200 when he tested on Windows 64bit (where SuiteSparse_long is 64bit and F77_INT was 32bit). (It was also independent of the size of octave_idx_type in his tests.)
So I'm guessing, sunindextype might need to match the size of SuiteSparse_long?

But it might also be caused by the code snippet, you showed in comment #31.
IIUC, SUNDIALS_INT64_T is defined if SUNDIALS_INDEX_SIZE is 64. That seems to be the default. So by default, sunindextype is 64bit. But KLU_INDEXTYPE would be 32bit wide on Windows (32bit and 64bit). That indeed looks suspicious. But if that is the problem, why does it work on Windows 64bit?
I wonder why KLU_INDEXTYPE isn't always defined as sunindextype?

Or those are two different (though quite similar) bugs.

[1]: https://computing.llnl.gov/projects/sundials/ida
[2]: https://computing.llnl.gov/sites/default/files/public/ida_guide.pdf

Markus Mützel <mmuetzel>
Group administrator
Thu 30 Jul 2020 05:12:57 PM UTC, comment #32: 

i also came accross the warning of incompatible pointers. Unfortunately the warning appears on the w64 target that does not make trouble. My thoughts about KLU_INDEXTYPE where: According to Wikipedia Windows uses long long integer model (i didn't know that). But if so, then KLU_INDEXTYPE is int32 for w32 and w64 target (does not depend on SUNDIALS_INT64_T). But on a 64 linux machine a long int is 64 bit. So there should be a difference between Linux 64 and Windows 64 with w64 target but there is no difference. The difference is on Windows 64 with w32 target. It's confusing me, but i tend to drop the KLU_INDEXTYPE hypothesis.

Hg200 <hg200>
Thu 30 Jul 2020 04:32:57 PM UTC, comment #31: 

It appears to me that sundials can call BLAS or Lapack functions and it uses sunindextype for the integer dimensions and work arrays that it passes.  So that type should match what is used by the BLAS and Lapack libraries on the system (i.e., it should follow the ENABLE_FORTRAN_INT64 option for mxe-octave.

I also found the following lines in sundials-5.3.0/src/sunlinsol/klu/sunlinsol_klu.c:


#if defined(SUNDIALS_INT64_T)
#define KLU_INDEXTYPE long int
#else
#define KLU_INDEXTYPE int
#endif


That looks wrong for Windows, but shouldn't be a problem for w32 systems, only for 64-bit systems when using 64-bit fortran integers?

For those systems (the mxe-octave w64-64 builds), the buildbot log file for sundials shows warning like this:


/scratch/buildbot/workers/jwe-debian-x86_64-3/w64-64-on-debian/src/tmp-sundials-ida/sundials-5.3.0/src/sunlinsol/klu/sunlinsol_klu.c: In function 'SUNLinSolSetup_KLU':
/scratch/buildbot/workers/jwe-debian-x86_64-3/w64-64-on-debian/src/tmp-sundials-ida/sundials-5.3.0/src/sunlinsol/klu/sunlinsol_klu.c:281:35: warning: passing argument 2 of 'klu_l_analyze' from incompatible pointer type [-Wincompatible-pointer-types]
  281 |                                   (KLU_INDEXTYPE*) SUNSparseMatrix_IndexPointers(A),
      |                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                   |
      |                                   long int *
In file included from /scratch/buildbot/workers/jwe-debian-x86_64-3/w64-64-on-debian/src/tmp-sundials-ida/sundials-5.3.0/include/sunlinsol/sunlinsol_klu.h:34,
                 from /scratch/buildbot/workers/jwe-debian-x86_64-3/w64-64-on-debian/src/tmp-sundials-ida/sundials-5.3.0/src/sunlinsol/klu/sunlinsol_klu.c:22:
/scratch/buildbot/workers/jwe-debian-x86_64-3/w64-64-on-debian/src/usr/x86_64-w64-mingw32/include/suitesparse/klu.h:253:17: note: expected 'long long int *' but argument is of type 'long int *'
  253 | klu_l_symbolic *klu_l_analyze (SuiteSparse_long, SuiteSparse_long *,
      |                 ^~~~~~~~~~~~~


John W. Eaton <jwe>
Group administrator
Thu 30 Jul 2020 02:36:10 PM UTC, comment #30: 

On my Debian system, I see


typedef int32_t sunindextype;


in the file /usr/include/sundials/sundials_types.h.

I assume this is needed to match the use of 32-bit integers for indexing and integer work arrays in the system BLAS library.

In Octave on 64-bit systems using the default int64_t for 64-bit indexing, we can still use 32-bit BLAS (and other) libraries if we are careful to avoid calling those library functions when the array sizes are too large.  I don't know whether we are already doing it, but we may need to do the same for Sundials.

On 32-bit systems, I don't expect it to be possible to use 64-bit indexing, so all indexing and dimension variables should be limited to 32-bits.

If Sundials and/or some of the libraries it uses are configured by default to use 64-bit indexing, then that's probably a mistake if they also need to call 32-bit BLAS functions.

If I remember correctly, SuiteSparse can be configured to use 64-bit indexing and use a BLAS library that has 32-bit indexing because it is careful when calling BLAS functions, same as Octave tries to do.


John W. Eaton <jwe>
Group administrator
Thu 30 Jul 2020 02:22:49 PM UTC, comment #29: 

RE comment #25, I haven't looked at the sundials configuration and build system, but it seems wrong that we would need to specify full path names including SO versions when linking to shared libraries.

John W. Eaton <jwe>
Group administrator
Thu 30 Jul 2020 02:08:35 PM UTC, comment #28: 

Another guess: Maybe "sunindextype" has to be the same size as "SuiteSparse_long"?

Markus Mützel <mmuetzel>
Group administrator
Thu 30 Jul 2020 01:48:41 PM UTC, comment #27: 

Got that wrong.
Sorry for the noise.

Markus Mützel <mmuetzel>
Group administrator
Thu 30 Jul 2020 01:43:35 PM UTC, comment #26: 

There is the following condition in "suitesparse.mk":

ifeq ($(ENABLE_FORTRAN_INT64),yes)
  ifeq ($(MXE_WINDOWS_BUILD),yes)
    $(PKG)_CPPFLAGS += -DLONGBLAS='long long'
  else
    $(PKG)_CPPFLAGS += -DLONGBLAS='long'
  endif
endif


On Windows (minus maybe cygwin), 'long long' is the "smallest" integer type that is 64bit. 'long' is 64bit on Linux. But ENABLE_FORTRAN_INT64 is 'no' by default. And you explicitly disabled it in your test.

I don't see another switch that sets the size of an indexing variable in suitesparse.mk. But maybe it uses different types depending on whether it is configured for a 32bit or 64bit executable target.

And indeed in SuiteSparse_config.h, there is the following stanza:

#ifndef SuiteSparse_long

#ifdef _WIN64

#define SuiteSparse_long __int64
#define SuiteSparse_long_max _I64_MAX
#define SuiteSparse_long_idd "I64d"

#else

#define SuiteSparse_long long
#define SuiteSparse_long_max LONG_MAX
#define SuiteSparse_long_idd "ld"

#endif
#define SuiteSparse_long_id "%" SuiteSparse_long_idd
#endif


If I'm reading this right, it defines SuiteSparse_long to the 32bit "long" for Windows 32bit targets (where _WIN64 isn't defined).
That looks like a bug in SuiteSparse to me. Probably, it should be "#ifdef _WIN32" (which is defined for Windows 32bit and 64bit targets).

That still seems to be defined the same in the current SuiteSparse version:
https://github.com/DrTimothyAldenDavis/SuiteSparse/blob/master/SuiteSparse_config/SuiteSparse_config.h#L54

I opened an issue upstream here:
https://github.com/DrTimothyAldenDavis/SuiteSparse/issues/55#issue-668736312

Markus Mützel <mmuetzel>
Group administrator
Thu 30 Jul 2020 12:16:39 PM UTC, comment #25: 

If I make the following change to the build rule of SUNDIALS IDA, it seems to correctly link to these libraries:

diff -r 2993dbd2acea -r 0bc7ea7264d9 src/sundials-ida.mk
--- a/src/sundials-ida.mk        Sun Jul 05 12:21:53 2020 +0200
+++ b/src/sundials-ida.mk        Thu Jul 30 14:08:20 2020 +0200
@@ -52,6 +52,11 @@
         -DKLU_ENABLE=ON \
         -DKLU_INCLUDE_DIR=$(HOST_INCDIR)/suitesparse \
         -DKLU_LIBRARY_DIR=$(HOST_LIBDIR) \
+        -DKLU_LIBRARY=$(HOST_LIBDIR)/libklu.so.1 \
+        -DAMD_LIBRARY=$(HOST_LIBDIR)/libamd.so.2 \
+        -DBTF_LIBRARY=$(HOST_LIBDIR)/libbtf.so.1 \
+        -DCOLAMD_LIBRARY=$(HOST_LIBDIR)/libcolamd.so.2 \
+        -DSUITESPARSECONFIG_LIBRARY=$(HOST_LIBDIR)/libsuitesparseconfig.so.5 \
         -DCMAKE_TOOLCHAIN_FILE='$(CMAKE_TOOLCHAIN_FILE)' \
         -DBUILD_ARKODE=OFF \
         -DBUILD_CVODE=OFF \


I don't know why the build tools wouldn't find and use those libraries automatically. They seem to be successfully found for Windows cross builds.
Maybe it has something to do with the trailing version? The Windows libraries seem to end in ".a" (without version postfix).

Markus Mützel <mmuetzel>
Group administrator
Thu 30 Jul 2020 11:27:36 AM UTC, comment #24: 

I crossed with your last comment #22.

That is strange. I would have expected your case 2.) to fail, too.
Maybe the issue is that the size of pointers is different for 32bit and 64bit targets. Maybe somewhere a pointer type is used for indexing or vice versa? But I guess that the compiler would at least warn about that...

I'll have a look why SUNDIALS IDA doesn't use KLU for native Linux builds with MXE Octave (probably a different bug from the one here).

Markus Mützel <mmuetzel>
Group administrator
Thu 30 Jul 2020 10:52:54 AM UTC, comment #23: 

Sounds like a good test of our current working assumption.

To give you a starting point for a native Linux build with MXE Octave (I don't remember if I sent that before), the buildbot configuration uses switches similar to these:

./configure --with-pkg-dir=../mxe-octave-pkg --with-ccache --enable-octave=default --enable-binary-packages --enable-native-build --enable-qt5 --enable-lib64-directory --enable-pic-flag --disable-devel-tools --enable-system-x11-libs --enable-system-fontconfig --enable-system-gcc gnu-linux


For a test, you could add "--disable-64" (and don't use the patch you provided here).

Markus Mützel <mmuetzel>
Group administrator
Thu 30 Jul 2020 10:48:57 AM UTC, comment #22: 

Follow-up

1.)
The bug appears consistent with the occurrence of sparse matrix representation. Attached is a minimum working example. With and without sparse - keyword. If


sparse()


is removed, the example runs successful as w32 target.

2.)
The test with mxe-octave on win64 target (on Windows 7), with int32_t octave_idx_type and int64_t sunindextype


./configure --with-pkg-dir=../pkg_mxe_64/ --with-ccache --enable-octave=default --enable-binary-packages --enable-qt5 --enable-devel-tools --enable-windows-64 --disable-64 --disable-fortran-int64 --disable-system-opengl


did not force the bug. Maybe it's an inconsistency between suitesparse + sundials-ida on a w32 target?

3.)
Off topic: I checked the fix on a MXE on Linux build. sundials log has a warning:

-- Looking for KLU libraries... FAILED
WARNING: KLU LIBRARIES NOT Found.  Please check library path
/home/.../mxe-octave-64-linux/usr/lib

Maybe it is because libsundials_sunlinsolklu.* is not build for for Linux. I would expect the preprocessor define "HAVE_SUNDIALS_SUNLINSOL_KLU" in config.h. But config.h is removed after building default-octave, right?





(file #49579, file #49580)

Hg200 <hg200>
Tue 28 Jul 2020 10:36:02 PM UTC, comment #21: 

Same for me. I have no idea whats going on in _ode15_.

Anyway, the attached patch v03 is verified with complete new & fresh windows builds, for 32 and 64 bit targets either. The testsuite / ODE-BISTS complete all without errors for both targets on Windows 7.

I didn't verify the "else path" so far (i.e. the non-windows build variants).

> Or use MXE Octave for a native Linux build.

Yeah - thats a good idea! I can build a Windows 64 target but with --disable-64 and see if the problem can be forced. If so then go ahead with Linux.



(file #49564)

Hg200 <hg200>
Tue 28 Jul 2020 02:24:36 PM UTC, comment #20: 

I'm not familiar with SUNDIALS IDA or the code in "__ode15__.cc". But it looks like there are some casts between void* and IDA*. Maybe some alignment might be off if types mismatch? But that might be a red herring.

For your tests on Linux: Are any of the tests skipped? Is HAVE_SUNDIALS_SUNLINSOL_KLU set?
You might have to compile SUNDIALS (and maybe also SuiteSparse) with KLU to reproduce the issue.
Or use MXE Octave for a native Linux build.

Markus Mützel <mmuetzel>
Group administrator
Tue 28 Jul 2020 01:33:09 PM UTC, comment #19: 

I'm not yet sure about the exact root cause. As long as Octave's ode15 uses the IDA-headers to create the data structures that are exchanged with the IDA library, i would not expect casting problems, provided that sunindextype is int64_t and octave_idx_type is int32_t. I.e. if a structure is packed, or padded and how it is casted should not depend on the type of an index?

Another observation: Since I can't debug under windows, I made a build on my 64-bit Linux, with octave_idx_type set to int32_t, based on the ENABLE_64 switch, which in turn is set in configure.ac based on the configuration option --disable-64. My expectation would have been to see the problem if the root cause is a mismatch between octave_idx_type and sunindextype. But the ode tests run smoothly. One could argue that i have Sundials 4.1.0 on Linux versus 5.3.0 on Windows MXE Octave, so it is not a proof. But it is a "try and error".

However, if the root cause is a compatibility mismatch between the octave / sundial indices: The sunindextype can be either int32_t or int64_t (default), but it can't be unsigned. Fortunately, octave_idx_type is signed, although I know there have been discussions about switching to unsigned (see bug #54405). So up to know, the signedness is equal but the size can differ.

As you said, everything has changed since 5.2.0: Version number, _oct15_.cc implementation, etc. So i am bit stuck what i could do next.

Regarding the patch: Yes, it feels "better" to have the same CMAKE switches for other OS than Windows too. I will create an update.

Hg200 <hg200>
Tue 28 Jul 2020 08:15:48 AM UTC, comment #18: 

Sorry. That should have said: AFAICT, octave_idx_type is signed (either int32_t or int64_t).

Markus Mützel <mmuetzel>
Group administrator
Tue 28 Jul 2020 08:11:06 AM UTC, comment #17: 

Is there a reason, you set SUNDIALS_INDEX_SIZE only for Windows? Wouldn't that also be necessary on other platforms?
Can signed-ness be an issue? AFAICT, octave_idx_type is unsigned (either int32_t or int64_t). What type is sunindextype if SUNDIALS_INDEX_SIZE is set to 32 (or 64?)?

I'm also adapting the bug title to what is most likely the cause for the issue. It probably affects all platforms and isn't limited to Windows.

Markus Mützel <mmuetzel>
Group administrator
Tue 28 Jul 2020 12:15:12 AM UTC, comment #16: 

A small update to get rid of the deprecated warnings in the w32 logfile:


./mxe-octave/log/sundials-ida


Changes:


EXAMPLES_ENABLE
EXAMPLES_ENABLE_C
SUNDIALS_INDEX_TYPE
SUNDIALS_INDEX_SIZE



(file #49556)

Hg200 <hg200>
Mon 27 Jul 2020 04:42:30 PM UTC, comment #15: 

Good finding!

IIRC, the API of SUNDIALS IDA changed between versions. Octave 5 was using the API of version 2.7. Octave 6 and newer switched to a newer incompatible API. The older API is no longer available in newer versions of SUNDIALS IDA.

I haven't tested your patch. But it looks good at a quick view.

While that change is probably something we want to have in MXE Octave, maybe Octave should also use SUNDIALS IDA correctly independent on how SUNDIALS_INDEX_TYPE was configured.
I guess there might be places in Octave's code for SUDIALS IDA where octave_idx_type is used when it should use sunindextype instead.

Markus Mützel <mmuetzel>
Group administrator
Mon 27 Jul 2020 04:21:43 PM UTC, comment #14: 

I had a closer look to the ODE problem and can share following observations:

1.)
The following switch [1] solves the problem on the win32 target for me:


-DSUNDIALS_INDEX_TYPE=int32_t


With this, the testsuite-odetests run without errors. I am currently on Sundials-ida-5.3.0, mxe-Octave hg id a65cacd, Octave hg id a61b651 + fix bug #58807. A patch that sets the sundials index size to 32 if $(ENABLE_64) == "no" is attached. Would be good if somebody can confirm.

2.)
BLAS - switching has no effect (same as Markus reported in comment #13).

3.)
"ode15i" is not completely "dead". Some simple differential equations are solved correctly. Only "test ode15i" causes big trouble. Why?

4.)
"test ode15i" runs without errors under the Octave-5.2.0-win32 executable. So my question is: Did the problem come with a package update or have the compiler switches changed since Octave 5.2.0? The reason for the question is that "sunindextype" has been around for quite some time. So the question is, why is the problem occurring right now?

[1]: IDA v3.2.0: "... added the SUNDIALS_INDEX_TYPE CMake option to select the sunindextype integer size".

https://computing.llnl.gov/sites/default/files/public/ida_guide.pdf



(file #49555)

Hg200 <hg200>
Thu 23 Jul 2020 06:34:37 AM UTC, comment #13: 

The tests were done with the reference BLAS library.
For a test, I switched to OpenBLAS (in the SSE/SSE2 build). But the results are the same.

Markus Mützel <mmuetzel>
Group administrator
Wed 22 Jul 2020 09:07:08 PM UTC, comment #12: 

I always blame such obscure errors on problems with optimized
blas library. Could you guys try to compile with the reference blas library instead of (presumably) openblas library?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 22 Jul 2020 08:14:11 PM UTC, comment #11: 

All text that would be displayed in the shell should be stored in the log for each package. All logs are in the "log" folder in the MXE build(?) tree.
I'm not sure if SUNDIALS IDA can be more verbose. If it can, you could change the build rule in src/sundials-ida.mk accordingly and re-build. AFAICS, "VERBOSE=1" is already passed to "make".

Markus Mützel <mmuetzel>
Group administrator
Wed 22 Jul 2020 07:57:26 PM UTC, comment #10: 

How can we check the compiler warnings on sundials? Is there a verbose switch for mxe-octave?

Hg200 <hg200>
Wed 22 Jul 2020 07:05:26 PM UTC, comment #9: 

MXE Octave is used to build Octave and all of its dependencies. It also even builds the (cross-)compiler and other build tools to build the rest.
The patch I used in bug #58807 changes the gcc cross compilers to compile with SSE and SSE2 instructions by default also for the i686-w64-mingw32 target (setting the flags you showed here to be used by default).

I did not change any other build rules. But the other precision issues have disappeared. So I guess the patch did what it was meant to do.

I re-built Octave and all of its dependencies from scratch (with that modified cross-compiler). That includes all libraries that are packaged for Octave for Windows.

There is probably something else that is causing the issue here.

Markus Mützel <mmuetzel>
Group administrator
Wed 22 Jul 2020 03:00:36 PM UTC, comment #8: 

Ideally you need to recompile all the libraries with SSE enabled.
I suspect some iterative solvers are failing due to x87 quirks.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 22 Jul 2020 01:51:09 PM UTC, comment #7: 

The precision bugs are solved by using the SSE and SSE2 instructions (see bug #58807).

The tests for ode15i and ode15s still fail with the same error.

Markus Mützel <mmuetzel>
Group administrator
Wed 22 Jul 2020 10:59:20 AM UTC, comment #6: 

I opened bug #58807 for the precision(?) issues in some of the BISTs on Windows 32bit.

This bug here is about the failing IDA solver in "ode15i" and "ode15s".

Markus Mützel <mmuetzel>
Group administrator
Tue 21 Jul 2020 01:32:45 PM UTC, comment #5: 

That's not an "official" source. But it is probably good enough for us to know that Windows 7 with all available updates won't run on CPUs without SSE2.

Markus Mützel <mmuetzel>
Group administrator
Tue 21 Jul 2020 11:42:55 AM UTC, comment #4: 
Dmitri A. Sergatskov <dasergatskov>
Tue 21 Jul 2020 11:31:51 AM UTC, comment #3: 

Thanks for re-posting the lost message. (I mis-spelled "verbatim" in the closing tag of the first block.)


Do you have a source where MS specifies that Windows 7 requires a CPU with SSE2?

On their system requirements page [1], they don't specify any specific CPU instruction set.

The only thing I could find with a quick Google search is [2] where they recommend to update to a CPU supporting the SSE2 instruction set as a workaround for a known issue. (How bold is that?!)
But since Windows 7 is no longer supported by MS and an update for that issue is very unlikely, I guess that workaround might be a requirement now...


Anyway, any half-decent CPU that was bought in the last 20 years most likely supports SSE2. So it is probably ok to have that as a requirement for Octave on Windows.
It would probably solve (some of) the precision bugs for which I haven't opened a bug report yet. Not sure about this bug here though.
If it turns out that that would fix this bug (or others), we should probably ask on the mailing list about raising the minimum hardware requirements.


We would probably need to compile Octave itself and most (or all) of its dependencies with these switches. Is that also what you think?


[1]: https://support.microsoft.com/en-us/help/10737/windows-7-system-requirements
[2]: https://support.microsoft.com/en-us/help/4103718/windows-7-update-kb4103718

Markus Mützel <mmuetzel>
Group administrator
Tue 21 Jul 2020 10:44:10 AM UTC, comment #2: 

Markus:

I suspect that some of the erros in tests are due to 387
(default on x86 platform) vs SSE (default on x86_64).
Since even Win 7 requires CPU with SSE2,  I would recommend
compiling with "-mfpmath=sse -msse -msse2" flags.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 21 Jul 2020 10:39:13 AM UTC, comment #1: 

Somehow savannah does not display all the message.
Reposting from the email:


Details:

MXE Octave (hg id a65cacd05892) was configured to cross-compile Windows 32bit
executables with:

./configure --with-pkg-dir=../mxe-octave-pkg --with-ccache
--enable-octave=default --enable-binary-packages --enable-qt5
--enable-devel-tools --disable-windows-64 --disable-64 --disable-fortran-int64
--disable-system-opengl
-vebatim-

On Windows 10 2004 64bit (and according to bug #58790 also on Windows 7), the
tests for ode15i and ode15s fail with the following errors:

>> test ode15i

[IDA ERROR]  IDASolve
  At t = 0, the linear solver setup failed unrecoverably.

***** testif HAVE_SUNDIALS_SUNLINSOL_KLU
 opt = odeset ("Jacobian", @jacfunsparse, "AbsTol", 1e-7, "RelTol", 1e-7);
 [t, y] = ode15i (@rob, [0, 100], [1; 0; 0], [-1e-4; 1e-4; 0], opt);
 assert ([t(end), y(end,:)], fref, 1e-3);
!!!!! test failed
IDASolve failed
>> test ode15s

[IDA ERROR]  IDASolve
  At t = 0, the linear solver setup failed unrecoverably.

***** testif HAVE_SUNDIALS_SUNLINSOL_KLU
 opt = odeset ("MStateDependence", "none",
               "Mass", sparse ([1, 0, 0; 0, 1, 0; 0, 0, 0]),
               "Jacobian", @jacfunsparse);
 [t, y] = ode15s (@rob, [0, 100], [1; 0; 0], opt);
 assert ([t(end), y(end,:)], frefrob, 1e-3);
!!!!! test failed
IDASolve failed


This might be a problem with SUNDIALS IDA 32bit itself or with how we are
using it.

In case this should matter, MXE Octave bundles SUNDIALS IDA version 5.3.0 and
SuiteSparse version 5.7.2.


(That was Markus Mützel <mmuetzel> )

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Tue 21 Jul 2020 06:59:45 AM UTC, original submission:  

MXE Octave (hg id a65cacd05892) was configured to cross-compile Windows 32bit executables with:

./configure --with-pkg-dir=../mxe-octave-pkg --with-ccache --enable-octave=default --enable-binary-packages --enable-qt5 --enable-devel-tools --disable-windows-64 --disable-64 --disable-fortran-int64 --disable-system-opengl
-vebatim-

On Windows 10 2004 64bit (and according to bug #58790 also on Windows 7), the tests for ode15i and ode15s fail with the following errors:
+verbatim+
>> test ode15i

[IDA ERROR]  IDASolve
  At t = 0, the linear solver setup failed unrecoverably.

***** testif HAVE_SUNDIALS_SUNLINSOL_KLU
 opt = odeset ("Jacobian", @jacfunsparse, "AbsTol", 1e-7, "RelTol", 1e-7);
 [t, y] = ode15i (@rob, [0, 100], [1; 0; 0], [-1e-4; 1e-4; 0], opt);
 assert ([t(end), y(end,:)], fref, 1e-3);
!!!!! test failed
IDASolve failed
>> test ode15s

[IDA ERROR]  IDASolve
  At t = 0, the linear solver setup failed unrecoverably.

***** testif HAVE_SUNDIALS_SUNLINSOL_KLU
 opt = odeset ("MStateDependence", "none",
               "Mass", sparse ([1, 0, 0; 0, 1, 0; 0, 0, 0]),
               "Jacobian", @jacfunsparse);
 [t, y] = ode15s (@rob, [0, 100], [1; 0; 0], opt);
 assert ([t(end), y(end,:)], frefrob, 1e-3);
!!!!! test failed
IDASolve failed


This might be a problem with SUNDIALS IDA 32bit itself or with how we are using it.

In case this should matter, MXE Octave bundles SUNDIALS IDA version 5.3.0 and SuiteSparse version 5.7.2.

Markus Mützel <mmuetzel>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #49783:  bug58795_ode15_integer_types_v3.patch added by mmuetzel (10KiB - application/octet-stream)
file #49781:  tested__ode15__.cc added by hg200 (36KiB - text/x-c++src)
file #49780:  bug49503_build_octave_v3.patch added by mmuetzel (13KiB - application/octet-stream)
file #49737:  bug58795_ode15_integer_types_v2.patch added by mmuetzel (10KiB - application/octet-stream)
file #49735:  bug58795_ode15_integer_types.patch added by mmuetzel (10KiB - application/octet-stream)
file #49585:  bug58795_sunindextype.patch added by mmuetzel (3KiB - application/octet-stream)
file #49579:  mweode15isparse.m added by hg200 (783B - text/x-objcsrc)
file #49580:  mweode15i.m added by hg200 (759B - text/x-objcsrc)
file #49564:  patch_sundials_32t_v3.diff added by hg200 (3KiB - text/x-patch)
file #49556:  patch_sundials_32t_v2.diff added by hg200 (4KiB - text/x-patch)
file #49555:  patch_sundials_32t.diff added by hg200 (4KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by hg200 (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by mmuetzel (Submitted the item)
  •  

    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 22 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-09-13 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2020-09-11 mmuetzel StatusIn Progress Ready For Test
    2020-09-11 mmuetzel Attached File- Added bug58795_ode15_integer_types_v3.patch, #49783
    2020-09-10 hg200 Attached File- Added tested__ode15__.cc, #49781
    2020-09-10 mmuetzel Attached File- Added bug49503_build_octave_v3.patch, #49780
    2020-09-10 mmuetzel StatusReady For Test In Progress
    2020-09-10 mmuetzel StatusPatch Submitted Ready For Test
    2020-09-03 mmuetzel Attached File- Added bug58795_ode15_integer_types_v2.patch, #49737
    2020-09-03 mmuetzel Attached File- Added bug58795_ode15_integer_types.patch, #49735
        CategoryLibraries Interpreter
        StatusConfirmed Patch Submitted
    2020-07-30 mmuetzel Attached File- Added bug58795_sunindextype.patch, #49585
    2020-07-30 mmuetzel Summaryode15i and ode15s fail if sunindextype and octave_idx_type are incompatible ode15i and ode15s fail for Windows 32bit
    2020-07-30 hg200 Attached File- Added mweode15isparse.m, #49579
        Attached File- Added mweode15i.m, #49580
    2020-07-28 hg200 Attached File- Added patch_sundials_32t_v3.diff, #49564
    2020-07-28 mmuetzel StatusNone Confirmed
        Operating SystemMicrosoft Windows Any
        SummaryTests for ode15i and ode15s fail for Octave 32bit on Windows ode15i and ode15s fail if sunindextype and octave_idx_type are incompatible
    2020-07-28 hg200 Attached File- Added patch_sundials_32t_v2.diff, #49556
    2020-07-27 hg200 Attached File- Added patch_sundials_32t.diff, #49555

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code