PING #2 On Thu, Apr 26, 2012 at 12:20 AM, Janne Blomqvist <blomqvist.ja...@gmail.com> wrote: > PING! > > On Thu, Apr 19, 2012 at 00:46, Janne Blomqvist > <blomqvist.ja...@gmail.com> wrote: >> Hi, >> >> the attached patch implements a few fixes and cleanups for the MOD and >> MODULO intrinsics. >> >> - When the arguments are constant, use mpfr_fmod instead of the naive >> algorithms which are numerically unstable for large arguments. This >> extends the PR 24518 fix to constant arguments as well, and makes the >> compile-time evaluation match the runtime implementation which also >> uses fmod in the same manner. >> >> - Remove the old fallback path for the case builtin_fmod is not >> available, as the builtin is AFAICS always available. >> >> - Specify the behavior wrt. the sign and magnitude of the result, >> mention this in the documentation. This includes signed zeros which >> now behave similar to other finite values. I.e. for MOD(A, P) the >> result has the sign of A and a magnitude less than that of P, and for >> MODULO(A, P) the result has the sign of P and a magnitude less than >> that of P. As a (minor?) caveat, at runtime this depends on the >> implementation of the fmod function in the target C library. But, a >> fmod that follows C99 Annex F implements this behavior. >> >> Regtested on x86_64-unknown-linux-gnu, Ok for trunk? >> >> 2012-04-19 Janne Blomqvist <j...@gcc.gnu.org> >> >> PR fortran/49010 >> PR fortran/24518 >> * intrinsic.texi (MOD, MODULO): Mention sign and magnitude of result. >> * simplify.c (gfc_simplify_mod): Use mpfr_fmod. >> (gfc_simplify_modulo): Likewise, use copysign to fix the result if >> zero. >> * trans-intrinsic.c (gfc_conv_intrinsic_mod): Remove fallback as >> builtin_fmod is always available. For modulo, call copysign to fix >> the result when signed zeros are enabled. >> >> >> -- >> Janne Blomqvist > > > > -- > Janne Blomqvist
-- Janne Blomqvist
