http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49010
--- Comment #8 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-05-17 14:02:07
UTC ---
So does the fallback path actually ever get used? AFAICS the builtins are
always available, and if the builtin results in a call to fmod{f,,l,Q} we have
fallback implementations in c99_functions.c for non-C99 functions. See PR
29810.
A problem with a naive implementation of the algorithm specified by the
standard is that it doesn't work for large arguments, which was what prompted
the usage of builtin_fmod in the first place. See PR 24518.
Taken together, it seems the proper approach would be to just remove the
fallback path (not really related to this PR per se, just as a general
janitorial patch), and fix the result if it's negative zero. E.g. something
like the following pseudocode for MOD(a,p):
if (!options.fast_math && fabs(p) == 0.0)
generate_error(...) // TBH, aborting the program here seems quite drastic..
[1]
res = __builtin_fmod (a, p)
if (options.signed_zeros)
{
if (res == -0.0)
res = 0.0
}
[1] While ISO C leaves it implementation-defined what happens here, POSIX
specifies that "If y is zero, a domain error shall occur, and either a NaN (if
supported), or an implementation-defined value shall be returned.". Similarly,
MS fmod returns NaN (according to MSDN, I haven't tested). So while not
strictly conforming to the Fortran spec, the POSIX/MS approach seems more
sensible, and is IMHO a better choice than aborting the program.
