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

Small update I fixed the handling of $ in slices.
[1,2,3,4][$-2 .. $] == [3,4]
will now work in newCTFE

March 17
On Sat, Mar 18, 2017 at 03:29:15AM +0000, Stefan Koch via Digitalmars-d wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> > [ ... ]
> 
> Small update I fixed the handling of $ in slices.
> [1,2,3,4][$-2 .. $] == [3,4]
> will now work in newCTFE

Awesome!  It's great to see the new CTFE engine slowly but surely taking shape.  Really looking forward to see the final product.


T

-- 
The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- Anonymous
March 19
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

I just restored Array/Slice-Expansion.
I also introduced concat!

This will now compile with newCTFE!

static immutable uint[] OneToTen = [1,2,3,4,5,6,7,8,9,10];

const(uint[]) SliceOf1to10(uint lwr, uint upr)
{
    return OneToTen[lwr .. upr];
}

const(uint)[] testConcat()
{
    return SliceOf1to10(0,4) ~ SliceOf1to10(7,9);
}

static assert(testConcat == [1,2,3,4,8,9]);

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

Oh darn, function pointers regressed!
I did not notice because the corresponding tests were commented out.

I am working to fix it ASAP.
March 20
On Monday, 20 March 2017 at 11:48:56 UTC, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> [ ... ]
>
> Oh darn, function pointers regressed!
> I did not notice because the corresponding tests were commented out.
>
> I am working to fix it ASAP.

It's not function pointers.
It's slice extension.

It just happened that my function pointer tests relied on slice extension working.
March 20
On Monday, 20 March 2017 at 12:06:57 UTC, Stefan Koch wrote:
> On Monday, 20 March 2017 at 11:48:56 UTC, Stefan Koch wrote:
>> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>>> [ ... ]
>>
>> Oh darn, function pointers regressed!
>> I did not notice because the corresponding tests were commented out.
>>
>> I am working to fix it ASAP.
>
> It's not function pointers.
> It's slice extension.
>
> It just happened that my function pointer tests relied on slice extension working.

Actually it's just local variables of slices :)
Doged a nasty bullet there.
March 21
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

Hi I fixed the local slice issue.
It turned out that there was special code in place to deal with this case;
But that I forgot to change that to the new slice ABI.

The moral of this story is;
ABI changes are hard to do if you have an ad-hoc approach to it.
However now I made ABI-dependeant values more visible.
And it is unlikely that further slice-ABI changes will cause problems.

Cheers,
Stefan
March 22
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

I just fixed a bug in switches, where the fall-trough case would incorrectly jump after the switch.

The reason this bug occurred is that none of my tests did cover the fall-trough case.
The code that handles switches converts them into a big if-else chain because jump-tables are usually more expensive for small switches.
March 31
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

Alright guys.

I am just fixing the newCTFE LLVM backend such that I can have better guesses as to what performance a JIT could archive.

Due to the ABI changes the llvm-backend a little optimization potential.

It'll be a while until the llvm backend is on par again.
Because functions and such need to be dealt with quite differently.
Also the llvm backend recives less testing since I cannot run it at compile time(Yet :))

Cheers,
Stefan
--
sorry for the short message I am busy fixing codegen bugs as always.
March 31
On Friday, 31 March 2017 at 14:05:00 UTC, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> [ ... ]
>
> Alright guys.
>
> I am just fixing the newCTFE LLVM backend such that I can have better guesses as to what performance a JIT could archive.
>
> Due to the ABI changes the llvm-backend a little optimization potential.
>
> It'll be a while until the llvm backend is on par again.
> Because functions and such need to be dealt with quite differently.
> Also the llvm backend recives less testing since I cannot run it at compile time(Yet :))
>
> Cheers,
> Stefan
> --
> sorry for the short message I am busy fixing codegen bugs as always.

oh, yeah ... If you want to checkout the llvm backend fethc the newCTFE_LLVMBackend branch from https://github.com/UplinkCoder/dmd.

the posix.mak is hardcoded to use libLLVM-3.5.
However you should be able to use any version newer then 3.3.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17