On Sunday, 6 February 2022 at 13:29:23 UTC, Ola Fosheim Grøstad wrote:

For log(0.1L) at CTFE, the compiler must when targeting a platform with x87 real.

From https://dlang.org/spec/float.html#fp_const_folding:

On Sunday, 6 February 2022 at 13:36:37 UTC, kinke wrote:

It says "or greater precision", so you can use a higher precision library. Which is what you would want when building lookup-tables.

But in general, it would be better to have real be a compile time type only and instead have ieee32, ieee64, ieee80, ieee128 etc.

On Sunday, 6 February 2022 at 13:42:16 UTC, Ola Fosheim Grøstad wrote:

GDC does this. LDC could use an 128-bit emulation to fix e.g. cross-compilation from x86 to non-Apple AArch64 (but LLVM has such functionality already). And yeah, according to the spec, a 128-bit emulation should suffice for targeting x86 too, but CTFE results might slightly diverge from a native x86-DMD then.

I strongly disagree. real is the cross-platform solution for 'max hardware precision' or 'C long double', and most code should probably use float/double.

On Sunday, 6 February 2022 at 13:47:37 UTC, kinke wrote:

And when would you use this?

D has alias, so you all you need is a feature that allows you to query what is compiled to hardware instructions and what is compiled to software, then bind it.

This what actual production code does in C/C++ too. If you are flexible about precision you typically bind it to an alias. E.g. in signal processing you might bind "sample_t" to a known fixed floating point type in your configuration header.

On Sunday, 6 February 2022 at 14:22:05 UTC, Ola Fosheim Grøstad wrote:

I'm not sure we're talking about the same thing. This has nothing to do with adding software-emulated D floating-point types, but solving a cross-compilation issue for the compiler itself in case target real != host real. User code with such demands should probably use a well-established library - but that's not probably not really an acceptable solution for the DMD frontend itself.

On Sunday, 6 February 2022 at 14:38:21 UTC, kinke wrote:

Ah, ok. So it is only for cross compilation. Then it makes sense.