According to this and (for me) this, that should either not happen; or at least be controllable.

But then, that may not have been the case for which compiler the code was originally (or subsequently) targeted at; so it's a good thought. Thank you.

I took a look through some of the source code you linked, and the type cast seems to be applied in particular when there's a subtraction that's obviously close to zero. I don't have enough C++ experience to know how the compilers are expected to behave on such things (even more so older versions), but I walked through a bunch of the arithmetic and there's a lot of adding and subtracting things that should either add up to zero or add up neatly to just one of the terms that was in a previous step, so I'm actually a little surprised that there aren't more oddball things in there (or at least a note about setting a compiler directive not to simplify) to keep the epsilons from getting optimized away.

There are enough things that just cancel away in odd ways that I was partly looking to verify you hadn't made any typos!

EDIT: in your first link it actually points out that the Intel C++ compiler does allow associativity transformations by default, so it may be a bit of legacy code to prevent that.

in your first link it actually points out that the Intel C++ compiler does allow associativity transformations by default, so it may be a bit of legacy code to prevent that.

It seems that both gcc and icc also have options specifically aimed at the problem:

Gnu compilers default to observing parentheses in accordance with language standards. Traditional C K&R behavior of permitting elision of parentheses according to algebraic rules is included in gcc –ffast-math and icc –fp-model fast.

Gfortran sets –fprotect-parens as a default even under –ffast-math, so that no normally used options will violate parentheses: http://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html

Apparently this was default for gcc only for the version which first introduced the option, and the option was later withdrawn, so gcc (and icc) don’t allow for using parentheses to control associativity under normally aggressive optimizations.

Ifort has the option –assume protect_parens for this purpose. With the addition of ,minus0 clause this may be enough for Fortran 95 standard compliance.

In order to set observance of parentheses (gcc –fprotect-parens) in icc without disabling other aggressive optimizations, the combination –fp-model source –ftz –fast-transcendentals –no-prec-div –no-prec-sqrt may be set. This may be a frequently needed setting for Intel® Xeon Phi™. For Intel® Xeon host, of these options, only –fast-transcendentals has a consistently large effect on performance.

Among well-known algorithms which will break when the compiler elides parentheses is Kahan summation. Consistent elimination of parentheses could reduce Kahan summation to a standard lower accuracy vectorizable sum. Inconsistent K&R treatment (or inconsistent extra precision) produces incorrect (not simply lower accuracy) results.

Intel compilers don’t recognize common sub-expressions unless they are parenthesized, and an option is set to observe the parentheses, e.g.

         a1 *= ((d1 *(e1 + f1)+ e1 * f1) + c1 *((e1 + f1) + d1))
             + b1 *(((e1 + f1) + d1) + c1);
         b1 *= (d1 *(e1 + f1)+ e1 * f1) + c1 *((e1 + f1) + d1);
[download]

while other compilers don’t need the extra parentheses as long as the common subexpressions match during left to right evaluation. In this code fragment, there are 5 repeated add instructions which may be eliminated, although the Intel compilers will replace some by equally time-consuming copy (move) instructions. The difference in performance may be quite large when fused multiply-add instructions are used.

Additional named assignments for local sub-expressions are undesirable, particularly in parallelized code, as they increase register pressure and invite the compiler not to perform register optimization.

But when these things came to be isn't clear. That said; the Kahan summation algorithm goes back to 1989; and compiler writers have been aware of it for a long time.

Of course; that says nothing about the various programmers who've had their hands on this code since.

All of which leaves me with a possibility; but none the wiser :(

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!