From 2301368574681716628 X-Google-Thread: f78e5,eb811809d4f61b12 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!news.glorb.com!news.tele.dk!feed118.news.tele.dk!news.tele.dk!small.news.tele.dk!lnewsinpeer00.lnd.ops.eu.uu.net!emea.uu.net!peer-uk.news.demon.net!kibo.news.demon.net!mutlu.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: jm@bourguet.org (Jean-Marc Bourguet) Newsgroups: comp.std.c++ Subject: Re: Using extended precision in floating point Date: Thu, 18 May 2006 15:19:30 GMT Lines: 52 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <1147882581.972497.100340@u72g2000cwu.googlegroups.com> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: news.demon.co.uk 1147965578 8210 158.152.254.254 (18 May 2006 15:19:38 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 18 May 2006 15:19:38 +0000 (UTC) X-Original-To: std-c++@mailman.ucar.edu X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Original-Trace: 18 May 2006 01:19:38 -0800, cdssoph29.cadence.com X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Original-NNTP-Posting-Host: cdssoph29.cadence.com X-Received: By mx-sanjose.cadence.com as k4I8Jiw5001260 at Thu May 18 01:19:45 2006 X-Path: comp-std-cpp-robomod!not-for-mail X-Delivered-To: std-c++@ucar.edu X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsgroups: comp.std.c++ Xref: g2news2.google.com comp.std.c++:2051 "kanze" writes: > I'd always been pretty sure of this, but on analysing some code > which wasn't giving the expected results (they were too accurate > for the algorithm being used !), I found that g++ (on a PC) used > extended precision through out the loop, at least when > optimization was requested. Is this an error in g++, or have I > misunderstood something? > > (For those who are familiar with Intel assembler, the body of > the loop is simply: > > .L9: > fadd DWORD PTR [%ecx+%eax*4] > inc %eax > cmp %eax, %edx > jb .L9 > > .) I think this is a bug is gcc. But see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 There are something like 70 duplicates. One comment is in the bug log is: Steven> ...to end this pointless discussion. Steven> Steven> Some people call this a bug in the x87 series. Other call it a bug in Steven> gcc. See these mails at least for the reason why this could be considered Steven> a bug in gcc: Steven> http://gcc.gnu.org/ml/gcc/2003-08/msg01195.html Steven> http://gcc.gnu.org/ml/gcc/2003-08/msg01234.html Steven> http://gcc.gnu.org/ml/gcc/2003-08/msg01257.html Steven> Steven> Regardless of where one wishes to put the blame, this problem will _not_ be Steven> fixed. Period. Steven> Yours, -- Jean-Marc --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]