On Thu, Sep 14, 2006 at 09:47:37AM +0200, Mark Wielaard wrote:
> Hi Andrew and Christian,
>
> By now you two probably know mprec.c better than others. Could you take
> a look at this patch suggestion? Might this be related to the recent
> miscompilation observed by Andrew? Do we have testcases for this
> problem?
>
> Thanks,
>
> Makr
>
> On Sun, 2006-09-10 at 10:37 -0400, Aaron M. Ucko wrote:
> > Please apply the below one-line patch to mprec.c to fix _Jv_ulp's
> > behavior on 64-bit systems, where it can otherwise improperly return
> > very large values when it should return very small ones. (Without
> > this patch, converting certain strings, such as "1e-305", to doubles
> > would go into infinite loops on x86_64-linux-gnu, and presumably other
> > 64-bit environments as well. With this patch, I see no such
> > problems.)
> >
> > Thanks!
> >
> > --- classpath/native/fdlibm/mprec.c~ 2006-09-05 09:47:02.000000000
> > -0400
> > +++ classpath/native/fdlibm/mprec.c 2006-09-05 13:15:28.000000000 -0400
> > @@ -666,7 +666,7 @@
> > _DEFUN (ulp, (_x), double _x)
> > {
> > union double_union x, a;
> > - register __Long L;
> > + register int32_t L;
> >
> > x.d = _x;
> >
> >
>
Hi!
The patch looks ok to me. Maybe it should be an uint32_t, as this is
the data type from the union. I wonder why __Long is defined as
long. There must have been a reason for that...
- twisti
