newCTFE Status November 2018

[Joakim]

On Saturday, 8 December 2018 at 07:08:54 UTC, Stefan Koch wrote:
> On Saturday, 8 December 2018 at 04:06:11 UTC, Joakim wrote:
>> On Saturday, 8 December 2018 at 00:32:58 UTC, Stefan Koch 
>> wrote:
>>> Hi All,
>>>
>>> I have short but good news, non-default class-constructors 
>>> work now.
>>> (this was tricky because of my unorthodox vtbl layout).
>>>
>>> And another exciting news item, newCTFE is going to support 
>>> cross-platform floating-point as soon as I got around to 
>>> re-implementing, the qemu fork of softfloat-2.
>>
>> What do you mean by "cross-platform floating-point," using the 
>> same implementation everywhere without calling _any_ libc/arch 
>> intrinsics?
>
> Yes that is what I mean. It has always been the plan, but until 
> recently,
> I saw no way to actually realize it.
>
>>> That'll result in a compile-time testable floating point 
>>> implementation ;) Pretty cool, huh.
>>
>> How does that differ from the current implementation?
>
> Currently it relies on the host fpu.  or rather the hosts float 
> implementation.
> Which I intent to replace with a pure software solution, which 
> operates independently
> from the host float math.
> And can therefore be made to behave like the targets (more or 
> less, it's emulation).

OK, got that from the first question, but I was referring to what 
you called "compile-time testable?" I didn't understand what 
using a fully soft-float implementation added in that regard.

>> Btw, do you know some way to get the current compile-time 
>> real's precision in D code?
>
> this _may_ work:
> static immutable ctRealPerc = () { return real.mant_dig; } ();

No, as kinke says, it doesn't work with ldc.

On Saturday, 8 December 2018 at 15:42:43 UTC, H. S. Teoh wrote:
> On Sat, Dec 08, 2018 at 04:06:11AM +0000, Joakim via 
> Digitalmars-d wrote: [...]
>> Btw, do you know some way to get the current compile-time 
>> real's precision in D code? It would be useful to avoid static 
>> asserts from overflowing when the runtime real's precision 
>> exceeds the compile-time real's precision, which doesn't 
>> happen with dmd but can with ldc:
>> 
>> https://github.com/dlang/phobos/pull/6790#discussion_r238633160
>
> Doesn't real.dig give the (approximate) precision of real? Or 
> is that
> hard-coded in the frontend?

Just so we're clear, the issue is what the precision of reals are 
when running CTFE code to initialize a constant, as opposed to 
the precision of the real at runtime. For dmd, this doesn't 
really matter since it only supports x86/x64 chips, but ldc uses 
the host's real at compile-time, which can obviously vary from 
the target. That's why I mentioned to you in another thread that 
some stdlib math tests assert when cross-compiling from x64 to 
Android/AArch64, because of that mismatch in host->target 
precision for reals.

real.dig has the same problem as real.mant_dig above, it only 
gives the target's precision. Compiling this snippet with ldc, 
`void main() { pragma(msg, "precision is ", real.dig);}`, I get 
18 when compiling natively on linux/x64, but 33 when 
cross-compiling to Android/AArch64, ie it always gives the target 
real's precision.