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
