dmd
dmd copied to clipboard
dlang
fix Issue 22740 - float and double literals should be rounded to thei…
…r precision
As @ibuclaw pointed out, this can be forced already with core.math.toPrec, but I suspect that making enum, const, and static all produce the same value should be unsurprising.
I'm not sure why it wouldn't work. The D spec requires float and double to be IEEE, and the D compiler is compiled with a D compiler.
Thanks for your pull request, @WalterBright!
Bugzilla references
| Auto-close | Bugzilla | Severity | Description |
|---|---|---|---|
| ✓ | 22740 | enhancement | float and double literals should be rounded to their precision |
Testing this PR locally
If you don't have a local development environment setup, you can use Digger to test this PR:
dub run digger -- build "master + dmd#13613"
It appears that CTFloat cannot currently convert to float or double. I've been considering writing an 80 bit emulator, it seems this PR will have to wait for that.
I haven't been able to find online a Boost compatible 80 bit emulator.
I'm not sure why it wouldn't work. The D spec requires
floatanddoubleto be IEEE, and the D compiler is compiled with a D compiler.
But the longdouble implementation is not necessarily real, and doesn't have the ability to convert from struct to native.
There's a reason why I've been periodically changing 1.0 and 0.0 to CTFloat.one and CTFloat.zero in the frontend whenever native float has accidentally crept in from time to time.
It appears that CTFloat cannot currently convert to float or double. I've been considering writing an 80 bit emulator, it seems this PR will have to wait for that.
Ah, so it isn't just gdc that emulates a float then judging from the Win64 failures. Good to know.
I haven't been able to find online a Boost compatible 80 bit emulator.
Can't you just add a CTFloat.truncate function, rather than go the whole hog?
This looks inferior to https://github.com/dlang/dmd/pull/11387 to me - parsing the literals as real_t and then converting to float/double, instead of parsing them directly as float/double, yielding the same values a C[++] compiler would. Edit: And with a proper overflow check.
And AFAICT it doesn't address the concerns raised in my PR.
But the longdouble implementation is not necessarily real, and doesn't have the ability to convert from struct to native.
I think all real_t types should have the ability to be cast to a double/float. Like https://github.com/dlang/dmd/blob/27d052e5f011c39286d6fa7dfc11f1c6e786aa03/src/dmd/root/longdouble.d#L169-L191.
But the longdouble implementation is not necessarily real, and doesn't have the ability to convert from struct to native.
I think all
real_ttypes should have the ability to be cast to a double/float. Like https://github.com/dlang/dmd/blob/27d052e5f011c39286d6fa7dfc11f1c6e786aa03/src/dmd/root/longdouble.d#L169-L191.
That only works because the underlying layout matches native reals though. Which isn't the case for me.
That only works because the underlying layout matches native reals though. Which isn't the case for me.
So IIUC, the type you are using cannot be simply converted to a native double or float?! I know for a fact that LLVM's APFloat (arbitrary-precision float) can: https://llvm.org/doxygen/classllvm_1_1APFloat.html#a37733c4c22afc6a48194783dbd25487c
That only works because the underlying layout matches native reals though. Which isn't the case for me.
So IIUC, the type you are using cannot be simply converted to a native double or float?! I know for a fact that LLVM's
APFloat(arbitrary-precision float) can: https://llvm.org/doxygen/classllvm_1_1APFloat.html#a37733c4c22afc6a48194783dbd25487c
I see real_to_target in the headers, that writes the result to a c_long array that may or may not be punnable to native. I don't really want to find out, as it would surely be more trivial doing this on the emulated type directly.
The number of times a float or double appears in gdc is zero, so it would be good to keep it that way.