[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign

["sgk at troutmask dot apl.washington.edu" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49010

--- Comment #10 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-05-17 14:50:52 UTC ---
On Tue, May 17, 2011 at 02:17:22PM +0000, jb at gcc dot gnu.org wrote:
>
> 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.
> 

I don't know all the targets on which gfortran can run.  Of course,
if all target have the builtin, then the fallback code won't be used.
We can garbage collect the code if you're confident that it is unneeded.

> 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

The restriction that "P shall not be zero" is on the user
not the compiler, and the compiler is not required to 
diagnosis that problem.  I think we can simply issue a
warning and let the builtin set res = NaN. 

> res = __builtin_fmod (a, p)
> if (options.signed_zeros)
> {
>   if (res == -0.0)
>     res = 0.0
> }

I don't have n1256.pdf handy (draft of C standard), but
IIRC, this check is expensive because zero and negative zero
compare equal.  One needs to explicitly check the sign
bit or simply do

   if (res == 0.0) res = abs(res)

to clear the sign.