[Bug c/60841] New: gcc: internal compiler error: Killed (program cc1) in gcc 4.9.0 RC 2014-04-11

[Bug c/60841] New: gcc: internal compiler error: Killed (program cc1) in gcc 4.9.0 RC 2014-04-11

[mike at vermeulen dot com]

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

            Bug ID: 60841
           Summary: gcc: internal compiler error: Killed (program cc1) in
                    gcc 4.9.0 RC 2014-04-11
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mike at vermeulen dot com

Created attachment 32596
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32596&action=edit
preprocessed source file that demonstrates the problem

When compiling with "gcc -Ofast" the compiler runs for a long time and
eventually dies with following internal compiler error.

When compiling with "gcc -O3" the compilation succeeds and is also much
quicker.

gcc: internal compiler error: Killed (program cc1)
0x409fd4 execute
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:2848
0x40a384 do_spec_1
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:4652
0x40cc46 process_brace_body
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5935
0x40cc46 handle_braces
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5849
0x40b1f9 do_spec_1
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5306
0x40cc46 process_brace_body
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5935
0x40cc46 handle_braces
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5849
0x40b1f9 do_spec_1
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5306
0x40af63 do_spec_1
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5421
0x40cc46 process_brace_body
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5935
0x40cc46 handle_braces
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5849
0x40b1f9 do_spec_1
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5306
0x40cc46 process_brace_body
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5935
0x40cc46 handle_braces
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5849
0x40b1f9 do_spec_1
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5306
0x40cc46 process_brace_body
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5935
0x40cc46 handle_braces
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5849
0x40b1f9 do_spec_1
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5306
0x40cc46 process_brace_body
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5935
0x40cc46 handle_braces
    /root/source/gcc-4.9.0-RC-20140411/gcc/gcc.c:5849
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug c/60841] gcc: internal compiler error: Killed (program cc1) in gcc 4.9.0 RC 2014-04-11

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

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

--- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Changes are you ran out of memory. Look at your dmesg for the OOM killer.

[Bug c/60841] gcc: internal compiler error: Killed (program cc1) in gcc 4.9.0 RC 2014-04-11

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |memory-hog
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-04-14
      Known to work|                            |4.7.3, 4.8.3
     Ever confirmed|0                           |1
      Known to fail|                            |4.10.0, 4.9.0
           Severity|critical                    |normal

--- Comment #2 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Confirmed.

[Bug c/60841] [4.9/4.10 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[mike at vermeulen dot com]

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

--- Comment #3 from Mike Vermeulen <mike at vermeulen dot com> ---
dmesg does confirm it was killed by OOM.

Relevant entries:

[27546]     0 27546    27116        1   4       0             0 bash
[27578]     0 27578    26084        7  13       0             0 gcc
[27579]     0 27579 31860193 30405249  18       0             0 cc1


Out of memory: Kill process 27579 (cc1) score 877 or sacrifice child
Killed process 27579, UID 0, (cc1) total-vm:127440772kB, anon-rss:121620876kB,
file-rss:120kB

[Bug c/60841] [4.9/4.10 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

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

--- Comment #4 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Looking at the backtrace I think the changes to vect_analyze_slp_instance 
in gcc/tree-vect-slp.c from April last year are to blame.

[Bug tree-optimization/60841] [4.9/4.10 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
          Component|c                           |tree-optimization
   Target Milestone|---                         |4.9.0

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started actually with r204538.  I'll have a look tomorrow.

[Bug tree-optimization/60841] [4.9/4.10 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
With --param vect-max-version-for-alias-checks=100000 -Ofast it started with
r200968.

[Bug tree-optimization/60841] [4.9/4.10 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For reduced testcase, I'm now at cca 8KB, but creduce is progressing slowly.

[Bug tree-optimization/60841] [4.9/4.10 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[trippels at gcc dot gnu.org]

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

--- Comment #8 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> For reduced testcase, I'm now at cca 8KB, but creduce is progressing slowly.

Yes. I've tried this for a while yesterday, but gave up.
("ulimit -v 1000000" was likely the wrong criterion.)

[Bug tree-optimization/60841] [4.9/4.10 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 32603
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32603&action=edit
pr60841.c

Somewhat reduced testcase.
With 4.8 as well as r200967 according to -Ofast -ftime-report needs about 5MB
total, with r200968 as well as latest trunk it needs over 620MB.

[Bug tree-optimization/60841] [4.9/4.10 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[jakub at gcc dot gnu.org]

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?

[Bug tree-optimization/60841] [4.9/4.10 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine.

[Bug tree-optimization/60841] [4.9/4.10 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, so this loop contains an incredibly connected value-graph (connecting the
loads to the stores) and stupidly (yeah, well...) the vectorizer SLP code
builds a tree (yes, by effectively duplicating 'shared' nodes).

AFAIK that itself isn't a regression.  What may be a regression is that
we compute SLP now before other analysis (dependence analysis for example)
would reject the loop as not vectorizable.  So you can certainly build
a testcase that should show similar behavior with 4.8 or 4.7.

Note that the vectorization transform doesn't yet support SLP rooting
of a build-from-scalars vector, so your obvious idea to fix this is
a general missed optimization (also for scalar code vectorization - as
soon as the SLP build fails we can make it succeed by building a starting
vector from N (different) scalars).  It also doesn't really work with
SLP within loop vectorization I think.

4.8 fails to vectorize with

t.i:9: note: === vect_analyze_data_ref_accesses ===
t.i:9: note: Detected interleaving of size 4
t.i:9: note: interleaving size is greater than step for p_240->f3
t.i:9: note: not vectorized: complicated access pattern.
t.i:9: note: bad data access.

but 4.9 and trunk are happy with them.

Example testcase, vectorized with the same graph vs. tree issue with
-fvect-cost-model=unlimited:

int a[1024];
int b[1024];
void foo()
{
  int i;
  for (i = 0; i < 1024/4; i+=4)
    {
      int a0 = a[i+0];
      int a1 = a[i+1];
      int a2 = a[i+2];
      int a3 = a[i+3];
      a0 = a0 * 3;
      a1 = a1 * 3;
      a2 = a2 * 3;
      a3 = a3 * 3;
      int a0p = a0 + 1;
      int a1p = a1 + 1;
      int a2p = a2 + 1;
      int a3p = a3 + 1;
      b[i+0] = a0p + a0;
      b[i+1] = a1p + a1;
      b[i+2] = a2p + a2;
      b[i+3] = a3p + a3;
    }
}

> grep 'vectorizing SLP node' t.c.114t.vect 
t.c:6:3: note: ------>vectorizing SLP node starting from: a0_4 = a[i_30];
t.c:6:3: note: ------>vectorizing SLP node starting from: a0_11 = a0_4 * 3;
t.c:6:3: note: ------>vectorizing SLP node starting from: a0p_15 = a0_11 + 1;
t.c:6:3: note: ------>vectorizing SLP node starting from: a0_4 = a[i_30];
t.c:6:3: note: ------>vectorizing SLP node starting from: a0_11 = a0_4 * 3;
t.c:6:3: note: ------>vectorizing SLP node starting from: _19 = a0p_15 + a0_11;
t.c:6:3: note: ------>vectorizing SLP node starting from: b[i_30] = _19;

thus we have duplicate nodes for the SLP load and the SLP mult by 3.  This
issue grows the SLP tree exponentially.  In theory each reference may
correspond to a different SLP permutation (but we don't support that in
the code-gen yet).  Note we also emit duplicate vectorized code from
such SLP trees (but usually we reject it via cost analysis).  The above
happens at least since GCC 4.7.

I'm not sure if we should completely disregard multi-uses for this reason
(will check if there are testcases that expect vectorization), but
definitely that would fix the issue.

Index: gcc/tree-vect-slp.c
===================================================================
--- gcc/tree-vect-slp.c (revision 209423)
+++ gcc/tree-vect-slp.c (working copy)
@@ -911,6 +911,37 @@ vect_build_slp_tree (loop_vec_info loop_
       if (oprnd_info->first_dt != vect_internal_def)
         continue;

+      /* Check if we have multiple uses on stmts not participating in
+        this SLP node.  */
+      unsigned j;
+      gimple def_stmt, use_stmt;
+      imm_use_iterator iter;
+      FOR_EACH_VEC_ELT (oprnd_info->def_stmts, j, def_stmt)
+       {
+         tree def;
+         if (gimple_code (def_stmt) == GIMPLE_PHI)
+           def = gimple_phi_result (def_stmt);
+         else
+           def = single_ssa_tree_operand (def_stmt, SSA_OP_DEF);
+         FOR_EACH_IMM_USE_STMT (use_stmt, iter, def)
+           {
+             unsigned k;
+             gimple sstmt;
+             FOR_EACH_VEC_ELT (SLP_TREE_SCALAR_STMTS (*node), k, sstmt)
+                 if (use_stmt == sstmt)
+                   break;
+             if (k == SLP_TREE_SCALAR_STMTS (*node).length ())
+               {
+                 if (dump_enabled_p ())
+                   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+                                    "Build SLP failed: multiple uses\n");
+                 end_imm_use_stmt_traverse (&iter);
+                 vect_free_oprnd_info (oprnds_info);
+                 return false;
+               }
+           }
+       }
+

this retains multiple uses in the same SLP node which is supported.
Unfortunately the check is quadratic in the SLP group size (but that's
limited to the size of a vector register ...).  We could, if we ensure
like PLF_2 is always clear on stmts, mark the scalar stmts that way
and aovid the inner loop, of course.

The above patch for example disables SLP vectorization of slp-12a.c
(and other vect testcases) because there is a non-SLP use of b6 with the
store to ia[i].

So checking this at this point doesn't seem to work.

We can impose an artificial limit on the SLP size.  But that's not a real
fix either.

We can mark stmts "consumed" when building the SLP tree and check that.

Index: gcc/tree-vect-stmts.c
===================================================================
--- gcc/tree-vect-stmts.c       (revision 209423)
+++ gcc/tree-vect-stmts.c       (working copy)
@@ -7388,6 +7388,8 @@ new_stmt_vec_info (gimple stmt, loop_vec
   GROUP_GAP (res) = 0;
   GROUP_SAME_DR_STMT (res) = NULL;

+  gimple_set_plf (stmt, GF_PLF_1, false);
+
   return res;
 }

Index: gcc/tree-vect-slp.c
===================================================================
--- gcc/tree-vect-slp.c (revision 209423)
+++ gcc/tree-vect-slp.c (working copy)
@@ -85,6 +85,8 @@ vect_free_slp_tree (slp_tree node)
   FOR_EACH_VEC_ELT (SLP_TREE_CHILDREN (node), i, child)
     vect_free_slp_tree (child);

+  gimple_set_plf (SLP_TREE_SCALAR_STMTS (node)[0], GF_PLF_1, false);
+
   SLP_TREE_CHILDREN (node).release ();
   SLP_TREE_SCALAR_STMTS (node).release ();
   SLP_TREE_VEC_STMTS (node).release ();
@@ -862,6 +864,14 @@ vect_build_slp_tree (loop_vec_info loop_
   matches[0] = false;

   stmt = SLP_TREE_SCALAR_STMTS (*node)[0];
+  if (gimple_plf (stmt, GF_PLF_1))
+    {
+      if (dump_enabled_p ())
+       dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+                        "Build SLP failed: multiple uses\n");
+      return false;
+    }
+
   if (is_gimple_call (stmt))
     nops = gimple_call_num_args (stmt);
   else if (is_gimple_assign (stmt))
@@ -977,6 +1020,8 @@ vect_build_slp_tree (loop_vec_info loop_
       return false;
     }

+  gimple_set_plf (stmt, GF_PLF_1, true);
+
   vect_free_oprnd_info (oprnds_info);
   return true;
 }

That still fails slp-18.c which exactly has such a duplicate use (with
very non-optimal initial vectorized codegen).  Similar bb-slp-20.c
and bb-slp-21.c.  So we could add an artificial "number of allowed
duplications" counter ... (but that couldn't use the flag approach
anymore as we'd falsely clear it on duplicate uses).

[Bug tree-optimization/60841] [4.9/4.10 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 32615
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32615&action=edit
patch

Patch limiting the SLP tree size (to the number of stmts in the loop/bb, not
allowing the exponential growth we see here).

[Bug tree-optimization/60841] [4.9/4.10 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Thu Apr 17 08:09:02 2014
New Revision: 209467

URL: http://gcc.gnu.org/viewcvs?rev=209467&root=gcc&view=rev
Log:
2014-04-17   Richard Biener  <rguenther@suse.de>

    PR tree-optimization/60841
    * tree-vect-data-refs.c (vect_analyze_data_refs): Count stmts.
    * tree-vect-loop.c (vect_analyze_loop_2): Pass down number
    of stmts to SLP build.
    * tree-vect-slp.c (vect_slp_analyze_bb_1): Likewise.
    (vect_analyze_slp): Likewise.
    (vect_analyze_slp_instance): Likewise.
    (vect_build_slp_tree): Limit overall SLP tree growth.
    * tree-vectorizer.h (vect_analyze_data_refs,
    vect_analyze_slp): Adjust prototypes.

    * gcc.dg/vect/pr60841.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/vect/pr60841.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-vect-data-refs.c
    trunk/gcc/tree-vect-loop.c
    trunk/gcc/tree-vect-slp.c
    trunk/gcc/tree-vectorizer.h

[Bug tree-optimization/60841] [4.9 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.10.0
            Summary|[4.9/4.10 Regression] gcc:  |[4.9 Regression] gcc:
                   |internal compiler error:    |internal compiler error:
                   |Killed (program cc1) out of |Killed (program cc1) out of
                   |memory                      |memory
      Known to fail|4.10.0                      |

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.

[Bug tree-optimization/60841] [4.9 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.0                       |4.9.1

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.0 has been released

[Bug tree-optimization/60841] [4.9 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

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

[Bug tree-optimization/60841] [4.9 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Tue Apr 22 13:29:32 2014
New Revision: 209631

URL: http://gcc.gnu.org/viewcvs?rev=209631&root=gcc&view=rev
Log:
2014-04-22   Richard Biener  <rguenther@suse.de>

    Backport from mainline
    2014-04-17   Richard Biener  <rguenther@suse.de>

    PR tree-optimization/60841
    * tree-vect-data-refs.c (vect_analyze_data_refs): Count stmts.
    * tree-vect-loop.c (vect_analyze_loop_2): Pass down number
    of stmts to SLP build.
    * tree-vect-slp.c (vect_slp_analyze_bb_1): Likewise.
    (vect_analyze_slp): Likewise.
    (vect_analyze_slp_instance): Likewise.
    (vect_build_slp_tree): Limit overall SLP tree growth.
    * tree-vectorizer.h (vect_analyze_data_refs,
    vect_analyze_slp): Adjust prototypes.

    * gcc.dg/vect/pr60841.c: New testcase.

Added:
    branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr60841.c
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_9-branch/gcc/tree-vect-data-refs.c
    branches/gcc-4_9-branch/gcc/tree-vect-loop.c
    branches/gcc-4_9-branch/gcc/tree-vect-slp.c
    branches/gcc-4_9-branch/gcc/tree-vectorizer.h