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] |

*From*: Geert Bosch <bosch at adacore dot com>*To*: Richard Guenther <rguenther at suse dot de>*Cc*: gcc-patches at gcc dot gnu dot org*Date*: Wed, 18 Oct 2006 11:57:37 -0400*Subject*: Re: [PATCH][4.3] Expand lround inline for x86_64/i?86 SSE math*References*: <Pine.LNX.4.64.0610181606580.8942@zhemvz.fhfr.qr> <EEA92755-FDBD-4FF8-AAAB-ACBB9461A6F7@adacore.com> <Pine.LNX.4.64.0610181714060.8942@zhemvz.fhfr.qr>

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.

**Follow-Ups**:**Re: [PATCH][4.3] Expand lround inline for x86_64/i?86 SSE math***From:*Andrew Haley

**References**:**[PATCH][4.3] Expand lround inline for x86_64/i?86 SSE math***From:*Richard Guenther

**Re: [PATCH][4.3] Expand lround inline for x86_64/i?86 SSE math***From:*Geert Bosch

**Re: [PATCH][4.3] Expand lround inline for x86_64/i?86 SSE math***From:*Richard Guenther

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |