This is the mail archive of the
`gcc-patches@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Janne Blomqvist <blomqvist dot janne at gmail dot com>*To*: Tobias Burnus <tobias dot burnus at physik dot fu-berlin dot de>*Cc*: gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org*Date*: Wed, 4 Apr 2012 14:14:34 +0300*Subject*: Re: [Patch, fortran] PR 49010/24518 MOD/MODULO fixes*References*: <20120404091123.GA17476@physik.fu-berlin.de>

On Wed, Apr 4, 2012 at 12:11, Tobias Burnus <tobias.burnus@physik.fu-berlin.de> wrote: > Janne Blomqvist wrote: >> the attached patch implements a few fixes and cleanups for the MOD and >> MODULO intrinsics. > >> 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. > >> +@item @emph{Note}: >> +The obvious algorithm as specified above is unstable for large real >> +inputs. Hence, for real inputs the result is calculated by using the >> +@code{fmod} function in the C math library. > > I wonder whether one should extend the note, stating that that using > "fmod" might lead to a `wrongly' signed 0. Something like: "; depending > on its implementation, this might lead to a diffent sign for 0 results > - compared to the result of the obvious algorithm." Yes, but if one describes the behavior for one special case, IMHO one should also specify it for other special cases. E.g. from the glibc fmod manpage: ...the returned value has the same sign as x and a magnitude less than the magnitude of y. If x or y is a NaN, a NaN is returned. If x is an infinity, a domain error occurs, and a NaN is returned. If y is zero, a domain error occurs, and a NaN is returned. If x is +0 (-0), and y is not zero, +0 (-0) is returned. For compile-time evaluation, MPFR fmod conforms to the specification for fmod in C99 Annex F, and for runtime so does glibc fmod (see above). But for other targets, runtime might be different. But I couldn't come up with a formulation that I was happy with; not that I'm happy about my text in the patch either. Suggestions welcome.. > Since you modify intrinsic.texi, could you also do: > - Add a cross @ref between mod and modulo. Ok. > - Show in the example (as comments) also the result of the mod/module > Âoperations. As many confuse mod (=remainder) and modulo, it makes > Âsense to help them by showing the result of examples.* Well, Fortran mod != C99 remainder(). So for a general remainder operation the result is "x-n*y" (evaluated with infinite precision), where n is x/y rounded to an integer in some way. Then we have at least the following cases - C fmod and Fortran MOD: n is rounded towards zero - Fortran MODULO: n is rounded towards -Infinity - C99 and IEEE754 remainder: n is rounded to the nearest integer. Incidentally, this has the nice property that abs(result) <= abs(y/2). > Please also update the Copyright year for simplify.c. Ok. > Otherwise, the patch looks OK. > > (Except for the mode change of libgcc/configure - which requires a build > maintainer approval. If you want to make it executable, do the same also > for libitm/configure - and do so in a separate patch.) Ah, that was some autogenerated stuff that was accidentally included in the patch. Please disregard it. -- Janne Blomqvist

**References**:**Re: [Patch, fortran] PR 49010/24518 MOD/MODULO fixes***From:*Tobias Burnus

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |