From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-449083-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 10970 invoked by alias); 15 Apr 2014 16:59:06 -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
Received: (qmail 10913 invoked by uid 48); 15 Apr 2014 16:59:03 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60841] [4.9/4.10 Regression] gcc: internal compiler error: Killed (program cc1) out of memory
Date: Tue, 15 Apr 2014 16:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: memory-hog
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60841-4-LzA0n4rlC3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60841-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60841-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-04/txt/msg01103.txt.bz2

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note that -fdump-tree-all dumps are pretty much the same short length, it is
just -fdump-tree-vect-details that goes to almost a gig.
And, an important thing I've noticed in there is tons of SLP node creations
where all (4 in this case) stmts of the node are the same.
There are a few where they differ like:
pr60841.i:9:3: note: Build SLP for h$f3_244 = b.30_588 < 0 ? h$f3_606 :
h$f3_250;
pr60841.i:9:3: note: Build SLP for h$f2_371 = b.30_588 < 0 ? h$f2_600 :
h$f2_377;
pr60841.i:9:3: note: Build SLP for h$f1_515 = b.30_588 < 0 ? h$f1_594 :
h$f1_561;
pr60841.i:9:3: note: Build SLP for h$f4_86 = b.30_588 < 0 ? h$f4_612 : h$f4_92;
but many more where they are all the same:
pr60841.i:9:3: note: Build SLP for b.30_588 = (int) _587;
pr60841.i:9:3: note: Build SLP for b.30_588 = (int) _587;
pr60841.i:9:3: note: Build SLP for b.30_588 = (int) _587;
pr60841.i:9:3: note: Build SLP for b.30_588 = (int) _587;

grep 'Build SLP for' pr60841.i.114t.vect | awk 'BEGIN{i=0;k=0;l=0}(i ==
0){j=$0;m=0;i++;next}(i != 0){if (j != $0){m=1};i++;if (i == 4){i=0;if
(m){l++;}else{k++;}}}END{print k, l}'
929443 14334

means (if I haven't made a mistake in the awk) that 14334 quadruplets have
differing stmts (the only case where building further SLP nodes makes sense),
while 929443 cases have the same stmts (then we just should treat it as a point
where we broadcast a scalar value into a vector if we choose to vectorize).

Richard, can you please have a look?