On Saturday, 17 December 2016 at 09:39:02 UTC, Stefan Koch wrote:
> On Saturday, 17 December 2016 at 08:53:07 UTC, Stefan Koch wrote:
>> Miscompiling phobos code is down to 4 functions.
>> std.range.primitives.{front, empty, back}
>> and std.traits.defaultParameters.
>> Note, StructLiterals are still regressed.
>> I am looking into it.
>
> Fixed the regression.
> It was an off-by-one error in the check of the member-count.
> causing the last field of a struct to be considered not part of the struct :p

Many of the forced bailouts could be removed.
Soon newCTFE will compile Phobos without any blacklisted functions!

On Monday, 19 December 2016 at 08:26:00 UTC, Stefan Koch wrote:
> On Saturday, 17 December 2016 at 09:39:02 UTC, Stefan Koch wrote:
>> On Saturday, 17 December 2016 at 08:53:07 UTC, Stefan Koch wrote:
>>> Miscompiling phobos code is down to 4 functions.
>>> std.range.primitives.{front, empty, back}
>>> and std.traits.defaultParameters.
>>> Note, StructLiterals are still regressed.
>>> I am looking into it.
>>
>> Fixed the regression.
>> It was an off-by-one error in the check of the member-count.
>> causing the last field of a struct to be considered not part of the struct :p
>
> Many of the forced bailouts could be removed.
> Soon newCTFE will compile Phobos without any blacklisted functions!

Excellent! Keep up the great work!

On Monday, 19 December 2016 at 08:26:00 UTC, Stefan Koch wrote:
> Soon newCTFE will compile Phobos without any blacklisted functions!

Awesome!

On Monday, 19 December 2016 at 08:26:00 UTC, Stefan Koch wrote:
> Soon newCTFE will compile Phobos without any blacklisted functions!

Which functions are still blacklisted?

On Monday, 19 December 2016 at 10:11:18 UTC, Nordlöw wrote:
> On Monday, 19 December 2016 at 08:26:00 UTC, Stefan Koch wrote:
>> Soon newCTFE will compile Phobos without any blacklisted functions!
>
> Which functions are still blacklisted?

Check here
https://github.com/UplinkCoder/dmd/blob/newCTFE/src/ctfe_bc.d#L120
currently it's still the range primitives and __lambda2 because of ParameterTypeTuple stuff.

Hey Guys I wanted to give a quick update.


I recently fixed an interesting bug that happened de-referencing null pointers to the heap.
That would cause arrays to be overwritten, when passed as arguments.
That bug had me stuck for a few hours.

Getting Function-Calls right will be impossible,
if the ABI issues remain.

Currently it's about the handling of pointers.
My architecture forbids pointers to the stack, therefore every time you take the address of something it needs to be pushed onto the heap.
And then the heap-value and the stack-value needs to be kept in sync with each other.
This is rather complicated, so it will take a while to get right.
At this point it might take another month until function calls are working.

--
On a different note.
Thanks for your continued moral support.
It is nice to know that my work is eagerly awaited by people.
As always I am sorry for the long time it takes.
I hope that my reports give a little insight into what issues I am facing, and why it is taking so long.

On Tuesday, 20 December 2016 at 16:53:21 UTC, Stefan Koch wrote:
> At this point it might take another month until function calls are working.

I admire your endurance.

On Tuesday, 20 December 2016 at 16:53:21 UTC, Stefan Koch wrote:
> On a different note.
> Thanks for your continued moral support.
> It is nice to know that my work is eagerly awaited by people.
> As always I am sorry for the long time it takes.
> I hope that my reports give a little insight into what issues I am facing, and why it is taking so long.

I find it all very interesting. Keep up the good work.

On Tuesday, 20 December 2016 at 16:53:21 UTC, Stefan Koch wrote:
> I hope that my reports give a little insight into what issues I am facing, and why it is taking so long.

There's a left parenthesis too much on line 3320 in ctfe_bc.d ;)

On Tuesday, 20 December 2016 at 20:30:43 UTC, Nordlöw wrote:
> On Tuesday, 20 December 2016 at 16:53:21 UTC, Stefan Koch wrote:
>> I hope that my reports give a little insight into what issues I am facing, and why it is taking so long.
>
> There's a left parenthesis too much on line 3320 in ctfe_bc.d ;)

You're right.
I was sleepy when committing that, so I forgot to check if it compiles.

It had flags to allow stack pointers for integers to make slice handling cheaper in the interpreter, but it turns out that this decision hurt performance overall, and now I am removing it.
This unmatched paren was part of the i32Ptr check :)