January 22, 2017
On Saturday, 21 January 2017 at 05:59:32 UTC, Stefan Koch wrote:
> On Friday, 20 January 2017 at 19:08:28 UTC, Stefan Koch wrote:
>> Druntime and phobos broke, the reason being that,
>> I did test against an outdated version of druntime/phobos.
>>
>> I am working on getting them to compile again.
>> Adding features is stalled until then.
>
> Phobos and druntime unittests pass again.
>
> this was _NOT_ a proper fix.
> only a really crude bailout when we detect that we jump to code that does not exist.

The cause seems to be fixed now.
January 23, 2017
I just fixed a bug related to the unsupported floating point.
~master phobos compiles again and runs the unit-tests.

I will probably have to spent the rest of the month with fixing bugs that function-call support has uncovered.

Since now newCTFE sees much more code before bailing out.

I have also determined the cause of most of the miscompiled code.
The cause is the incorrect treatment of utf8.
(currently the evaluator really just does (dchar c= (_c & 7f))
which leads to corrupted strings in mixins;
and that has pretty crazy effects.

It was very hard to find this.
January 23, 2017
On Monday, 23 January 2017 at 07:57:35 UTC, Stefan Koch wrote:
> It was very hard to find this.

Good job.
January 23, 2017
On Monday, 23 January 2017 at 09:06:49 UTC, Nordlöw wrote:
>
> Good job.

There are more good news

uint fn()
{
  uint x = 7;
  modx(&x);
  return x;
}

void modx(uint* x)
{
    *x = 12;
}

static assert(fn() == 12);

This code does now compile with newCTFE :)
January 23, 2017
interpret3.d passes!!!

The only remaining issues that cause miscompiled code are UTF(8/16/32) encoding and decoding issues.
January 23, 2017
On Monday, 23 January 2017 at 17:42:00 UTC, Stefan Koch wrote:
> interpret3.d passes!!!
>
> The only remaining issues that cause miscompiled code are UTF(8/16/32) encoding and decoding issues.

Wow! Getting close know!
January 23, 2017
On 1/23/17 6:42 PM, Stefan Koch wrote:
> interpret3.d passes!!!
>

Now that's something!

> The only remaining issues that cause miscompiled code are UTF(8/16/32)
> encoding and decoding issues.

---
Dmitry Olshansky
January 23, 2017
V Mon, 23 Jan 2017 17:42:00 +0000
Stefan Koch via Digitalmars-d <digitalmars-d@puremagic.com> napsáno:

> interpret3.d passes!!!
> 
> The only remaining issues that cause miscompiled code are UTF(8/16/32) encoding and decoding issues.

WOW

January 23, 2017
On Monday, 23 January 2017 at 17:42:00 UTC, Stefan Koch wrote:
> interpret3.d passes!!!
>
> The only remaining issues that cause miscompiled code are UTF(8/16/32) encoding and decoding issues.

Is that without bailing out?

 — David
January 24, 2017
On Monday, 23 January 2017 at 22:09:27 UTC, David Nadlinger wrote:
> On Monday, 23 January 2017 at 17:42:00 UTC, Stefan Koch wrote:
>> interpret3.d passes!!!
>>
>> The only remaining issues that cause miscompiled code are UTF(8/16/32) encoding and decoding issues.
>
> Is that without bailing out?
>
>  — David

No I still bail a lot :).
And I will be for some time, until I have written a memory-manager and various other runtime-libarary equivalents which are required for CTFE.

As well as my own soft-floating point library to ensure proper output during cross-compilation.

However this is an important milestone because it can now magically speed up a subset of ctfe without breaking things...
modulo bugs not covered by the unittests.