This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, fortran] PR 49010/24518 MOD/MODULO fixes
- From: Tobias Burnus <tobias dot burnus at physik dot fu-berlin dot de>
- To: Janne Blomqvist <blomqvist dot janne at gmail dot com>, gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org
- Date: Wed, 4 Apr 2012 11:11:23 +0200
- Subject: Re: [Patch, fortran] PR 49010/24518 MOD/MODULO fixes
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."
Since you modify intrinsic.texi, could you also do:
- Add a cross @ref between mod and modulo.
- 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.*
Please also update the Copyright year for simplify.c.
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.)
Tobias
* Regarding "mod" vs. "module" see also
https://en.wikipedia.org/wiki/Remainder#The_case_of_general_integers
and the right column at
https://en.wikipedia.org/wiki/Modulo_operation