This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: PR29335 use MPFR for builtins fma, fmin and fmax


Kaveh R. GHAZI wrote:
Right.  I wish MIN/MAX_EXPR were suitable for fmin/fmax replacements.
There are a lot of optimizations in the middle-end for these EXPRs that
I'd rather not duplicate in the builtins.  Instead I'd like to be able to
lower the builtins into these codes like we do for fabs->ABS_EXPR.  But
that would require work to change all the backends to honor the new
behaviors for -0.0 and/or NaN.

Actually, I'm not sure if fmin/fmax care about -0.0, but I think they do
care about NaN vs a normal number.  Anyone got the standard handy?

Which standard? If it's like the Fortran standard, the C standard probably doesn't say, which presumably leaves it up to the IEEE floating-point standard, if anything.


There was a fairly warm little debate in comp.lang.fortran (and crossposted elsewhere, IIRC) a couple of months ago about what the IEEE standard required in such cases, and whether it required anything at all. What I recall of the arguments roughly amounted to (a) The IEEE standard can be read to say that max(NaN, x) should be x, regardless of argument order (though I don't recall how clear this reading was); and (b) this behavior is stupid and disconcerting for anyone who's using propagation of NaNs to indicate when something's gone bad, and if that's what the IEEE standard says then it's wrong.

If you want to come to a specific decision on the matter, the thread may be worth digging up and reading; it wasn't at all Fortran-specific.

- Brooks


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]