Re: inlining + optimization = nuisance bugs

> [Oh, humph. If you think that floating point operations don't have a
> correct answer, then you definitely shouldn't be using floating point.
> Unfortunately, too many compiler writers seem to share this
> misconception. As we've said many times before, approximate is not the
> same as unpredictable. -John]


Hmm, perhaps you're thinking of something else when writing "correct answer",
but I - as one of the people responsible for reviewing bug reports for g77 -
too often come across the following:


            FUNCTION FINDX(X)
    10 XNEW = < some computation involving X >
            IF (XNEW .EQ. X) THEN
                  FINDX = XNEW
                  RETURN
            ENDIF
            X = XNEW
            GOTO 10
            END


I.e. a relaxation type computation that assumes that < some computation
involving X > has a fixed point.


This almost invariably breaks down on Intel processors, because in the
equality comparison, XNEW normally resides in a register (being recently
computed) and X is retrieved from memory.


Of course, the compiler _could_ remedy this by slowing down the whole
computation such that every floating point intermediate was stored in memory
(just singling out XNEW is too hard), but the real problem (pun intended)
with this code is much more scary:


There is no guarantee that < some computation involving X >, even if the
mathematical expression _has_ a fixed point, won't result in X and XNEW
eternally oscillating between two numbers that differ by a bit.


*I* do not know how to prove that this doesn't happen for arbitrary values of
the seed (the initial value of X) and an arbitrary < some computation
involving X >.
--
Toon Moene (mailto:toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: mailto:fortran@gnu.org; egcs: mailto:egcs-bugs@cygnus.com
[Again, there are correct answers here, but they can wobble back and
forth around the limit if the limit isn't representable, so the
X = XNEW test is just plain wrong. But you probably learned that back in
your numerical analysis class. -John]




--

Return to the comp.compilers page.
Search the comp.compilers archives again.