On Wed, Mar 14, 2012 at 01:03, Janne Blomqvist
<> 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.
> The patch does not per se fix the corner-case bug as reported in PR
> 49010, in fact it makes it worse in a way as with the patch the result
> if the arguments are parameters is the same as the runtime result
> (previously, the compile-time result was correct). But, I think we
> should leave it as it is. Due to the reasons above, we're not using
> the naive algorithms anyway, and IMHO -0.0 is quite a good
> approximation for +0.0 anyway. One might even argue that due to the
> numerical instability, specifying the naive algorithms is a bug in the
> standard.
> The patch adds notes to the documentation about the usage of fmod, so
> users interested in corner-case behavior can look up how that function
> is supposed to behave on their target. FWIW, AFAICS MPFR and glibc
> fmod conform to the behavior specified in C99 Annex F.
> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
> 2012-03-14  Janne Blomqvist  <>
>        PR fortran/49010
>        PR fortran/24518
>        * intrinsic.texi (MOD,MODULO): Mention usage of fmod instead of
>        naive algorithm.
>        * simplify.c (gfc_simplify_mod): Use mpfr_fmod.
>        (gfc_simplify_modulo): Likewise.
>        * trans-intrinsic.c (gfc_conv_intrinsic_mod): Remove fallback as
>        builtin_fmod is always available.
> --
> Janne Blomqvist

Janne Blomqvist

Reply via email to