bugGNU Octave - Bugs: bug #47413, string to numeric parsing problems...

 
 

bug #47413: string to numeric parsing problems with LLVM libc++ (LLVM upstream bug)

Submitter:  Mike Miller <mtmiller>
Submitted:  Tue 15 Mar 2016 02:19:26 AM UTC
   
 
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Wont Fix Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 05 May 2016 06:12:27 PM UTC, comment #12: 

Yes, it was only left open because the bug hasn't been fixed in llvm's libc++ yet, but you're right we don't have to leave bugs open to track external bugs. It might be nice to have a way to track them somewhere, so periodically we can see if they've been addressed yet.

Mike Miller <mtmiller>
Group Member
Thu 05 May 2016 08:01:35 AM UTC, comment #11: 

This has been "won't fix" for over a month.

Is it open to avoid others reporting the same bug?  I'm (tentatively) closing it.

Lachlan Andrew <lachlan>
Tue 15 Mar 2016 05:25:26 PM UTC, comment #10: 

Good demo. That turns out to be this open bug report against LLVM: https://llvm.org/bugs/show_bug.cgi?id=17782

My understanding of the standard is that Octave is doing the right thing and LLVM is not.

Mike Miller <mtmiller>
Group Member
Tue 15 Mar 2016 02:02:47 PM UTC, comment #9: 

The following program seems to be enough to demonstrate the problem. I think it should write "val: 1, failbit: 0" but it writes "val: 0, failbit: 4" when using clang++ 3.7 and libc++.

If you put a space between the '1' and the 'a' in the stringstream, it works. But I think it should stop reading the double value after the 1 either way. Am I wrong? If the clang+libc++ behavior is standard conforming, we probably have a lot of work to do to fix the way Octave reads numbers, so I hope I'm not wrong...


#include <iostream>
#include <sstream>

int
main (void)
{
std::istringstream s1 ("1asdf");
double val = 0.0;
is >> val;
std::cerr << "val: " << val
<< ", failbit: " << (is.rdstate () & std::ios::failbit)
<< std::endl;
return 0;
}


John W. Eaton <jwe>
Group administrator
Tue 15 Mar 2016 02:02:02 PM UTC, comment #8: 

The following program seems to be enough to demonstrate the problem.  I think it should write "val: 1, failbit: 0" but it writes "val: 0, failbit: 4" when using clang++ 3.7 and libc++.

If you put a space between the '1' and the 'a' in the stringstream, it works.  But I think it should stop reading the double value after the 1 either way.  Am I wrong?  If the clang+libc++ behavior is standard conforming, we probably have a lot of work to do to fix the way Octave reads numbers, so I hope I'm not wrong...

+verbatim-
#include <iostream>
#include <sstream>

int
main (void)
{
  std::istringstream s1 ("1asdf");
  double val = 0.0;
  is >> val;
  std::cerr << "val: " << val
            << ", failbit: " << (is.rdstate () & std::ios::failbit)
            << std::endl;
  return 0;
}
-verbatim-

John W. Eaton <jwe>
Group administrator
Tue 15 Mar 2016 01:30:07 PM UTC, comment #7: 

I see the same results:


octave:1> sscanf("1asdf", "%f", 1)
ans = [](0x1)
octave:2> str2double("1i")
ans = NaN
octave:3> strread("1i", "%f")
ans = NaN


John W. Eaton <jwe>
Group administrator
Tue 15 Mar 2016 04:43:04 AM UTC, comment #6: 

Seems to be better now.  I'll see if I can duplicate the problems tomorrow.

John W. Eaton <jwe>
Group administrator
Tue 15 Mar 2016 04:38:32 AM UTC, comment #5: 

Oops, I might have been out of date with libc++.  I updated it and now I'm trying again.

John W. Eaton <jwe>
Group administrator
Tue 15 Mar 2016 04:33:53 AM UTC, comment #4: 

That looks like an error that was fixed in a previous version of libc++. Do you have libc++ 3.5? See bug #43298. I have libc++ 3.7 from Debian unstable installed and I don't have any build errors. I don't think Debian gives you the option of having more than one libc++ installed at the same time.

Mike Miller <mtmiller>
Group Member
Tue 15 Mar 2016 04:22:08 AM UTC, comment #3: 

On my Debian system, I used:


/home/jwe/src/octave/configure --prefix=/usr/local/octave/dev-clang --with-hdf5-includedir=/usr/include/hdf5/serial --with-hdf5-libdir=/usr/lib/x86_64-linux-gnu/hdf5/serial CC="clang-3.7" CXX="clang++-3.7 -stdlib=libc++" CFLAGS="-O0 -g" CXXFLAGS="-O0 -g" FFLAGS="-O0 -g"


and I'm seeing a build error that begins with


In file included from /home/jwe/src/octave/libinterp/operators/op-i64-i64.cc:27:
In file included from liboctave/operators/mx-i64nda-i8.h:5:
In file included from /home/jwe/src/octave/liboctave/array/int64NDArray.h:28:
In file included from /home/jwe/src/octave/liboctave/array/intNDArray.h:28:
In file included from /home/jwe/src/octave/liboctave/array/MArray.h:29:
In file included from /home/jwe/src/octave/liboctave/array/Array.h:34:
In file included from /usr/include/c++/v1/algorithm:625:
/usr/include/c++/v1/type_traits:1195:21: error: call to '__test' is ambiguous
   typedef decltype(__test(declval<_Tp>())) type;
                    ^~~~~~
/usr/include/c++/v1/type_traits:1208:18: note: in instantiation of template class 'std::__1::__numeric_type<octave_int<long> >' requested here
          bool = __numeric_type<_A1>::value &&
                 ^
/usr/include/c++/v1/cmath:959:14: note: in instantiation of default argument for '__promote<octave_int<long>, octave_int<long>, void>' required here
    typename __promote<_A1, _A2>::type
             ^~~~~~~~~~~~~~~~~~~
[...]


John W. Eaton <jwe>
Group administrator
Tue 15 Mar 2016 03:56:20 AM UTC, comment #2: 

With GCC's libstdc++:


../configure CC=clang-3.7 CXX=clang++-3.7


With LLVM's libc++:


../configure CC=clang-3.7 CXX="clang++-3.7 -stdlib=libc++"


The former does not show these errors, and the only difference is which STL headers and runtime library are used, so it's probably something in LLVM's implementation of the STL, maybe the iostream classes?

Mike Miller <mtmiller>
Group Member
Tue 15 Mar 2016 03:50:27 AM UTC, comment #1: 

What configure command line did you use to build with clang and libc++?

John W. Eaton <jwe>
Group administrator
Tue 15 Mar 2016 02:19:26 AM UTC, original submission:  

Building Octave with clang 3.7 and libc++ 3.7 results in some strange string to numeric conversion errors. There may be a single point of failure or a class of functions failing here, but I haven't tracked it down yet. Here are some examples of failures with clang's libc++ version 3.7:


>> sscanf("1asdf", "%f", 1)
ans = [](0x1)
>> str2double("1i")
ans = NaN
>> strread("1i", "%f")
ans = NaN


Mike Miller <mtmiller>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

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 bpabbott (cc myself since MacOS requires LLVM/clang)
  • -email is unavailable- added by jwe (Posted a comment)
  •  

    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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-21 mtmiller Carbon-CopyRemoved 80942 -
    2019-01-21 mtmiller Summarystring to numeric parsing problems with llvm libc++ string to numeric parsing problems with LLVM libc++ (LLVM upstream bug)
    2016-05-05 lachlan Open/ClosedOpen Closed
    2016-03-27 bpabbott Carbon-Copy- Added -email is unavailable-
    2016-03-15 mtmiller StatusNeed Info Wont Fix

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code