Thomas Lockhart wrote:
> > I noticed the other day that the geometry output differs with the
> > compiler optimization level. That can't be good.
>
> It depends where the differences are. If they are just in the last few
> decimal places, then it should be OK (though annoying for regression
> test support).
>
> With higher optimizations, they may be doing more inlining and using
> different code sequences for, for example, the transcendental functions.
Dunno which flags you used, but with the right flags you get faster
versions of the built-in library routines -- I know that for sine/cosine
etc this makes a significant difference in runtime for a very small loss in
accuracy. And aggressive reordering of instructions can mean that different
parts of the calculation are executed in different order (if I recall
correctly EV6/7s have 8 fp/int pipes) so that small differences in
end-results are to be expected. But then, the last few digits are garbage
in most numerical calculations anyway, so no great harm done there.
The right way to solve this would be to be able to control the number of
digits that are printed, so that it is easier to check that the significant
digits are the same. That would probably get rid of quite a few
architecture specific files regression test files as well.
Adriaan
