June 19, 2017
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

newCTFE specific tests are now included in my version of the test-suite.
No more silent breakage. (Atleast for anything covered by the test.)
For this to work I introduced a __trait which returns true if newCTFE bailed-out on something, and false otherwise.

So far it seems to work quite well.
June 20, 2017
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

limited Support for 32bit floating point ops [+, -, *, /, %] has just landed in newCTFE.

float fmadd(float a, float b, float c)
{
    return b + a * c;
}

pragma(msg, fmadd(6.7, 8.9, 1.3)/* == 17.61f*/);
pragma(msg, fmadd(6.7, 8.9, -1.3)/* == 19.00f*/);

June 20, 2017
On Tuesday, 20 June 2017 at 12:07:00 UTC, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> [ ... ]
>
> limited Support for 32bit floating point ops [+, -, *, /, %] has just landed in newCTFE.
>
> float fmadd(float a, float b, float c)
> {
>     return b + a * c;
> }
>
> pragma(msg, fmadd(6.7, 8.9, 1.3)/* == 17.61f*/);
> pragma(msg, fmadd(6.7, 8.9, -1.3)/* == 19.00f*/);
These will pass with newCTFE:
static assert(fmadd(0x1.acccccp+2, 0x1.166666p+3, 0x1.4cccccp+0) == 0x1.168f5cp+4);
static assert(fmadd(0x1.acccccp+2, 0x1.166666p+3, -0x1.4cccccp+0) == -0x1.47a8p-7);

Proving that newCTFE's floating-point-math works the same as runtime-floating-point math.
Which is not surprising since the interpreter uses same code as the runtime version.
At-least if you bootstrap dmd with itself.

June 20, 2017
On Tuesday, 20 June 2017 at 12:07:00 UTC, Stefan Koch wrote:
> limited Support for 32bit floating point ops [+, -, *, /, %] has just landed in newCTFE.

Nice!
June 20, 2017
On Tue, Jun 20, 2017 at 12:07:00PM +0000, Stefan Koch via Digitalmars-d wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> > [ ... ]
> 
> limited Support for 32bit floating point ops [+, -, *, /, %] has just landed in newCTFE.

Awesome!!!!!


> float fmadd(float a, float b, float c)
> {
>     return b + a * c;
> }
> 
> pragma(msg, fmadd(6.7, 8.9, 1.3)/* == 17.61f*/);
> pragma(msg, fmadd(6.7, 8.9, -1.3)/* == 19.00f*/);

Awesome stuff.  Can't wait to get my hands on the newCTFE engine for my math code!


T

-- 
Written on the window of a clothing store: No shirt, no shoes, no service.
June 20, 2017
On Tuesday, 20 June 2017 at 12:07:00 UTC, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> [ ... ]
>
> limited Support for 32bit floating point ops [+, -, *, /, %] has just landed in newCTFE.
>
> float fmadd(float a, float b, float c)
> {
>     return b + a * c;
> }
>
> pragma(msg, fmadd(6.7, 8.9, 1.3)/* == 17.61f*/);
> pragma(msg, fmadd(6.7, 8.9, -1.3)/* == 19.00f*/);

Cheer Guys!
64bit floating point is in!

Hit me with brittle numeric code please!
At the same time 64bit integer support was expanded.
Such that we can now return long and ulong values.

Unfortunately this also broke the phobos unitttests since now more of is attempted to be evaluated.


June 20, 2017
On Tuesday, 20 June 2017 at 17:35:28 UTC, Stefan Koch wrote:
> Hit me with brittle numeric code please!
> […]
>
> Unfortunately this also broke the phobos unitttests since now more of is attempted to be evaluated.

Just making sure that the Phobos unit tests pass at compile time (with 64 bit reals, if that is what you support) should be a good start.

 — David
June 20, 2017
On Tuesday, 20 June 2017 at 18:58:36 UTC, David Nadlinger wrote:
> On Tuesday, 20 June 2017 at 17:35:28 UTC, Stefan Koch wrote:
>> Hit me with brittle numeric code please!
>> […]
>>
>> Unfortunately this also broke the phobos unitttests since now more of is attempted to be evaluated.
>
> Just making sure that the Phobos unit tests pass at compile time (with 64 bit reals, if that is what you support) should be a good start.
>
>  — David

Fixed.
June 20, 2017
On Tuesday, 20 June 2017 at 17:35:28 UTC, Stefan Koch wrote:
> At the same time 64bit integer support was expanded.
> Such that we can now return long and ulong values.
>
> Unfortunately this also broke the phobos unitttests since now more of is attempted to be evaluated.

The reason this broke was because we do not handle default arguments in calls correctly.
I have added a bailout such that we will not try to call functions with default arguments.

with that we should pass phobos uinttests again.
June 20, 2017
On Tuesday, 20 June 2017 at 19:01:06 UTC, Stefan Koch wrote:
> On Tuesday, 20 June 2017 at 18:58:36 UTC, David Nadlinger wrote:
>> On Tuesday, 20 June 2017 at 17:35:28 UTC, Stefan Koch wrote:
>>> Hit me with brittle numeric code please!
>>> […]
>>>
>>> Unfortunately this also broke the phobos unitttests since now more of is attempted to be evaluated.
>>
>> Just making sure that the Phobos unit tests pass at compile time (with 64 bit reals, if that is what you support) should be a good start.
>>
>>  — David
>
> Fixed.

But how much of the std.math code are you actually executing with newCTFE? What I meant is that if the std.math{,special} implementations of the various mathematical functions work, there shouldn't be any egregious issues. I'm not sure how much of it is usually run during CTFE, though.

 — David