Mac OSX: parseNumber tests failing for out-of-bound numbers on clang

[umar456]

The following tests are failing for parseNumber using clang++ Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn).:

[  FAILED  ] AssemblyContextParseNarrowUnsignedIntegers.Sample
[  FAILED  ] AssemblyContextParseWideUnsignedIntegers.Sample
[  FAILED  ] AssemblyContextParseFloat.Sample
[  FAILED  ] AssemblyContextParseDouble.Sample

This is because clang does not fail for large numbers(i.e. 1e400) when converting text to float using istringstream.

#include <iostream>
#include <iomanip>
#include <sstream>
#include <limits>
using namespace std;

int main() {
  istringstream text_stream("1e400");
  double val = 0;

  text_stream >> std::setbase(0);
  text_stream >> val;

  cout << text_stream.fail() << endl;
  cout << "val: " << val << endl;
}

Output:

clang++ -std=c++11 foo.cpp -o clang_foo && echo clang && ./clang_foo && g++-4.8 -std=c++11 foo.cpp -o gcc_foo && echo gcc && ./gcc_foo
clang
0
val: inf
gcc
1
val: 1.79769e+308

[dneto0]

The reliance on the failure from istringstream is used to check for out-of-bounds arguments to things like OpConstant %type , where %type is a known type.
For example if %type is an unsigned 32-bit int, then the istringstream::fail() is used to see if the value is out of bounds for that type.
In short, this is behaviour we do want to rely on, so that the assembler can properly check its inputs.

This looks like a bug in the Apple C++ library.
Behaviour is as specified in http://en.cppreference.com/w/cpp/io/basic_istream/operator_gtgt
In particular "f extraction fails, zero is written to value and failbit is set. If extraction results in the value too large or too small to fit in value, std::numeric_limits::max() or std::numeric_limits::min() is written and failbit flag is set."

Well, we've already worked around a GNU libc++ bug. We seem to have an Apple one.

Thanks for reporting this.

[dneto0]

I investigated two test failures which occur on Mac OSX using Apple's Clang.

There are two failing essential cases:

1. parsing "-0" is expected to succeed with value 0 even for unsigned target types.
2. parsing a too-large floating point value in regular notation (e.g. 1.0e400) is expected to result in an error, but it does not.

[dneto0]

Fixed in master with 6bad02c