Hi all,
  MSVC's strtod does not deal correctly with hexadecimal floating point literals, resulting a few unittests failing. For example, the following program

import std.math, std.stdio;
void main() {
    writeln(PI);
}

outputs "0" (zero), simply because std.math.PI is defined using a hex literal and LDC2 compiled with MSVC cannot deal with that.
See: https://github.com/ldc-developers/ldc/issues/761

I added
#if _MSC_VER <= 1800
    VersionCondition::addPredefinedGlobalIdent("MSVC_STRTOD_NOHEXREALS");
#endif
to main.cpp, and then in std.math I defined PI and friends using decimal floating point literals for version(MSVC_STRTOD_NOHEXREALS).

Is this a desired fix? (i.e. trying to make a better build with MSVC while we wait for the new version)

One positive effect of this change is that it un-hides some other failing tests.

thanks for comments,
  Johan

On Sunday, 1 March 2015 at 21:00:53 UTC, Johan Engelen wrote:
> Hi all,
>   MSVC's strtod does not deal correctly with hexadecimal floating point literals, resulting a few unittests failing. For example, the following program
>
> import std.math, std.stdio;
> void main() {
>     writeln(PI);
> }
>
> outputs "0" (zero), simply because std.math.PI is defined using a hex literal and LDC2 compiled with MSVC cannot deal with that.
> See: https://github.com/ldc-developers/ldc/issues/761
>
> I added
> #if _MSC_VER <= 1800
>     VersionCondition::addPredefinedGlobalIdent("MSVC_STRTOD_NOHEXREALS");
> #endif
> to main.cpp, and then in std.math I defined PI and friends using decimal floating point literals for version(MSVC_STRTOD_NOHEXREALS).
>
> Is this a desired fix? (i.e. trying to make a better build with MSVC while we wait for the new version)
>
> One positive effect of this change is that it un-hides some other failing tests.
>
> thanks for comments,
>   Johan

Why use hex constants to begin with? Why not just use the floating point equivalent? The compiler will just substitute with the binary representation that is closest will it not?

On Monday, 2 March 2015 at 00:23:33 UTC, Kevin Brogan wrote:
> Why use hex constants to begin with? Why not just use the floating point equivalent? The compiler will just substitute with the binary representation that is closest will it not?

Hi Kevin,

it is a very complicated problem to create a floating point number from the usual decimal scientific representation, e.g. 3.1415. I think a good reading is http://dl.acm.org/citation.cfm?id=93557.
The hex representation is far easier to parse.

Regards,
Kai

Hi Johan!

On Sunday, 1 March 2015 at 21:00:53 UTC, Johan Engelen wrote:
> Is this a desired fix? (i.e. trying to make a better build with MSVC while we wait for the new version)

Not really. It fixes building std.math but fails with any user application.

What about implement a hex value parsing function which is invoked if the result is 0?

> One positive effect of this change is that it un-hides some other failing tests.

As a local fix, this is good.

Regards,
Kai

On Monday, 2 March 2015 at 07:17:37 UTC, Kai Nacke wrote:
> Hi Johan!
>
> On Sunday, 1 March 2015 at 21:00:53 UTC, Johan Engelen wrote:
>> Is this a desired fix? (i.e. trying to make a better build with MSVC while we wait for the new version)
>
> Not really. It fixes building std.math but fails with any user application.
>
> What about implement a hex value parsing function which is invoked if the result is 0?

dmd has a strold for compilers that do not support hex floats:
https://github.com/D-Programming-Language/dmd/blob/master/src/backend/strtold.c

Or do you think that is overkill and we are better off implementing our own hex parser?

On Monday, 2 March 2015 at 18:49:42 UTC, Johan Engelen wrote:
> On Monday, 2 March 2015 at 07:17:37 UTC, Kai Nacke wrote:
>>
>> What about implement a hex value parsing function which is invoked if the result is 0?
>
> dmd has a strold for compilers that do not support hex floats:
> https://github.com/D-Programming-Language/dmd/blob/master/src/backend/strtold.c
>
> Or do you think that is overkill and we are better off implementing our own hex parser?

Actually I am thinking about ripping out just the hex parsing part from dmd's strtold, and tweaking it for our purposes...

On Monday, 2 March 2015 at 18:51:27 UTC, Johan Engelen wrote:
> On Monday, 2 March 2015 at 18:49:42 UTC, Johan Engelen wrote:
>> On Monday, 2 March 2015 at 07:17:37 UTC, Kai Nacke wrote:
>>>
>>> What about implement a hex value parsing function which is invoked if the result is 0?
>>
>> dmd has a strold for compilers that do not support hex floats:
>> https://github.com/D-Programming-Language/dmd/blob/master/src/backend/strtold.c
>>
>> Or do you think that is overkill and we are better off implementing our own hex parser?
>
> Actually I am thinking about ripping out just the hex parsing part from dmd's strtold, and tweaking it for our purposes...

We've already had DMD's strtold() implementation. It was removed when we switched to double-precision real on Win64 and MSVCRT, see https://github.com/ldc-developers/ldc/pull/747.
For MSVCRT < 14, we'd need a standard-compliant strtod(), not strtold().

On Monday, 2 March 2015 at 21:52:10 UTC, kinke wrote:
>
> We've already had DMD's strtold() implementation. It was removed when we switched to double-precision real on Win64 and MSVCRT, see https://github.com/ldc-developers/ldc/pull/747.
> For MSVCRT < 14, we'd need a standard-compliant strtod(), not strtold().

OK, but it is relatively easy to write a hex parser on top of MSVC's strtod (for the heavy duty work). I'll see how far I get :)

I have an initial implementation working now.
Where should I put this code in the codebase? Create a new file dmd2/root/strtod_hex.c ?

thanks,
  Johan

Also, where do I add tests for this?
I could add a .d test file, where correct parsing of hex float literals are tested against binary representations.