taskGNU Octave - Tasks: task #13313, MingW issues for Octave built w...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #13313: MingW issues for Octave built w --enable-64

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Fri 05 Sep 2014 07:43:25 PM UTC  
 
Should Start On: Thu 04 Sep 2014 10:00:00 PM UTCShould be Finished on: Thu 04 Sep 2014 10:00:00 PM UTC
Category: NonePriority: 5 - Normal
Status: NonePrivacy: Public
Assigned to: NoneOriginator Name: Philip Nienhuis
Open/Closed: OpenFixed Release: None
Planned Release: None

(Jump to the original submission Jump to the original submission)

Sat 10 Oct 2015 07:03:40 PM UTC, comment #9:

Can this task be closed now?

AFAICS there are just one or two OF packages that do not build properly with 64-bit indexing; JohnD has fixed several others.

I had a test run with a 64-bit build (cset 56333f6df823, Oct. 10, 2015) on Windows with _run_test_suite_ and got only 3 fails now, all related to tolerances that appear insignificant to me (but OK that's just me):

axis.m:

lscov.m:

assert.m:

Philip Nienhuis <philipnienhuis>
Project Member
Sun 05 Oct 2014 02:53:22 PM UTC, comment #8:

I checked in the following changeset. It seems to fix the strange problem with the loop counter in the eig.cc tests.

http://hg.savannah.gnu.org/hgweb/octave/rev/0279c601b49c

I'm not sure why this fix works to avoid that problem. But either way, it seems better to me that we use a consistent method for calculating the elements of the range and I think the best way to do that is to perform that calculation in a method in the Range class instead of duplicating the code elsewhere.

John W. Eaton <jwe>
Project Administrator
Thu 11 Sep 2014 01:44:25 PM UTC, comment #7:

Sorry I didn't initially understand what you meant with "out of range inside the test function itself".
Only later on I found that all tests in eig.cc_tst pass when run by hand and that the problem lies in test.m itself.

I stepped through Octave-3.8.2's test.m (applying it to eig.cc_tst with test #17 uncommented); I found that as soon as the loop counter __i in L.244 gets > 16 it doesn't get to be 17 as expected, but instead turns into 1.0224e-314. Looks like an erroneous cast from double to integer, or wraparound (but I'd rather expect wraparound when __i goes from 15 to 16).

In libinterp/octave-value/ov.h there's the following (L. 180-191):

===========<QUOTE>===========
// FIXME: these are kluges. They turn into doubles
// internally, which will break for very large values. We just use
// them to store things like 64-bit ino_t, etc, and hope that those
// values are never actually larger than can be represented exactly
// in a double..

#if defined (HAVE_LONG_LONG_INT)
octave_value (long long int i);
#endif
#if defined (HAVE_UNSIGNED_LONG_LONG_INT)
octave_value (unsigned long long int i);
#endif
===========</QUOTE>===========

Could that be related to what we see in test.m ? Or is it a problem in the interpreter, triggered/provoked by the try-catch blocks in test.m?
Could that also be a relation with the tolerances seen in failing tests for e.g., axis.m and assert.m in my original post?

Philip Nienhuis <philipnienhuis>
Project Member
Sun 07 Sep 2014 02:49:22 PM UTC, comment #6:

I suppose people would want 64-bit Octave with 64-bit indexing. Isn't that the point of 64-bit?

Didn't you get FAILs in eig.cc-tst before you checked in that cs? (I'm referring to the last 4 input validation tests in eigs.cc-tst.) I got those consistently with --enable-64.
Indeed eigs.cc tests pass fine on Octave built for Linux (Mageia-4 64 bit).
I suppose a compiler bug cannot be ruled out. I got those FAILs also before gcc in MXE was upgraded to 4.9.0. But indeed - maybe those tests are too lax and simply don't trigger on Linux. I'd expect (= hope for) identical behavior on Linux and Windows.

OT: What is the reason that Ghostcript isn't built for 64-bit Octave? didn't it get built properly with mingw-64?

Philip Nienhuis <philipnienhuis>
Project Member
Sun 07 Sep 2014 10:52:42 AM UTC, comment #5:

I checked in the following change

http://hg.octave.org/mxe-octave/rev/1220a9158bc1

to make building a 64-bit Windows binary independent of building Octave with 64-bit indexing.

Interestingly, after building with --enable-windows-64 and not --enable-64, I get the same strange failure in eigs.cc-tst about an index being out of range inside the test function itself. That seems to indicate that this problem is not related to 64-bit indexing in Octave. Further, since this doesn't happen on my 64-bit Debian system, perhaps this is a compiler bug that is specific to Windows systems? Or the bug is present on both systems, and it just doesn't cause a problem on the Debian system purely by chance?

John W. Eaton <jwe>
Project Administrator
Fri 05 Sep 2014 09:16:09 PM UTC, comment #4:

The improved speed you see might just be that w64 is better than w32.

I don't think there is currently a way to ask for a w64 build without also building for 64-bit indexing, but these concepts should probably be separate, same as they are for other 64-bit operating systems where Fortran integers (and thus Octave indexing) is normally 32-bits instead of 64-bits.

John W. Eaton <jwe>
Project Administrator
Fri 05 Sep 2014 08:46:20 PM UTC, comment #3:

(I posted this all in the Task tracker as I suppose 64-bit builds do not have a relatively high priority at present.)

Unstable Octave
===============

MXE (cross-)builds for MinGW with --enable-64 break on qthandles (both 3.9.0+ and 4.1.0+):

Philip Nienhuis <philipnienhuis>
Project Member
Fri 05 Sep 2014 08:39:12 PM UTC, comment #2:

It is not a complaint from my side, not quite. Maybe from Windows...

Anyway I'm very happy with the 64-bit builds. I have the impression that they're faster than 32-bit Octave as well; loading 250 MB v7 .mat files (that expand to almost 1 GB in RAM) seems about twice as fast and OOM errors I often met with them have gone.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 05 Sep 2014 07:54:31 PM UTC, comment #1:

64-bit pointers are required for building Octave with --enable-64, so it makes no sense to complain that Octave configured this way won't run on Windows 32.

John W. Eaton <jwe>
Project Administrator
Fri 05 Sep 2014 07:43:25 PM UTC, original submission:

General
=======
Altough formally the --enable-64 flag indicates only 64-bit indexes, Octave for MinGW built with this flag is really a 64-bit Windows program (Windows XP 32bit complains that "Octave.exe is not a valid win32 program"; on Windows 7, compatibility settings listed for 64-bit Octave exclude all 32-bit Windows variants).

HDF5
====
See bug #43101

sparse.tst
==========

In later builds (after patching hdf5 cf. bug #43101) there's a hard crash.
Note it is the "sparse (af)" in the assert stmt. statement that provokes the crash, not so much writing/reading the hdf5 file.

Java
====
Octave64 expects a 64-bit JRE. I found that when Octave has been cross-built on a 64-bit Linux box, it expects jvm.dll to be in C:\Program Files\Java\jre7\bin\server, however when Octave has been cross-built on 32-bit Linux (with 32-bit JDK) it expects jvm.dll to be in C:\Program Files\Java\jre7\bin\client. Simply copying the client subdir + contents to a server subdir (or vice versa) in the same place in the Java JRE directory tree suffices.

I think this had better be fixed so that Octave64 always expects jvm.dll to be in the server/ subdir for 64-bit systems, as seems to be customary for 64-bit JRE/JDK.

Note: At least on Windows 64-bit it is perfectly possible to have both a 32-bit and a 64-bit JRE (or JDK) coexisting peacefully. The 64-bit one lives in C:\Program Files\, the 32-bit version in C:\Program Files (X86)\

AFAICS Java class libs (.jar files) are agnostic as to whether they're called from a 32-bit or a 64-bit JRE.
BUT... non-Java programs living behind those .jar files do care, e.g., OpenOffice or LibreOffice when invoked through the UNO spreadsheet interface in the io package. I couldn't get 32-bit LibreOffice invoked through Octave-Forge io package's UNO interface on my 64-bit Win7 box. It only works with 32-bit Octave.

Octave-Forge packages
=====================
Installation of some OF packages included in mxe-octave fail, apparently (AFAICS) due to ambiguous casts / data types:

data-smoothing
fl-core
fuzzy-logic
image
io (.mex; already fixed locally, replaced by .oct. Will push later)
netcdf
odepkg
optim
quaternion

Formal Octave test suite
========================
Currently Octave64 crashes on the eig_cc.tst.
That is due to the last 4 tests in eig_cc.tst; luckily, these do not test actual numerical stuff but merely input validation.
As a kludge, commenting out those tests lets Octave64 finish the test suite. But obviously that is not the proper way to deal with it.

At first sight, Octave64 may yield several (~12 IIRC) Java-related test failures. See above (32-bit vs. 64-bit JRE) for a solution.

Next there are several test failure related to tolerances:

chop.m:
=======

num2str.m:
==========

axis.m:
=======

assert.m:
=========

All of these appear to be simple tolerance issues.

The below FAIL seems different:

bug-38691.tst
=============

Finally, fcn-handle test has an issue related to Octave's search path.

fcn-handle-derived-resolution.tst
=================================
***** test
p = parent (7);
assert (numel (p), 7)
!!!!! test failed
'__trace__' undefined near line 2 column 3
***** test
d = derived (13);
assert (numel (d), 13)
!!!!! test failed
'__trace__' undefined near line 2 column 3
***** test
p = parent (11);
f = @numel;
assert (f (p), 11)
!!!!! test failed
'__trace__' undefined near line 2 column 3
***** test
d = parent (21);
f = @numel;
assert (f (d), 21)
!!!!! test failed
'__trace__' undefined near line 2 column 3
***** test
o(1) = other (13);
o(2) = other (42);
assert (getsize_loop (o), [13, 42])
!!!!! test failed
'__trace__' undefined near line 2 column 3
***** test
o(1) = other (13);
o(2) = other (42);
assert (getsize_cellfun (o), [13, 42])
!!!!! test failed
'__trace__' undefined near line 2 column 3
***** test
o(1) = other (13);
o(2) = other (42);
assert (getsize_arrayfun (o), [13, 42])
!!!!! test failed
'__trace__' undefined near line 2 column 3
-verbatim-

...but when the tests are run manually, they all pass.

So all in all, ignoring eig.cc.tst and HDF5, a 64-bit MinGW Octave-3.8.2 looks quite usable to me.

Philip Nienhuis <philipnienhuis>
Project Member

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by philipnienhuis (Submitted the item)
  •  

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    No Changes Have Been Made to This Item

    Back to the top


    Powered by Savane 3.1-cleanup1