On Tue, May 04, 2010 at 05:29:03PM +0200, Florian Weimer wrote: > * Niko Tyni: > > > The benefits are obviously improved numeric range and precision. The > > downside is presumably increased memory usage. I have no measurement > > data on this; suggestions on suitable tests would be welcome. > > I have run into several incompatibilities between i386 and amd64 due > to different Perl integer sizes, so I'm definitely in favor of 64-bit > integers. > > I'm not sure if long doubles are a win. The rest of the world runs on > 64 bit floating point numbers, so this would introduce additional > incompatibilities.
I wasn't initially going for long doubles, but several upstream developers recommended that they be enabled together. http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2010-04/msg00773.html http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2010-04/msg00895.html Given that we've already run into a dozen or so incompatibilities with just the CPAN modules, -Duselongdouble seems to be a pretty rare thing to do. I'm inclined to revert this setting. On Wed, May 05, 2010 at 01:50:30PM +1000, Brendan O'Dea wrote: > On 4 May 2010 22:54, Niko Tyni <nt...@debian.org> wrote: > > It would be possible to choose these settings separately for each > > architecture. > > Should I exclude the 'smaller' architectures (armel, mips*?) > > You could ask debian-...@lists.debian.org and the other ports lists, > but it seems reasonable to include 64bit support only on those > architectures where there is native 64 bit support in the chipset. Good point. Can anybody list our "pure" 32-bit architectures off-hand or suggest a simple test? Checking the instruction set for each one is a bit on the laborous side... Ideally, I'd like to have a concrete plan to send to the ports lists and just ask for any objections. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100508102808.ga9...@madeleine.local.invalid
