------- Comment #8 from joseph at codesourcery dot com 2009-08-24 16:59 ------- Subject: Re: complex folding inexact
On Mon, 24 Aug 2009, ghazi at gcc dot gnu dot org wrote: > This brings up the question that it's possible for GCC to produce a > compile-time result (via MPC) that is different from the runtime result (via > libgcc2) where both are C99 compliant standard conforming values. Which one > the user receives would depend on the context (e.g. static init) or on whether > optimizations allowed GCC to fold it at compile-time. > > Now this happens all the time for finite values, MPFR and MPC are more exact > that glibc's math library and often produce different results which are > clearly > better. However having GCC be more accurate than glibc (where the C library > is > outside out control) is different IMHO than getting two entirely different > results from two parts of GCC, i.e. compile-time folding vs libgcc2. E.g. > (Inf > NaN) vs (0 -Inf) are both infinities per C99 Annex G. There are certainly other cases where folding may produce different results from those produced at runtime. If a processor may require kernel support for subnormals or other special values we fold following IEEE rather than having options to declare the exact state of kernel support. We do not necessarily always produce a NaN with the same significand as hardware does. Out-of-range conversions from floating-point to integer (unspecified value in Annex F) do not necessarily produce consistent results between folding and runtime (or between software and hardware floating point). If we implement IBM long double constant folding (bug 26374) I expect that will produce the nearest representable value to the exact result rather than always producing the same value as at runtime which might sometimes be further away from the exact result. > Should I continue to pursue having GCC fold the Annex G special cases via MPC > if it leads to this kind of discrepancy? Or should be seek to fold these I think folding these cases via MPC is fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30789
