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