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*: roger at eyesopen dot com*To*: "Eric Christopher" <echristo at apple dot com>*Cc*: gcc-patches at gcc dot gnu dot org*Date*: Sun, 17 Dec 2006 19:33:28 -0700 (MST)*Subject*: Re: [patch] fix pr 29302*References*: <Pine.LNX.4.44.0612151544490.8913-100000@www.eyesopen.com> <32F1656C-CD35-4462-8F1B-44F6813B18F0@apple.com>

Hi Eric, >> I appreciate that the actual code is cut'n'paste from c-cppbuiltin.c, >> but have you considered recoding the algorithm to avoid the use of >> real_from_string? It makes sense to construct this floating point > > I have, and I'm up for a good way to do that since we basically just > want to throw the correct value in there and I was hoping to avoid > testing for 32/64/128 bitness when coming up with the value. Basically > we'd want to round the value to the nearest valid double. Sorry for the delay. I tried reproducing this failure on powerpc-apple-darwin7.9.0 but without success. Sorry if I'm being a bit slow but is the IBM extended long double MacOS version specific? However, investigating futher, I think the real.c fix should be something like: Index: real.c =================================================================== *** real.c (revision 119967) --- real.c (working copy) *************** real_maxval (REAL_VALUE_TYPE *r, int sig *** 2282,2287 **** --- 2282,2296 ---- np2 = SIGNIFICAND_BITS - fmt->p * fmt->log2_b; memset (r->sig, -1, SIGSZ * sizeof (unsigned long)); clear_significand_below (r, np2); + + if (fmt->pnan < fmt->p) + /* This is an IBM extended double format made up of two IEEE + doubles. The value of the long double is the sum of the + values of the two parts. The most significant part is + required to be the value of the long double rounded to the + nearest double. Rounding means we need a slightly smaller + value for LDBL_MAX. */ + clear_significand_bit (r, SIGNIFICAND_BITS - fmt->pnan); } } My understanding of the ASCII string that you construct is exactly the same bit pattern as we'd generate by real_maxval and then the line: >> buf[4 + fmt->pnan / 4] = "7bde"[fmt->pnan % 4]; Is used to reset the single fmt->pnan bit (expressed in nibbles). In real.c this can be done via clear_significant_bit, but with the proviso that real.c numbers bits relative to SIGNIFICAND_BITS. I believe the patch above should fix the problem, modulo the remote possibility of an off by one error. Sorry that I'm unable to reproduce this failure and therefore confirm that the implementation above works correctly, but hopefully this should be enough help to let you get the rest of the way. Let me know if this helps. Roger --

**Follow-Ups**:**Re: [patch] fix pr 29302***From:*Mike Stump

**Re: [patch] fix pr 29302***From:*Eric Christopher

**References**:**Re: [patch] fix pr 29302***From:*Roger Sayle

**Re: [patch] fix pr 29302***From:*Eric Christopher

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

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