newCTFE Status November 2018
noone at nowhere.com
Mon Dec 10 14:36:36 UTC 2018
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
>> And where I can give meaningful statements about what it can,
>> 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
> 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. :)
More information about the Digitalmars-d