newCTFE Status November 2018

[Joakim]

On Monday, 10 December 2018 at 14:36:36 UTC, kinke wrote:
> 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. :)

I think they're implying he already got newCTFE working with a 
BSD-licensed softfloat-2 written in C, and he plans to rewrite 
its functionality in D and Boost-license it.

Might be a good idea for ldc to use that C softfloat-2 library 
too, since ldc's BSD-licensed anyway, as opposed to the 
LGPL-licensed MPFR.