newCTFE Status November 2018

[H. S. Teoh]

On Sat, Dec 08, 2018 at 05:19:59PM +0000, Joakim via Digitalmars-d wrote:
[...]
> 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.

Ahhh, so *that's* the reason for the failure.

But I'd think that's more than just a floating-point issue; wouldn't
CTFE in general be problematic if there's a mismatch between host
built-in types vs. target built-in types when cross-compiling? I suppose
D's fixed-sized types help a lot in this regard (imagine the mess if
`int` varies in size across host/target archs -- the kind of mess C/C++
have to deal with). But `real` is a fly in the ointment.

I'd imagine difference in endianness would be another cause of problems
in cross-compilation, though for the most part typical D code wouldn't
be affected by this at least as far as CTFE is concerned (since casting
/ reinterpretation of unions is not currently allowed).


> 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.

Which it should, since any code that depends on real.dig is ostensibly
expecting the target arch's precision, not the host's which may change
depending on which host you use to compile it.

Looks like we'll somehow need a way to tell the CTFE engine what the
target arch should be, and when something doesn't match the host type,
it should run a software emulation instead of using the host's `real`.


T

-- 
Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world. -- Carl B. Constantine