Sun 10 Jul 2016 12:10:35 AM UTC, comment #18:
Thank you for testing, I've updated the patch to recent changes and pushed to default
http://hg.savannah.gnu.org/hgweb/octave/rev/a5a99a830c8c
|
Sat 09 Jul 2016 01:36:55 PM UTC, comment #17:
@Mike,
Compiling octave with your patch I get
|
Thu 07 Jul 2016 09:17:37 PM UTC, comment #16:
Sorry, that patch doesn't compile, use this updated one instead.
(file #37763)
|
Thu 07 Jul 2016 08:58:43 PM UTC, comment #15:
Attached.
(file #37761)
|
Thu 07 Jul 2016 08:58:22 PM UTC, comment #14:
Try the attached patch.
Please report if this works, whether the value of fpucw is correct when Octave starts up (both with and without Java), and whether tests like assert.m (bug #48365) or axis.m (bug #48364) are also fixed with this patch.
|
Thu 07 Jul 2016 10:01:29 AM UTC, comment #13:
@Mike:
If I change the name of bug-46330.tst, the test ends with 11 failures. If you submit a patch that calls octave_set_default_fpucw(), I can check it.
|
Thu 07 Jul 2016 06:31:36 AM UTC, comment #12:
It appears to be the case that 32-bit Windows processes set the FPU control word to use double precision instead of extended precision. This differs from the default behavior on GNU/Linux, and thus the test result differences by a few eps.
We could easily add a call to octave_set_default_fpucw() when Octave first starts up. This would probably fix this bug, as well as bug #48364 and bug #48365.
|
Thu 07 Jul 2016 05:28:00 AM UTC, comment #11:
The crash is due to bug-46330.tst add in changeset
d3c79eb1b483. Not related to Java disabling.
|
Thu 07 Jul 2016 04:06:28 AM UTC, comment #10:
Building with disable-java
Last command caused Octave to crash.
|
Wed 06 Jul 2016 10:16:27 PM UTC, comment #9:
@Mike: If this is correct, this would probably explain the other three bug reports about _run_test_suite_. They are mostly tolerance errors of just a few eps. If we are using truncated intermediate results during calculation more error is going to build up than is expected.
|
Wed 06 Jul 2016 09:04:17 PM UTC, comment #8:
Rik: that saving and restoring of the FPUCW is currently in effect. The value that Avinoam sees after running Java is the correct one, 0x37f, which tells the processor to use 80-bit extended precision floating point for intermediate values. The initial value, when the tests fail, 0x27f tells the processor to truncate all intermediate results to 64-bit double precision values.
So the code to restore the correct value of the FPUCW is working, because it gets the right value after a Java call. But the initial value is wrong, and I wonder if it's wrong all the time (which is why I want to see the results in a non-Java 32-bit build), or wrong because the JVM is linked into Octave and it is changing the default when Octave starts up, even if it hasn't been called yet.
|
Wed 06 Jul 2016 07:25:03 PM UTC, comment #7:
We ran into this problem somewhere before as well where the JVM was changing deep internal flags of the CPU resulting in different math behavior. Unfortunately, the fix might be to save/restore flags before every call to the JVM.
|
Wed 06 Jul 2016 04:13:50 PM UTC, comment #6:
This will take a few hours :-)
|
Wed 06 Jul 2016 04:05:23 PM UTC, comment #5:
Excellent, thank you, that confirms what I thought. Now I'm looking forward to seeing what the value of the register is when you run it in a non-Java-enabled 32-bit Octave.
|
Wed 06 Jul 2016 04:03:46 PM UTC, comment #4:
I get the values of 0x037f only after calling a Java function.
|
Wed 06 Jul 2016 03:42:50 PM UTC, comment #3:
Use the attached function, build with mkoctfile and run "fpucw" in Octave.
The expected value is
(file #37733)
|
Wed 06 Jul 2016 04:57:48 AM UTC, comment #2:
I can build mxe-octave 32-bit cross-build with --disable-java.
How do I look for the value of the FPU control word?
|
Wed 06 Jul 2016 04:46:38 AM UTC, comment #1:
Testing a mxe-octave 32-bit cross-build with --disable-java would allow run_test_suite to run without loading any Java classes, and would help identify whether the tests still fail without Java present, and which tests are failing. Can you or someone else try that and report any test failures that are not already reported?
The reason for the test results changing after loading/running Java may have to do with the Intel floating point control word.
It would be worth looking at the value of the FPU control word when Octave starts, when the tests fail, and after calling a Java function when the tests pass.
|
Wed 06 Jul 2016 03:59:02 AM UTC, original submission:
Some tests fails, but these failures are not seen when running
__tun_test_suite__
for example:
This is becauase of test libinterp\octave-value\ov-class.cc-tst
And the reason is jobj = javaObject ("java.lang.StringBuffer");
Some of the test fails when running alone, but pass when running with __tun_test_suite__
|