From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12514 invoked by alias); 8 Dec 2009 23:58:22 -0000 Received: (qmail 12488 invoked by uid 48); 8 Dec 2009 23:58:10 -0000 Date: Tue, 08 Dec 2009 23:58:00 -0000 Message-ID: <20091208235810.12487.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug other/42333] complex division failure on darwin10 with -lm In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "ghazi at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-12/txt/msg00908.txt.bz2 ------- Comment #13 from ghazi at gcc dot gnu dot org 2009-12-08 23:58 ------- (In reply to comment #12) > .. seems likely that there are two things here: 1. we seem to be generating > (probably) less efficient code than older versions of the compiler ... and 2. > possibly the ___divdc3 in /usr/lib/libSystem is faulty? There are more than one way of generating a complex divide. One way is faster, but it's naive (lazy) and leads to errors and overflow. A second way is correct in more cases, but a little slower. FSF GCC defaults to choosing correctness over speed, unless the user asks for extra speed with a special flag. There are flags in FSF GCC for example that allow one to use the "lazy" complex divide algorithms, but the default is correctness. It appears that the Apple GCC has chosen to have their ___divdc3 routine follow the lazy algoritm in the name of speed. This must have been a concious choice on their part. Therefore filing a bug report against it is likely to get a response of "works as intended." You can try filing a bug report at Apple, but I think a better route would be to see if we can avoid linking in the system ___divdc3 from FSF GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333