develooper Front page | perl.perl5.porters | Postings from November 2013

Re: [perl #120405] Wrong results for unpack "f"

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
November 3, 2013 13:36
Subject:
Re: [perl #120405] Wrong results for unpack "f"
Message ID:
20131103133615.GH26894@plum.flirble.org
On Tue, Oct 29, 2013 at 05:12:35PM -0400, Andy Dougherty wrote:
> On Tue, Oct 29, 2013 at 01:46:55PM -0400, Andy Dougherty wrote:
> 
> > > > Short version (copied into this bug for easier access):
> > > > -----------------------------------------------------------------------
> > > > 
> > > > $ perl -e "print unpack('f>', pack ('f>', 279.117156982422));"
> > > > 279.617156982422
> > 
> > Is this the same as [perl #86534]?  That was fixed by
> > 
> >     commit cd07c537987a76c934f141ca5bc0309e5a6b2609
> >     Author: David Mitchell <davem@iabyn.com>
> >     Date:   Mon Mar 21 14:14:52 2011 +0000
> > 
> >     pack test failures with long doubles on x86/gcc
> >         
> 
> Porting/bisect-runner tells me that on 32-bit Linux x86 with gcc -O2,
> the commit below fixed it.  Whether it fixed it or just reordered code
> so gcc doesn't make the error in [perl #86534], I don't know.
> 
> commit 3a88beaa68dbb5bad93145daa0c829e0aeb40adb
> Author: Nicholas Clark <nick@ccl4.org>
> Date:   Tue May 7 17:39:42 2013 +0200

I don't know either. I know enough to know that I don't know enough to figure
this out. But one guess (possibly wrong) - is this change forcing some value
to spill out to memory, and so no longer be in an 80 bit FP register?
(Or alternatively, to not spill and so be preserved in all its 80 bit glory)

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About