From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2618 invoked by alias); 6 Feb 2014 19:51:33 -0000 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 Received: (qmail 2583 invoked by uid 48); 6 Feb 2014 19:51:29 -0000 From: "thorstenkurth at me dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/60101] New: Long compile times when mixed complex floating point datatypes are used in lengthy expressions Date: Thu, 06 Feb 2014 19:51:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 4.8.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: thorstenkurth at me dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-02/txt/msg00652.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101 Bug ID: 60101 Summary: Long compile times when mixed complex floating point datatypes are used in lengthy expressions Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: thorstenkurth at me dot com Created attachment 32071 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32071&action=edit Archive which includes test case. In the example I copied below, the double.c file compiles instantly whereas the float.c file takes very long. This is a truncated version of an even longer file (more lines of code in the loop) and the compile time for the float.c file grows like N^3, where N is the number of lines. Here is the output of the long version for 4.8.2: 0x40ae17 do_spec_1 ../../gcc-4.8.2-src/gcc-4.8.2/gcc/gcc.c:5269 0x40ae17 do_spec_1 ../../gcc-4.8.2-src/gcc-4.8.2/gcc/gcc.c:5269 0x40c875 process_brace_body ../../gcc-4.8.2-src/gcc-4.8.2/gcc/gcc.c:5872 0x40c875 process_brace_body ../../gcc-4.8.2-src/gcc-4.8.2/gcc/gcc.c:5872 0x40c875 handle_braces ../../gcc-4.8.2-src/gcc-4.8.2/gcc/gcc.c:5786 0x40c875 handle_braces ../../gcc-4.8.2-src/gcc-4.8.2/gcc/gcc.c:5786 0x40ae17 do_spec_1 ../../gcc-4.8.2-src/gcc-4.8.2/gcc/gcc.c:5269 0x40c875 process_brace_body ../../gcc-4.8.2-src/gcc-4.8.2/gcc/gcc.c:5872 and more messages like that The attached files both compile, but they the float.c takes significantly longer. The only difference between those files is that the temporary variable sum is double complex in the working version and float complex in the non-working version. So I guess, the compiler tries to reorganize the complex multiplications and additions so that intermediate floating point results can be used (this is what I guess). Both files compile using the icc (>=11.0) and clang/LLVM almost instantly. It also works for gcc<=4.4.