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
