Update tisean.yaml

[lostbard]

v0.2.4

[mmuetzel]

It looks like the tests for that package crashed Octave in the CI:

  Testing functions in package 'tisean':
  
  Integrated test scripts:
  
                                                                                    [ CPU    /  CLOCK ]
    ..packages/tisean-0.2.4/x86_64-pc-linux-gnu-api-v59/lazy.cc-tst  pass    4/4    [ 0.008s /  0.008s]
    ..ckages/tisean-0.2.4/x86_64-pc-linux-gnu-api-v59/mutual.cc-tst  pass    5/5    [ 0.013s /  0.013s]
  fatal: caught signal Segmentation fault -- stopping myself...
    /usr/share/octave/packages/tisean-0.2.4/av_d2.m ................
  Error: Process completed with exit code 139.

Is this something that needs to be fixed? Or should we just go ahead with this version anyway?

[lostbard]

yeah would be nice to fix but isnt happenig on my work machine - i was going to try a couple of others to see if I could recreate it

[mmuetzel]

Could that be the same issue that Dmitri reported on Savannah with address sanitizer?
https://savannah.gnu.org/bugs/?61583

  ..ri/.local/share/octave/api-v60/packages/tisean-0.2.4/lyap_r.m =================================================================
==669628==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7c1bbf9b4f68 at pc 0x7bfaa4e36cde bp 0x7bfa9da1c8d0 sp 0x7bfa9da1c8c8
READ of size 8 at 0x7c1bbf9b4f68 thread T10 (QThread)
    #0 0x7bfaa4e36cdd in F__lyap_r__(octave_value_list const&, int) /tmp/oct-FMgS89/tisean-0.2.4/src/__lyap_r__.cc:173:48
    #1 0x7ffbc7fb869d in octave::tree_evaluator::execute_builtin_function(octave_builtin&, int, octave_value_list const&) /home/dmitri/src/dev/octave/clang_asan/../libinterp/parse-tree/pt-eval.cc:3551:14

But then, the tests for lyap_r.m would probably have run after the tests for av_d2.m for which it apparently crashed in the CI...

[lostbard]

I can duplicate a crash in windows for av_d2
I think I know the problem so will see what need to do to fix

[lostbard]

Using this patch:

diff -r f93e77808612 src/configure.ac
--- a/src/configure.ac  Fri Apr 04 10:00:42 2025 -0400
+++ b/src/configure.ac  Sat Apr 05 08:06:44 2025 -0400
@@ -41,6 +41,14 @@
     [AC_MSG_RESULT([no])]
     [AC_MSG_ERROR([*** A fortran compiler with support for -freal-4-real-8 flag is required.])]
 )
+FFLAGS=-finteger-4-integer-8
+AC_MSG_CHECKING([whether $F77 supports -finteger-4-integer-8])
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([])],
+    [AC_MSG_RESULT([yes])]
+    [AM_FFLAGS="$AM_FFLAGS -finteger-4-integer-8"],
+    [AC_MSG_RESULT([no])]
+    [AC_MSG_ERROR([*** A fortran compiler with support for -finteger-4-integer-8 flag is required.])]
+)
 FFLAGS="$my_save_fflags"
 AC_SUBST([AM_FFLAGS])

I stop getting crashes at least on the windows machie that I saw them on.
However more tests fail which seems to be the otherr issue raise in the bug report.

[siko1056]

The CI Octave container image is using BLAS configured 64 Bit indices entirely:

• https://github.com/gnu-octave/docker/blob/348cfa2a2fc3d8c27a62f0ab4b8078335a7cf01c/build-octave-9.docker#L123
• https://github.com/gnu-octave/docker/blob/348cfa2a2fc3d8c27a62f0ab4b8078335a7cf01c/build-octave-9.docker#L270-L271

Does the tisean package detect and respect the Octave configuration?

[siko1056]

gfortran also states a warning about the suitability of the flag -finteger-4-integer-8:

This option should be used with care and may not be suitable for your codes. Areas of possible concern include calls to external procedures [...]

--- https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html#index-finteger-4-integer-8

Where I assume "external procedures" could be calls to BLAS procedures configured with 8 bit indices explicitly in this case?

[lostbard]

yeah i dont use fortran so cant comment much on what it is or isnt doing.

Apart from the flags set in configure for real-4-8 and patch above for int-4-8, it is using whatever mkoctfile uses.

Without the int-4 patch, I see warnings in windows for values of INT(4) and INT(8) conflicts

[mmuetzel]

Fwiw, MXE Octave uses the Fortran flag -fdefault-integer-8 when linking to Fortran libraries with 64-bit integers. I don't know how that differs from -finteger-4-integer-8 though.

In general: Should we really use a Docker image which contains Fortran libraries with (fairly uncommon) 64-bit default Fortran integer size? Would it be better to use the default 32-bit Fortran integer size in the CI instead?
Is support for 64-bit Fortran integers a requirement for Octave packages?