From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1122 invoked by alias); 17 Feb 2005 02:47:59 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 1089 invoked by uid 48); 17 Feb 2005 02:47:55 -0000 Date: Thu, 17 Feb 2005 13:27:00 -0000 Message-ID: <20050217024755.1088.qmail@sourceware.org> From: "rth at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050215161817.19974.Thomas.Koenig@online.de> References: <20050215161817.19974.Thomas.Koenig@online.de> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug target/19974] incorrect complex division on ia-64 with flag_complex_method = 2 X-Bugzilla-Reason: CC X-SW-Source: 2005-02/txt/msg01895.txt.bz2 List-Id: ------- Additional Comments From rth at gcc dot gnu dot org 2005-02-17 02:47 ------- The "problem" is the use of the fused multiply-and-add instructions. 1672 y = (b - (a * ratio)) / denom; d6: 70 70 24 0c 54 00 fms.s.s0 f7=f9,f6,f14 This computes the intermediate results of the entire numerator with 82 bits of precision. One can argue that this is inappropriate, since it's not what the source wrote. HOWEVER, if I rewrite __divsc3 to explicitly use "long double" to compute intermediate results -- which as far as I can see should be legitimate -- I also get 18059 for the imaginary part of the result. As best I can figure, that result is more mathematically correct than 0. -- What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974