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

 
 

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

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Fri 01 Jul 2016 01:27:47 PM UTC  
 
Category: Octave FunctionSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Inaccurate Result
Status: FixedAssigned to: None
Originator Name: Philip NienhuisOpen/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)

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>
Project Administrator
Wed 13 Jul 2016 06:59:21 PM UTC, comment #18:

OK you wanted to see this:

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>
Project 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>
Project Member
Wed 13 Jul 2016 05:08:50 PM UTC, comment #16:

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>
Project 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>
Project Administrator
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):

That config.log is attached (zipped).

Then:

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

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>
Project 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):

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

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>
Project Administrator
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)

Philip Nienhuis <philipnienhuis>
Project 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>
Project Administrator
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>
Project 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>
Project Administrator
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>
Project 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>
Project Member
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>
Project Administrator
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>
Project 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>
Project Administrator
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.

This result is the same as Linux.

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

Rik <rik5>
Project 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>
Project Administrator
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>
Project Administrator
Fri 01 Jul 2016 01:27:47 PM UTC, original submission:
Philip Nienhuis <philipnienhuis>
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 #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
  • -unavailable- added by lachlan (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by rik5 (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 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
    Wed 13 Jul 2016 07:34:01 PM UTCmtmillerStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Wed 13 Jul 2016 09:41:34 AM UTCphilipnienhuisAttached File-=>Added config.zip, #37841
    Sat 09 Jul 2016 12:36:33 AM UTCmtmillerStatusNone=>Ready For Test
      Summary_run-test_suite FAILs for data-cc.tst ('NaN' mismatches)=>_run-test_suite FAILs for data.cc-tst ('NaN' mismatches)
    Sun 03 Jul 2016 04:58:37 PM UTCmtmillerAttached File-=>Added liboctave-frexp.patch, #37689

    Back to the top


    Powered by Savane 3.1-cleanup1