On 5/15/2016 10:24 PM, Manu via Digitalmars-d wrote:
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.
Check out my other message to you quoting the VC++ manual. It does constant
folding at higher precision. So does gcc:
http://stackoverflow.com/questions/7295861/enabling-strict-floating-point-mode-in-gcc
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.
You can generate the tables at runtime at program startup by using a 'static
this()' constructor.
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.
You're always going to have tragic problems if you expect FP to behave like
conventional mathematics. Just look at all the switches VC++ has that influence
FP behavior. Do you really understand all that?
Tell me you understand all the gcc floating point switches?
https://gcc.gnu.org/wiki/FloatingPointMath
How about g++ getting different results based on optimization switches?
http://stackoverflow.com/questions/7517588/different-floating-point-result-with-optimization-enabled-compiler-bug
-------
Or, you could design the code so that there aren't cracks because it is more
tolerant of slight differences, i.e. look for so many mantissa bits matching
instead of all of them matching. This can be done by subtracting the operands
and looking at the magnitude of the difference.
The fact that you have had "many late nights" and were not using D means that
the compiler switches you were using were not adequate or were not doing what
you thought they were doing.
