Always false float comparisons

Manu via Digitalmars-d digitalmars-d at puremagic.com
Sun May 15 22:24:59 PDT 2016


On 16 May 2016 at 14:31, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 5/15/2016 9:05 PM, Manu via Digitalmars-d wrote:
>>
>> I've never read the C++ standard, but I have more experience with a
>> wide range of real-world compilers than most, and it is rarely very
>> violated.
>
>
> It has on every C/C++ compiler for x86 machines that used the x87, which was
> true until SIMD, and is still true for x86 CPUs that don't target SIMD.

It has what? Reinterpreted your constant-folding to execute in 80bits
internally for years? Again, if that's true, I expect that's only true
in the context that the compiler also takes care to maintain the IEEE
conformant bit pattern, or at very least, it works because the
opportunity for FP constant folding in C++ is almost non-existent
compared to CTFE, such that it's never resulted in a problem case in
my experience.
In D, we will (do) use CTFE for table generation all the time (this
has never been done in C++). If those tables were generated with
entirely different precision than the runtime functions, that's just
begging for trouble.

>> The times it is, we've known about it, and it has made us
>> all very, very angry.
>
>
> The C/C++ standard is written that way for a reason.
>
> I'd like to hear what terrible problem is caused by having more accurate
> values.

In the majority of my anecdotes, if they don't match, there are
cracks/seams in the world. That is a show-stopping bug. We have had
many late nights, even product launch delays due to by these problems.
They have been a nightmare to solve in the past.
Obviously the solution in this case is a relatively simple
work-around; don't use CTFE (ie, lean on the LLVM runtime codegen
instead to do the right thing with the float precision), but that's a
tragic solution to a problem that should never happen in the first
place.


More information about the Digitalmars-d mailing list