WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
> 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 <jb@...>
> 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
> * 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