newCTFE Status November 2018

[kinke]

On Monday, 10 December 2018 at 13:20:32 UTC, Iain Buclaw wrote:
> On Mon, 10 Dec 2018 at 14:00, Stefan Koch via Digitalmars-d
>> ctfloat depends on the C runtime, and therefore it's
>> implementation dependent.

For DMD, yes; GDC obviously doesn't use the C runtime, and LDC 
does partially (which should be fixed at some point).

>> I'd rather go with an implementation which I have verified 
>> myself.
>> And where I can give meaningful statements about what it can, 
>> and
>> can't support.
>>
>> I'd love to not re-invent the weel; But we don't have a wheel.

Again, that's the case for DMD. Considering DMD only supports x86 
targets with x87 reals and isn't really usable/used for 
cross-compilation, one could argue that using a software real_t 
for DMD is overkill, reducing CTFE speed for 
host-C-runtime-independent results (which might lead to new 
runtime/compile-time divergences).

> Then fix the wheel - you've already gone as far as taking one 
> soft-float implementation, use it for the alias to real_t!

My impression was that Stefan was about to port some 
implementation, that's why I interfered, in the hopes of 
accelerating newCTFE deployment. ;) - So if it's already 
implemented and fully in D, then perfect, I'll be more than happy 
to incorporate it as LDC's real_t. :)