octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #58795] ode15i and ode15s fail for Windows 32b


From: Markus Mützel
Subject: [Octave-bug-tracker] [bug #58795] ode15i and ode15s fail for Windows 32bit
Date: Thu, 10 Sep 2020 14:06:46 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 Edg/85.0.564.44

Follow-up Comment #55, bug #58795 (project octave):

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)
    _______________________________________________________

Additional Item Attachment:

File name: bug49503_build_octave_v3.patch Size:12 KB
   
<https://file.savannah.gnu.org/file/bug49503_build_octave_v3.patch?file_id=49780>



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58795>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]