On 16 May 2016 at 14:31, Walter Bright via Digitalmars-d <digitalmars-d@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.