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

 
 

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

Submitted by:  Markus Mützel <mmuetzel>
Submitted on:  Tue 21 Jul 2020 06:59:45 AM UTC  
 
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

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>
Project Member
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>
Project Member
Thu 30 Jul 2020 06:40:10 PM UTC, comment #41: 
Markus Mützel <mmuetzel>
Project Member
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>
Project 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>
Project 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>
Project Member
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>
Project 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>
Project Member
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>
Project 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>
Project 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>
Project Member
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>
Project 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>
Project 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>
Project 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>
Project Member
Thu 30 Jul 2020 01:48:41 PM UTC, comment #27: 

Got that wrong.
Sorry for the noise.

Markus Mützel <mmuetzel>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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>
Project Member
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:

Markus Mützel <mmuetzel>
Project Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    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.5