[Patch, fortran] PR 49010/24518 MOD/MODULO fixes, take 2

[Janne Blomqvist-3]

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  <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
        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-3]

PING!

On Thu, Apr 19, 2012 at 00:46, Janne Blomqvist
<blomqvist.janne@...> 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  <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
>        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-3]

PING #2

On Thu, Apr 26, 2012 at 12:20 AM, Janne Blomqvist
<blomqvist.janne@...> wrote:

> PING!
>
> On Thu, Apr 19, 2012 at 00:46, Janne Blomqvist
> <blomqvist.janne@...> 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  <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
>>        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

[Mikael Morin-2]

On 02/05/2012 21:22, Janne Blomqvist wrote:

> PING #2
>
> On Thu, Apr 26, 2012 at 12:20 AM, Janne Blomqvist
> <blomqvist.janne@...> wrote:
>> PING!
>>
>> On Thu, Apr 19, 2012 at 00:46, Janne Blomqvist
>> <blomqvist.janne@...> 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  <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
>>>        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
>
>
>

Hello,

this looks good. OK with a testcase.
Thanks, and sorry for the delay.

Mikael

[Janne Blomqvist-3]

On Fri, May 4, 2012 at 6:11 PM, Mikael Morin <mikael.morin@...> wrote:

> On 02/05/2012 21:22, Janne Blomqvist wrote:
>> PING #2
>>
>> On Thu, Apr 26, 2012 at 12:20 AM, Janne Blomqvist
>> <blomqvist.janne@...> wrote:
>>> PING!
>>>
>>> On Thu, Apr 19, 2012 at 00:46, Janne Blomqvist
>>> <blomqvist.janne@...> 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  <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
>>>>        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
>>
>>
>>
>
> Hello,
>
> this looks good. OK with a testcase.

Committed as r187191. Testcases I committed attached.

> Thanks, and sorry for the delay.

Thanks for the review!

--
Janne Blomqvist

[Andreas Schwab-2]

Janne Blomqvist <blomqvist.janne@...> writes:

> - When the arguments are constant, use mpfr_fmod instead of the naive

mpfr 2.3.1 doesn't have mpfr_fmod.

Andreas.

--
Andreas Schwab, schwab@...
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Janne Blomqvist-3]

On Sat, May 5, 2012 at 2:31 PM, Andreas Schwab <schwab@...> wrote:
> Janne Blomqvist <blomqvist.janne@...> writes:
>
>> - When the arguments are constant, use mpfr_fmod instead of the naive
>
> mpfr 2.3.1 doesn't have mpfr_fmod.

I know, but since GCC requires at least mpfr 2.4.2 we're ok.

--
Janne Blomqvist

[Andreas Schwab-2]

Janne Blomqvist <blomqvist.janne@...> writes:

> On Sat, May 5, 2012 at 2:31 PM, Andreas Schwab <schwab@...> wrote:
>> Janne Blomqvist <blomqvist.janne@...> writes:
>>
>>> - When the arguments are constant, use mpfr_fmod instead of the naive
>>
>> mpfr 2.3.1 doesn't have mpfr_fmod.
>
> I know, but since GCC requires at least mpfr 2.4.2 we're ok.

No, it doesn't.

Andreas.

--
Andreas Schwab, schwab@...
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Tobias Burnus]

Andreas Schwab wrote:
> Janne Blomqvist<blomqvist.janne@...>  writes:
>> On Sat, May 5, 2012 at 2:31 PM, Andreas Schwab<schwab@...>  wrote:
>>> mpfr 2.3.1 doesn't have mpfr_fmod.
>> I know, but since GCC requires at least mpfr 2.4.2 we're ok.
> No, it doesn't.

 From 4.8's ./configure:

   # If we have GMP, check the MPFR version.
...
     #if MPFR_VERSION < MPFR_VERSION_NUM(2,3,1)
     choke me
     #endif


On the other hand, http://gcc.gnu.org/install/prerequisites.html states:

"MPFR Library version 2.4.2 (or later)"


Tobias