[Bug c/60101] New: Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[Bug c/60101] New: Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[thorstenkurth at me dot com]

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.

[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
             Status|UNCONFIRMED                 |NEW
      Known to work|                            |4.4.7
           Keywords|                            |compile-time-hog,
                   |                            |diagnostic
   Last reconfirmed|                            |2014-02-07
     Ever confirmed|0                           |1
            Summary|Long compile times when     |[4.7/4.8/4.9 Regression]
                   |mixed complex floating      |Long compile times when
                   |point datatypes are used in |mixed complex floating
                   |lengthy expressions         |point datatypes are used in
                   |                            |lengthy expressions
   Target Milestone|---                         |4.7.4
      Known to fail|                            |4.5.4, 4.6.4, 4.7.2, 4.8.2,
                   |                            |4.9.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Looks like we spend all time in c-common.c:verify_sequence_points ().  Not sure
why double.c compiles instantly.  Using the C++ frontend also makes float.c
compile instantly.

Regression from at 4.4.

[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Let me have a look.

[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
The difference I see is not that dramatic.

float.c
real    10m5.540s
user    10m0.678s
sys    0m0.172s

double.c:
real    7m54.983s
user    7m50.344s
sys    0m0.384s

[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Aha, checking=release is where the difference is evident.

[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started (expectably) with r146472 aka PR16202.

[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|mpolacek at gcc dot gnu.org        |unassigned at gcc dot gnu.org

--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Unassigning for now.

[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101

--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> passes with this change and the testcase from this PR finishes in under a
> second.  Manuel, can you please try to explain what you were trying to
> achieve in the SAVE_EXPR case and whether the reversal of copy behavior in
> merge_tlist was on purpose?

I don't remember I implemented this part (the revision that you mention is not
adding the handling of SAVE_EXPR or the reversal of copy behavior). My patch
simply extended the definition of what is considered candidates for warning (by
looking at the operands of operators). I took a look at my patch, and I don't
fully understand how it triggers the bug that you mention. Perhaps there is
some duplication between the code path that I added (since it is meant to
recurse on operands) and some special-handling that was there for SAVE_EXPR and
COND_EXPR.
>From gcc-bugs-return-443277-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Feb 11 13:14:27 2014
Return-Path: <gcc-bugs-return-443277-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6458 invoked by alias); 11 Feb 2014 13:14:27 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 6392 invoked by uid 48); 11 Feb 2014 13:14:23 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions
Date: Tue, 11 Feb 2014 13:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords: compile-time-hog, diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-60101-4-R3wdzQGbDq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60101-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60101-4@http.gcc.gnu.org/bugzilla/>
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/msg01034.txt.bz2
Content-length: 506

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`101

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernds at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, sorry, Manuel, it seems that code is older, has been added already in
http://gcc.gnu.org/ml/gcc-patches/2000-11/msg00541.html

[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 32103
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32103&action=edit
WIP patch

And just for completeness, I'm attaching my WIP (about 50% of work done) patch
to introduce the hash tables.  But, if this new testcase doesn't need it,
perhaps there is no point in hacking on that further, unless we hit it on
larger testcases.

[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101

--- Comment #11 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Sorry for not being more helpful, it was a long time ago that I worked on that.
Perhaps if you tell me which revision did the reversal/implemented the
special-handling of SAVE_EXPR, I can figure out what is going on.
>From gcc-bugs-return-443280-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Feb 11 13:29:13 2014
Return-Path: <gcc-bugs-return-443280-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19091 invoked by alias); 11 Feb 2014 13:29:13 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 19077 invoked by uid 48); 11 Feb 2014 13:29:10 -0000
From: "loximann at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/60144] New: Misleading error message when missing "then" after "if" and "else if"
Date: Tue, 11 Feb 2014 13:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: loximann at gmail 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
Message-ID: <bug-60144-4@http.gcc.gnu.org/bugzilla/>
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/msg01037.txt.bz2
Content-length: 1077

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`144

            Bug ID: 60144
           Summary: Misleading error message when missing "then" after
                    "if" and "else if"
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: loximann at gmail dot com

Compiler version:
GNU Fortran (Ubuntu 20130917-1ubuntu1) 4.9.0 20130917 (experimental) [trunk
revision 202647]

Test program:
--------------------
program ifelif
    if (.TRUE.)
    else if (.FALSE.)
    end if
end program
--------------------

Error messages:
----------------------
if.F90:2.15:

    if (.TRUE.)
               1
Error: Cannot assign to a named constant at (1)
if.F90:3.11:

    else if (.FALSE.)
           1
Error: Unexpected junk after ELSE statement at (1)
[...]
----------------------

Both errors should read something like "Missing THEN after IF/ELSE IF".

The first error message doesn't even make sense...

[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Feb 12 07:35:50 2014
New Revision: 207711

URL: http://gcc.gnu.org/viewcvs?rev=207711&root=gcc&view=rev
Log:
    PR c/60101
    * c-common.c (merge_tlist): If copy is true, call new_tlist,
    if false, add ADD itself, rather than vice versa.
    (verify_tree): For COND_EXPR, don't call merge_tlist with non-zero
    copy.  For SAVE_EXPR, only call merge_tlist once.

    * c-c++-common/pr60101.c: New test.

Added:
    trunk/gcc/testsuite/c-c++-common/pr60101.c
Modified:
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-common.c
    trunk/gcc/testsuite/ChangeLog

[Bug c/60101] [4.7/4.8 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
      Known to work|                            |4.9.0
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
            Summary|[4.7/4.8/4.9 Regression]    |[4.7/4.8 Regression] Long
                   |Long compile times when     |compile times when mixed
                   |mixed complex floating      |complex floating point
                   |point datatypes are used in |datatypes are used in
                   |lengthy expressions         |lengthy expressions
      Known to fail|4.9.0                       |

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.

[Bug c/60101] [4.7/4.8 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Thu Mar  6 08:01:57 2014
New Revision: 208368

URL: http://gcc.gnu.org/viewcvs?rev=208368&root=gcc&view=rev
Log:
    Backport from mainline
    2014-02-12  Jakub Jelinek  <jakub@redhat.com>

    PR c/60101
    * c-common.c (merge_tlist): If copy is true, call new_tlist,
    if false, add ADD itself, rather than vice versa.
    (verify_tree): For COND_EXPR, don't call merge_tlist with non-zero
    copy.  For SAVE_EXPR, only call merge_tlist once.

    * c-c++-common/pr60101.c: New test.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/pr60101.c
Modified:
    branches/gcc-4_8-branch/gcc/c-family/ChangeLog
    branches/gcc-4_8-branch/gcc/c-family/c-common.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug c/60101] [4.7 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|4.7.4                       |4.8.3
      Known to fail|                            |4.7.4

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed for 4.8.3.