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
mod2.diff
Description: Binary data
