On Tue, 1 Jan 2008, Vincent Lefevre wrote:
> On 2007-12-31 14:38:21 -0500, Kaveh R. GHAZI wrote:
> > 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?
Yes I call mpfr_clear_flags() before each mpfr function call. Also, the
individual mpfr types are initialized and destroyed for each call, no
reuse occurs between different mpfr calls. However...
> > 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?
Yes, reuse occurs for src and dest variable:
mpfr_clear_flags ();
inexact = func (m, m, GMP_RNDN);
So I guess I got lucky here. :-)
> > 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).
Right, as seen above. Later on, I do check the global overflow and
underflow flags, but not global inexact.
> > 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.
I'll poke around some more and see if I can find something.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
