On 2007-12-31 14:38:21 -0500, Kaveh R. GHAZI wrote: > I read through the bugs in 2.3.0 from the above link. I'm trying to see > if I can write a GCC testcase that exposes one of those bugs when GCC is > linked with mpfr-2.3.0, but passes when I use 2.3.1-rc1. > > The bug would need to be exposed using a mantissa size of a C type, like > 53 for double, and the default exponent range. And all the global mpfr > flags are cleared beforehand,
Are they cleared before each call to MPFR functions? > and the input precision is the same as the output precision. These > circumstances seem to eliminate many (all?) of the potential > failures. The fact that the input precision is the same as the output precision will also eliminate some bugs. > I tried several things through gcc+mpfr-2.3.0 like asin(-0.0), but > that folds to -0.0 correctly. Perhaps because the same variable is used for the input and output? > I tried a call to sqrt(2.0) with -frounding-math. But the inexact > flag is apparently set and gcc appropriately does not fold this > case, instead replying on the library call to get the rounding > correct. The ternary value was correct, and I suppose that GCC tests the ternary value instead of the global inexact flag (this is what one does in general). > Often the bug says it will fail on "huge" inputs, but doesn't say > exactly what they are. Most of the time, testcases were included in the changesets (not in 53 bits, but in general, this shouldn't matter). You may want to look at them. -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
