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][4.3] Expand lround inline for x86_64/i?86 SSE math



On Oct 18, 2006, at 11:28, Richard Guenther wrote:
Hm, I did test +-0, 0.5, 1.0, 1.5 with +- DBL_EPSILON added,
but that's obviously something different.  Is there a way to
easily get the predecessor/successor without bit-munging the
FP representation?
In the general case, it's not that easy. See the Succ and Pred
routines in s-fatgen. The "bit-munging" is far easier if you
can assume IEEE single, double or double extended types and
have integer types with matching size: for positive definite
numbers (including +0.0) the predecessor resp. successor
of the floating-point number is the same as the predecessor
resp. successor of the integer representation. For negative
numbers, use the identities Pred (-X) == -Succ (X) and
Succ (-X) == -Pred (X). For the very general case, look
at Succ and Pred functions in ada/s-fatgen.adb.

If you can change rounding modes, you can trivially compute
the functions by specifying round to +infinity or -infinity
and adding/subtracting the smallest floating-point number.


I wonder if fortran specifies round differently, as the frontend explicitly converts NINT(x) = INT(x + ((x > 0) ? 0.5 : -0.5)).

AFAIK, this is a bug as well, unless the rounding mode is changed to round-towards-zero. For case of round-to-even and operations that are strictly IEEE-conformant, you can do replace the 0.5 constant by its predecessor (which I gave in my previous mail) and the rounding of the addition will ensure right answers in all cases. Note that extra precision (such as x86 double extended) kills this algorithm, which is the reason Gigi always converts to the widest hardware floating-point type.

Two TODO items:
  -  We should have a predicate in the compiler telling us wether
     operations on a floating-point type will always be correctly
     rounded or not
  -  Ada should be able to import GCC's builtin functions as
     intrinsics, but that has turned out to be hard, because of
     the way they (and the types they operate on) are defined.

-Geert


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