bugGNU Octave - Bugs: bug #48363, __run-test_suite_ FAILs for...

 
 

bug #48363: __run-test_suite_ FAILs for data.cc-tst ('NaN' mismatches)

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Fri 01 Jul 2016 01:27:47 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Inaccurate Result
Status:  Fixed Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 13 Jul 2016 07:34:01 PM UTC, comment #19: 

Yes, thank you.

Unfortunately we have no checks in place right now that bootstrap has been run. The build will either fail or it will produce unexpected results like this. I'm guessing that's what happened, the frexp functions in libgnu were not used and the system versions were used instead. In another case it might be a function from gnulib that doesn't exist on the system, and it will show up as a build error.

Mike Miller <mtmiller>
Group Member
Wed 13 Jul 2016 06:59:21 PM UTC, comment #18: 

OK you wanted to see this:

:
libinterp\corefcn\data.cc-tst ............................... PASS   1005/1005
:


Now the frexp entries are found in config.log as well.
I still wonder why they didn't show up the first time, but most importantly the fix works.
Thanks!

In the mean time--run_test_suite__ is already hanging for several minutes in syscalls-cc.tst, but that must be another issue

Philip Nienhuis <philipnienhuis>
Group Member
Wed 13 Jul 2016 05:14:36 PM UTC, comment #17: 

I'm even quite sure I ran ./bootstrap - it's in my bash history just before the ./dev/configure && make -j3 && make check command.

Nevertheless I'm happy to start all over again and let it build during preparing dinner... :-)

Philip Nienhuis <philipnienhuis>
Group Member
Wed 13 Jul 2016 05:08:50 PM UTC, comment #16: 


>> __octave_config_info__ hg_id
ans = 5ad67277b007+


Is there anyway to check (on Linux side) whether ./bootstrap has run?
I'm quite sure I did run it, but I try again, no problem.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 13 Jul 2016 03:27:13 PM UTC, comment #15: 

No, something's not right with this build, sorry. It's either not the changeset you thought it was or something wasn't bootstrapped or done right. (Unfortunately the hg id is not written to config.log, you'll have to do "__octave_config_info__ hg_id".)

If frexp and frexpf don't show up at all in config.log, then something was not included correctly.

Mike Miller <mtmiller>
Group Member
Wed 13 Jul 2016 09:41:34 AM UTC, comment #14: 

In that particular build by me (which I think is from after your cset from comment #11):

$ sed -n '/checking.*frexp/,/ result:/p' config.log

<nothing>


That config.log is attached (zipped).

Then:

$ nm liboctave.dll.a | grep frexp
0000000000000000 I __imp_octave_frexpf_wrapper
0000000000000000 T octave_frexpf_wrapper
0000000000000000 I __imp_octave_frexp_wrapper
0000000000000000 T octave_frexp_wrapper
0000000000000000 I __imp__ZN6octave4math5frexpEfPi
0000000000000000 T _ZN6octave4math5frexpEfPi
0000000000000000 I __imp__ZN6octave4math5frexpEdPi
0000000000000000 T _ZN6octave4math5frexpEdPi


In a 4.0.3 build (64-bit) I get:

:
libinterp\corefcn\data.cc-tst ............................... PASS    967/967
:


Yesterday I've made a new build ("clean", i.e., w/o my usual personal patch collection). Tonight I'll try that one after installing it.


(file #37841)

Philip Nienhuis <philipnienhuis>
Group Member
Tue 12 Jul 2016 04:31:50 PM UTC, comment #13: 

Ok, here's what I would check next.

The file D:\Octave\Octave-4.1.0+VEp_w64_20160711\share\octave\4.1.0+\etc\config.log should contain the full configuration of the build. Either share the whole file, or search for strings that look like this (pulled from the official 4.0.3 build):


$ sed -n '/checking.*frexp/,/ result:/p' config.log
configure:44942: checking whether frexp() can be used without linking with libm
configure:44968: i686-w64-mingw32-gcc -o conftest.exe -g -O2 -pthread  -I/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/include -Wl,-rpath-link,/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/lib -L/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/lib conftest.c -lm   -lgdi32 -lws2_32 -luser32 -lkernel32 -lgdi32 -lws2_32 -luser32 -lkernel32 >&5
configure:44968: $? = 0
configure:44977: result: yes
configure:56034: checking whether frexp works
configure:56125: result: guessing no
configure:56181: checking whether frexpf can be used without linking with libm
configure:56218: i686-w64-mingw32-gcc -o conftest.exe -g -O2 -pthread  -I/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/include -Wl,-rpath-link,/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/lib -L/scratch/jwe/mxe-octave/usr/i686-w64-mingw32/lib conftest.c -lm   -lgdi32 -lws2_32 -luser32 -lkernel32 -lgdi32 -lws2_32 -luser32 -lkernel32 >&5
configure:56218: $? = 0
configure:56227: result: yes
configure:56296: checking whether frexpf works
configure:56364: result: guessing no


Next I would check liboctave to see whether it's linking with the system's frexp and frexpf functions or the gnulib replacements.


$ cd D:\Octave\Octave-4.1.0+VEp_w64_20160711\lib\octave\4.1.0+
$ nm liboctave.dll.a | grep frexp
00000000 I __imp__rpl_frexpf
00000000 T _rpl_frexpf
00000000 I __imp__rpl_frexp
00000000 T _rpl_frexp


The nm program should be in Octave's bin directory. This is the output I see for the library in the 4.0.3 release, should be the same in your build.

By the way, if you have a 4.0.x can you verify that this test did not fail there, that this only started failing on recent builds from default (corresponding to when the gnulib cleanup started)?

Mike Miller <mtmiller>
Group Member
Tue 12 Jul 2016 01:37:50 PM UTC, comment #12: 

Not fixed in a 64-bit (--enable-windows-64 configured) MXE cross-build from July 11 (not sure but hg id >= 67a44207da71)


[...]
>>>>> processing D:\Octave\Octave-4.1.0+VEp_w64_20160711\share\octave\4.1.0+\etc\tests\libinterp\corefcn\data.cc-tst
***** test
 [f, e] = log2 ([0,-1; 2,-4; Inf,-Inf]);
 assert (f, [0,-0.5; 0.5,-0.5; Inf,-Inf]);
 assert (e(1:2,:), [0,1;2,3]);
!!!!! test failed
ASSERT errors for:  assert (f,[0, -0.5; 0.5, -0.5; Inf, -Inf])

  Location  |  Observed  |  Expected  |  Reason
   (3,1)         NaN          Inf        'NaN' mismatch
   (3,2)         NaN          -Inf       'NaN' mismatch

[...]

***** test
 [f, e] = log2 (complex (zeros (3, 2), [0,-1; 2,-4; Inf,-Inf]));
 assert (f, complex (zeros (3, 2), [0,-0.5; 0.5,-0.5; Inf,-Inf]));
 assert (e(1:2,:), [0,1; 2,3]);
!!!!! test failed
ASSERT errors for:  assert (f,complex (zeros (3, 2), [0, -0.5; 0.5, -0.5; Inf, -Inf]))

  Location  |  Observed  |  Expected  |  Reason
   (3,1)       NaN+NaNi      0+Infi      'NaN' mismatch
   (3,2)       NaN+NaNi      0-Infi      'NaN' mismatch


Philip Nienhuis <philipnienhuis>
Group Member
Sat 09 Jul 2016 12:36:33 AM UTC, comment #11: 

No test results on Windows, but pushed anyway, guess we'll find out eventually if this fixes it.

http://hg.savannah.gnu.org/hgweb/octave/rev/e0dbd81fd9b1

Mike Miller <mtmiller>
Group Member
Tue 05 Jul 2016 03:51:55 PM UTC, comment #10: 

I'll file a different bug report about the extra gnulib functions.  I agree that it probably makes little difference, but I also don't like the untidyness of having chunks of code around that we aren't using.

Rik <rik5>
Group administrator
Tue 05 Jul 2016 03:25:35 PM UTC, comment #9: 

Re comment #7: Yes, my mistake, I copied existing files and missed the Copyright line.

Re comment #8: Maybe, but that's a lower priority issue. Having the modules around won't hurt anything, it will only make the configure process a little slower and compile a few extra objects that we may not link to.

Mike Miller <mtmiller>
Group Member
Tue 05 Jul 2016 03:20:27 PM UTC, comment #8: 

@Mike: I noticed your comment "since we have amassed quite a list of math functions in bootstrap.conf over the years, none of which we are using now".  Should there be a separate bug report to prune bootstrap.conf before the 4.2 release?

Rik <rik5>
Group administrator
Tue 05 Jul 2016 06:38:57 AM UTC, comment #7: 

Mike, shouldn't you (not jwe) be listed in the copyright lines of the new files?

Lachlan Andrew <lachlan>
Sun 03 Jul 2016 04:58:37 PM UTC, comment #6: 

Yes, we could add a wrapper, it would be something like the attached (needs testing on Windows, but should work).

I named the file "math-wrappers" with the expectation that we may need to do the same for other math functions from gnulib (since we have amassed quite a list of math functions in bootstrap.conf over the years, none of which we are using now).

(file #37689)

Mike Miller <mtmiller>
Group Member
Sun 03 Jul 2016 03:07:58 PM UTC, comment #5: 

I haven't been following jwe's changes closely, but he seems to have been placing wrappers around gnulib functions so they are called as straight 'C' functions, rather than having the C++ compiler use it's own choices.  Maybe aske him if we can use that trick to access the gnulib replacement for frexp.

Rik <rik5>
Group administrator
Sun 03 Jul 2016 04:31:15 AM UTC, comment #4: 

The two-output-argument form is calling std::frexp, the single-return-value form is calling std::log2.

Ah, according to the gnulib manual section on frexp, this may have been fixed before when we were using gnulib, which we lost recently:

> This function does not work on infinite numbers on some
> platforms: IRIX 6.5, mingw, MSVC 9


(from https://www.gnu.org/software/gnulib/manual/html_node/frexp.html)

So this is exactly the type of bug that we were trying to fix by using gnulib, but GCC 6 has decided is bad to try to address (because they want std::frexp to only be able to call the system C library frexp function, not any replacement you may define).

Mike Miller <mtmiller>
Group Member
Fri 01 Jul 2016 05:03:50 PM UTC, comment #3: 

It is probably worth tracing this code down.  It runs from Flog2 in data.cc in libinterp to liboctave/numeric/lo-mappers.cc.  We are using C++ std::log2, but also std::log and std::frexp.  Testing with a Windows VM shows there is a clear difference when different code paths are used.


f = log2 ([Inf, -Inf])
f =

       Inf + 0.00000i       Inf + 4.53236i


This result is the same as Linux.

The two argument form, which is the failing one, is


[f, e] = log2 ([Inf, -Inf])
f =

   NaN   NaN

e =

  -1  -1



Rik <rik5>
Group administrator
Fri 01 Jul 2016 04:18:13 PM UTC, comment #2: 

Should we just put a "if (! ispc () || isunix ())" and a comment around that assert if there is nothing we can do about it?

Mike Miller <mtmiller>
Group Member
Fri 01 Jul 2016 03:39:19 PM UTC, comment #1: 

Hasn't this always been the case?  I believe it is the C lib implementation of log2 on Windows.  Maybe try searching the bug reports or the the history of octave-maintainers on Nabble.  I know its been discussed, I can't remember if there was any resolution.

Rik <rik5>
Group administrator
Fri 01 Jul 2016 01:27:47 PM UTC, original submission:  


>>>>> processing L:\philip\devel\octdev\mxe\mxe_64b_20160623\dist\octave-2016-07-01-12-48\share\octave\4.1.0+\etc\tests\libinterp\corefcn\data.cc-tst
***** test
 [f, e] = log2 ([0,-1; 2,-4; Inf,-Inf]);
 assert (f, [0,-0.5; 0.5,-0.5; Inf,-Inf]);
 assert (e(1:2,:), [0,1;2,3]);
!!!!! test failed
ASSERT errors for:  assert (f,[0, -0.5; 0.5, -0.5; Inf, -Inf])

  Location  |  Observed  |  Expected  |  Reason
   (3,1)         NaN          Inf        'NaN' mismatch
   (3,2)         NaN          -Inf       'NaN' mismatch
shared variables
  scalar structure containing the fields:

    xs =

Compressed Column Sparse (rows = 1, cols = 4, nnz = 3 [75%])

  (1, 2) ->  1
  (1, 3) ->  2
  (1, 4) ->  3

***** test
 [f, e] = log2 (complex (zeros (3, 2), [0,-1; 2,-4; Inf,-Inf]));
 assert (f, complex (zeros (3, 2), [0,-0.5; 0.5,-0.5; Inf,-Inf]));
 assert (e(1:2,:), [0,1; 2,3]);
!!!!! test failed
ASSERT errors for:  assert (f,complex (zeros (3, 2), [0, -0.5; 0.5, -0.5; Inf, -Inf]))

  Location  |  Observed  |  Expected  |  Reason
   (3,1)       NaN+NaNi      0+Infi      'NaN' mismatch
   (3,2)       NaN+NaNi      0-Infi      'NaN' mismatch
shared variables
  scalar structure containing the fields:

    xs =

Compressed Column Sparse (rows = 1, cols = 4, nnz = 3 [75%])

  (1, 2) ->  1
  (1, 3) ->  2
  (1, 4) ->  3


Philip Nienhuis <philipnienhuis>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #37841:  config.zip added by philipnienhuis (184KiB - application/zip)
file #37689:  liboctave-frexp.patch added by mtmiller (7KiB - text/x-diff)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by lachlan (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-07-13 mtmiller StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2016-07-13 philipnienhuis Attached File- Added config.zip, #37841
    2016-07-09 mtmiller StatusNone Ready For Test
        Summary_run-test_suite FAILs for data-cc.tst ('NaN' mismatches) _run-test_suite FAILs for data.cc-tst ('NaN' mismatches)
    2016-07-03 mtmiller Attached File- Added liboctave-frexp.patch, #37689

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code