bugGNU Octave - Bugs: bug #48418, MXE Octave: __run_test_suite__ has...

 
 

bug #48418: MXE Octave: __run_test_suite__ has wrong results

Submitted by:  Avinoam Kalma <avinoam>
Submitted on:  Wed 06 Jul 2016 03:59:02 AM UTC  
 
Category: Octave FunctionSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: FixedAssigned to: None
Originator Name: AvinoamOpen/Closed: Closed
Release: devOperating System: Microsoft Windows

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 Jump to the original submission)

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

Mike Miller <mtmiller>
Project Administrator
Sat 09 Jul 2016 01:36:55 PM UTC, comment #17:

@Mike,
Compiling octave with your patch I get

Avinoam Kalma <avinoam>
Project Member
Thu 07 Jul 2016 09:17:37 PM UTC, comment #16:

Sorry, that patch doesn't compile, use this updated one instead.

(file #37763)

Mike Miller <mtmiller>
Project Administrator
Thu 07 Jul 2016 08:58:43 PM UTC, comment #15:

Attached.

(file #37761)

Mike Miller <mtmiller>
Project Administrator
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.

Mike Miller <mtmiller>
Project Administrator
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.

Avinoam Kalma <avinoam>
Project Member
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.

Mike Miller <mtmiller>
Project Administrator
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.

Avinoam Kalma <avinoam>
Project Member
Thu 07 Jul 2016 04:06:28 AM UTC, comment #10:

Building with disable-java

Last command caused Octave to crash.

Avinoam Kalma <avinoam>
Project Member
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.

Rik <rik5>
Project Administrator
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.

Mike Miller <mtmiller>
Project Administrator
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.

Rik <rik5>
Project Administrator
Wed 06 Jul 2016 04:13:50 PM UTC, comment #6:

This will take a few hours :-)

Avinoam Kalma <avinoam>
Project Member
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.

Mike Miller <mtmiller>
Project Administrator
Wed 06 Jul 2016 04:03:46 PM UTC, comment #4:

I get the values of 0x037f only after calling a Java function.

Avinoam Kalma <avinoam>
Project Member
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)

Mike Miller <mtmiller>
Project Administrator
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?

Avinoam Kalma <avinoam>
Project Member
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.

Mike Miller <mtmiller>
Project Administrator
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__

Avinoam Kalma <avinoam>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #37763:  bug-48418.patch added by mtmiller (1KiB - text/x-diff)
file #37761:  bug-48418.patch added by mtmiller (833B - text/x-diff)
file #37733:  fpucw.cc added by mtmiller (1KiB - text/x-c++src)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by avinoam (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 project members can vote.

     

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

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 10 Jul 2016 12:10:35 AM UTCmtmillerStatusNeed Info=>Fixed
      Open/ClosedOpen=>Closed
    Thu 07 Jul 2016 09:17:37 PM UTCmtmillerAttached File-=>Added bug-48418.patch, #37763
    Thu 07 Jul 2016 08:58:43 PM UTCmtmillerAttached File-=>Added bug-48418.patch, #37761
    Wed 06 Jul 2016 03:42:50 PM UTCmtmillerAttached File-=>Added fpucw.cc, #37733
    Wed 06 Jul 2016 04:46:38 AM UTCmtmillerStatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup1