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 ClarkThread Previous | Thread Next