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] fix pr 29302


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



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