[Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[Bug tree-optimization/59519] New: ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[su at cs dot ucdavis.edu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 9716 bytes --]

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

            Bug ID: 59519
           Summary: ICE on valid code at -O3 on x86_64-linux-gnu in
                    slpeel_update_phi_nodes_for_guard1, at
                    tree-vect-loop-manip.c:486
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: su at cs dot ucdavis.edu

The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes. 

It is a regression from 4.8.x. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++,lto --enable-checking=release --disable-werror
--enable-multilib
Thread model: posix
gcc version 4.9.0 20131215 (experimental) [trunk revision 206004] (GCC) 
$ 
$ gcc-trunk -O2 -c small.c
$ gcc-4.8 -O3 -c small.c
$ 
$ gcc-trunk -O3 -c small.c
small.c: In function ‘foo’:
small.c:9:1: internal compiler error: in slpeel_update_phi_nodes_for_guard1, at
tree-vect-loop-manip.c:486
 foo ()
 ^
0xa01706 slpeel_update_phi_nodes_for_guard1
    ../../gcc-trunk/gcc/tree-vect-loop-manip.c:486
0xa01706 slpeel_tree_peel_loop_to_edge
    ../../gcc-trunk/gcc/tree-vect-loop-manip.c:1411
0xa02281 vect_do_peeling_for_alignment(_loop_vec_info*, tree_node*, unsigned
int, bool)
    ../../gcc-trunk/gcc/tree-vect-loop-manip.c:2009
0x9f624f vect_transform_loop(_loop_vec_info*)
    ../../gcc-trunk/gcc/tree-vect-loop.c:5797
0xa0dacf vectorize_loops()
    ../../gcc-trunk/gcc/tree-vectorizer.c:473
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.
$ 


---------------------------------


struct
{
  int f0;
} d;

int a[8] = {0}, b, c, e;

void
foo ()
{
  for (; e < 1; e++)
    for (b = 0; b < 7; b++)
      {
    c |= (a[b+1] != 0);
    if (d.f0)
      break;
      }
}
>From gcc-bugs-return-437678-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 16 02:23:05 2013
Return-Path: <gcc-bugs-return-437678-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30404 invoked by alias); 16 Dec 2013 02:23:04 -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 30379 invoked by uid 48); 16 Dec 2013 02:23:00 -0000
From: "su at cs dot ucdavis.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/59520] New: a possible inconsistency in error diagnostics with "-pedantic -stdÉ9"
Date: Mon, 16 Dec 2013 02:23: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.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: su at cs dot ucdavis.edu
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-59520-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg01333.txt.bz2
Content-length: 2119

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

            Bug ID: 59520
           Summary: a possible inconsistency in error diagnostics with
                    "-pedantic -std=c99"
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: su at cs dot ucdavis.edu

I wonder whether or not the following examples illustrate an unintended
inconsistency with error diagnostics in GCC. 

In particular, should the diagnostic message be a warning for error3.c rather
than an error as shown below?  

error3.c:1:5: error: zero or negative size array ‘a’
 int a[] = {}; 
     ^

---------------

$ gcc-trunk -pedantic -std=c99 -c error1.c
error1.c:1:12: warning: ISO C forbids empty initializer braces [-Wpedantic]
 int a[1] = {};
            ^
$ clang-trunk -pedantic -std=c99 -c error1.c
error1.c:1:12: warning: use of GNU empty initializer extension
[-Wgnu-empty-initializer]
int a[1] = {};
           ^
1 warning generated.
$ cat error1.c
int a[1] = {};
$ 

---------------

$ gcc-trunk -pedantic -std=c99 -c error2.c
error2.c:1:5: warning: array ‘a’ assumed to have one element [enabled by
default]
 int a[];
     ^
$ clang-trunk -pedantic -std=c99 -c error2.c
error2.c:1:5: warning: tentative array definition assumed to have one element
int a[];
    ^
1 warning generated.
$ cat error2.c
int a[];
$ 

---------------

$ gcc-trunk -pedantic -std=c99 -c error3.c
error3.c:1:11: warning: ISO C forbids empty initializer braces [-Wpedantic]
 int a[] = {}; 
           ^
error3.c:1:5: error: zero or negative size array ‘a’
 int a[] = {}; 
     ^
$ clang-trunk -pedantic -std=c99 -c error3.c
error3.c:1:11: warning: use of GNU empty initializer extension
[-Wgnu-empty-initializer]
int a[] = {}; 
          ^
error3.c:1:11: warning: zero size arrays are an extension [-Wzero-length-array]
2 warnings generated.
$ cat error3.c
int a[] = {}; 
$
>From gcc-bugs-return-437679-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 16 02:27:33 2013
Return-Path: <gcc-bugs-return-437679-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32292 invoked by alias); 16 Dec 2013 02:27:33 -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 32273 invoked by uid 48); 16 Dec 2013 02:27:29 -0000
From: "drepper.fsp at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/59521] New: __builtin_expect not effective in switch
Date: Mon, 16 Dec 2013 02:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: drepper.fsp 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-59521-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: 2013-12/txt/msg01334.txt.bz2
Content-length: 1857

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY521

            Bug ID: 59521
           Summary: __builtin_expect not effective in switch
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: drepper.fsp at gmail dot com

When used in switch, __builtin_expect should reorder the comparisons
appropriately.  Take this code:

#include <stdio.h>
void
f(int ch) {
  switch (__builtin_expect(ch, 333)) {
    case 3: puts("a"); break;
    case 42: puts("e"); break;
    case 333: puts("i"); break;
    }
}

Current mainline (and also prior versions, I tested 4.8.2) produce with -O3
code like this:

0000000000000000 <f>:
   0:    83 ff 2a                 cmp    $0x2a,%edi
   3:    74 33                    je     38 <f+0x38>
   5:    81 ff 4d 01 00 00        cmp    $0x14d,%edi
   b:    74 1b                    je     28 <f+0x28>
   d:    83 ff 03                 cmp    $0x3,%edi
  10:    74 06                    je     18 <f+0x18>
  12:    c3                       retq
  13:    0f 1f 44 00 00           nopl   0x0(%rax,%rax,1)
  18:    bf 00 00 00 00           mov    $0x0,%edi
  1d:    e9 00 00 00 00           jmpq   22 <f+0x22>
  22:    66 0f 1f 44 00 00        nopw   0x0(%rax,%rax,1)
  28:    bf 00 00 00 00           mov    $0x0,%edi
  2d:    e9 00 00 00 00           jmpq   32 <f+0x32>
  32:    66 0f 1f 44 00 00        nopw   0x0(%rax,%rax,1)
  38:    bf 00 00 00 00           mov    $0x0,%edi
  3d:    e9 00 00 00 00           jmpq   42 <f+0x42>

Instead the test for 333/$0x14d should have been moved to the front.

[Bug tree-optimization/59519] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[su at cs dot ucdavis.edu]

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

--- Comment #1 from Zhendong Su <su at cs dot ucdavis.edu> ---
Below is simpler testcase that triggers the same ICE: 

------------------------------------

int a, b, c, d;

void
foo ()
{
  for (; d; d++)
    for (b = 0; b < 14; b++)
      {
    c |= 1;
    if (a)
      break;
      }
}

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[mpolacek at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-12-17
                 CC|                            |mpolacek at gcc dot gnu.org
   Target Milestone|---                         |4.9.0
            Summary|ICE on valid code at -O3 on |[4.9 Regression] ICE on
                   |x86_64-linux-gnu in         |valid code at -O3 on
                   |slpeel_update_phi_nodes_for |x86_64-linux-gnu in
                   |_guard1, at                 |slpeel_update_phi_nodes_for
                   |tree-vect-loop-manip.c:486  |_guard1, at
                   |                            |tree-vect-loop-manip.c:486
     Ever confirmed|0                           |1

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r205959.

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[amker.cheng at gmail dot com]

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

bin.cheng <amker.cheng at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amker.cheng at gmail dot com

--- Comment #3 from bin.cheng <amker.cheng at gmail dot com> ---
I will look into it.

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[amker.cheng at gmail dot com]

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

--- Comment #4 from bin.cheng <amker.cheng at gmail dot com> ---
First clue.

b_lsm.11_13 is recognized as chrec {1, +, 1}_2 with the patch, thus the loop
can be vectorized now.

  <bb 5>:

  <bb 6>:
  # b.4_30 = PHI <b.4_12(5), 1(12)>
  # prephitmp_28 = PHI <c.1_9(5), c.1_21(12)>
  # b_lsm.11_13 = PHI <b.4_12(5), 1(12)>
  # ivtmp_46 = PHI <ivtmp_45(5), 13(12)>
  c.1_9 = prephitmp_28 | 1;
  b.4_12 = b.4_30 + 1;
  ivtmp_45 = ivtmp_46 - 1;
  if (ivtmp_45 != 0)
    goto <bb 5>;
  else
    goto <bb 7>;

Problem arises in calling stack like:
vect_do_peeling_for_loop_bound
  slpeel_tree_peel_loop_to_edge
    slpeel_update_phi_nodes_for_guard1
for phi node : # b_lsm.11_13 = PHI <b.4_12(5), 1(12)>

It looks like loop peeling has difficulty in coping with peeled phi node.

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[amker.cheng at gmail dot com]

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

--- Comment #5 from bin.cheng <amker.cheng at gmail dot com> ---
For the offending loop:

  <bb 5>:

  <bb 6>:
  # b.4_30 = PHI <b.4_12(5), 1(12)>
  # prephitmp_28 = PHI <c.1_9(5), c.1_21(12)>
  # b_lsm.11_13 = PHI <b.4_12(5), 1(12)>
  # ivtmp_46 = PHI <ivtmp_45(5), 13(12)>
  c.1_9 = prephitmp_28 | 1;
  b.4_12 = b.4_30 + 1;
  ivtmp_45 = ivtmp_46 - 1;
  if (ivtmp_45 != 0)
    goto <bb 5>;
  else
    goto <bb 7>;

Now SCEV recognizes b_lsm.11_13 as {1,1}_2, and vectorizer considers it can be
vectorized.
The problem comes in function slpeel_update_phi_nodes_for_guard1 for phi node
:# b_lsm.11_13 = PHI <b.4_12(5), 1(12)>.  It's special because its loop_arg:
b.4_12 has already been handled in previous node and has non-null current
definition, resulting in assertion failure at line:
  gcc_assert (get_current_def (current_new_name) == NULL_TREE);

It seems loop manipulating utility for vectorization can't cope with this kind
PEELED phi node.

We can get more loops vectorized if we can handle this issue in vectorization.
For example, the more complicated example reported can be vectorized
successfully.

But, I think it's a little bit difficult to handle the case because it's
possible to have the PEELED phi node come before the phi node from which it's
peeled from (b.4_30, in this case), just like:

  <bb 5>:

  <bb 6>:
  # b_lsm.11_13 = PHI <b.4_12(5), 1(12)>   <----appear before b.4_30
  # b.4_30 = PHI <b.4_12(5), 1(12)>
  # prephitmp_28 = PHI <c.1_9(5), c.1_21(12)>
  # ivtmp_46 = PHI <ivtmp_45(5), 13(12)>
  c.1_9 = prephitmp_28 | 1;
  b.4_12 = b.4_30 + 1;
  ivtmp_45 = ivtmp_46 - 1;
  if (ivtmp_45 != 0)
    goto <bb 5>;
  else
    goto <bb 7>;

So here I come up three options:
0) handle peeled phi in slpeel_update_phi_nodes_for_guard*.  Maybe two passes
scanning for phi nodes is necessary.
1) reject loops containing peeled phi node in vectorization.
2) add code to rewrite such peeled phi node into normal one.

I am new to vectorization, so any words?

Thanks,
bin

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[jakub at gcc dot gnu.org]

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

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

I wonder if this isn't just a checking issue, the two PHI nodes created in
*new_exit_bb have the same argument, so I think it is just fine if the two PHI
results are used interchangeably, later optimization passes should hopefully
coalesce them into a single IV.

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[amker.cheng at gmail dot com]

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

--- Comment #7 from bin.cheng <amker.cheng at gmail dot com> ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 31562 [details]
> gcc49-pr59519.patch
> 
> I wonder if this isn't just a checking issue, the two PHI nodes created in
> *new_exit_bb have the same argument, so I think it is just fine if the two
> PHI results are used interchangeably, later optimization passes should
> hopefully coalesce them into a single IV.

I tested one similar patch before.  It passed x86_64 bootstrap and normal
regression test.  It failed some ada (also one go) cases if I ran regression
test with "-O3" option.  The failures look like noise to me, which I am not
sure about.  What's your test results?

One potential shortage is it introduces additional PHI/copy of different ssa
names and makes the generated code some kind of ugly and hard to read, but just
as you pointed out, later passes should be able to coalescing them (I am not
sure about that, especially after seeing ssa names not get coalesced in some
more regular cases.)

Thanks.

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
BTW, the patch can hardly regress anything, it only affects cases that ICEd
before the patch.

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[amker.cheng at gmail dot com]

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

--- Comment #10 from bin.cheng <amker.cheng at gmail dot com> ---
(In reply to Jakub Jelinek from comment #9)
> BTW, the patch can hardly regress anything, it only affects cases that ICEd
> before the patch.

Em, I am worried if vectorization can handle peeled phi correctly for each
scenario before, because I barely know the implementation.  That's why I looked
for your guys' suggestions in the first place.

Thanks.

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've tried even:
struct S { int f0; } d;
int a[8] = { 0 }, b, c, e, f;

void
foo (void)
{
  for (; e < 1; e++)
    {
      for (b = 0; b < 7; b++)
        {
          c |= (a[b + 1] != 0);
          if (d.f0)
            break;
        }
      f += b;
    }
}

where I've hoped get_current_def would be called on the problematic loop_arg,
but apparently it isn't (the only calls are the one changed in the patch).

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
--target_board=unix/-O3 testing showed no changes (except for the testcases in
the patch), on both x86_64-linux and i686-linux (on the former one including
ada testing).

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Sat Jan  4 11:23:16 2014
New Revision: 206333

URL: http://gcc.gnu.org/viewcvs?rev=206333&root=gcc&view=rev
Log:
    PR tree-optimization/59519
    * tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_guard1): Don't
    ICE if get_current_def (current_new_name) is already non-NULL, as long
    as it is a phi result of some other phi in *new_exit_bb that has
    the same argument.

    * gcc.dg/vect/pr59519-1.c: New test.
    * gcc.dg/vect/pr59519-2.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/vect/pr59519-1.c
    trunk/gcc/testsuite/gcc.dg/vect/pr59519-2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-vect-loop-manip.c

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.