[Bug tree-optimization/61010] New: ICE in gcc.c

[Bug tree-optimization/61010] New: ICE in gcc.c

[ishiura-compiler at ml dot kwansei.ac.jp]

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

            Bug ID: 61010
           Summary: ICE in gcc.c
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ishiura-compiler at ml dot kwansei.ac.jp

GCC 4.8 - 4.10 for i686 and x86_64 ICE the following code.

  /*

  $ x86_64-unknown-linux-gnu-gcc-4.10.0 test.c
  x86_64-unknown-linux-gnu-gcc-4.10.0: internal compiler error:
  Segmentation fault (program cc1)
  0x40ce59 execute
  /home/hassy/gcc-master/gcc/gcc.c:2848
  0x40d0c9 do_spec_1
  /home/hassy/gcc-master/gcc/gcc.c:4652
  0x40fd76 process_brace_body
  /home/hassy/gcc-master/gcc/gcc.c:5935
  0x40fd76 handle_braces
  /home/hassy/gcc-master/gcc/gcc.c:5849
  0x40deb7 do_spec_1
  /home/hassy/gcc-master/gcc/gcc.c:5306
  0x40fd76 process_brace_body
  /home/hassy/gcc-master/gcc/gcc.c:5935
  0x40fd76 handle_braces
  /home/hassy/gcc-master/gcc/gcc.c:5849
  0x40deb7 do_spec_1
  /home/hassy/gcc-master/gcc/gcc.c:5306
  0x40ddbe do_spec_1
  /home/hassy/gcc-master/gcc/gcc.c:5421
  0x40fd76 process_brace_body
  /home/hassy/gcc-master/gcc/gcc.c:5935
  0x40fd76 handle_braces
  /home/hassy/gcc-master/gcc/gcc.c:5849
  0x40deb7 do_spec_1
  /home/hassy/gcc-master/gcc/gcc.c:5306
  0x40fd76 process_brace_body
  /home/hassy/gcc-master/gcc/gcc.c:5935
  0x40fd76 handle_braces
  /home/hassy/gcc-master/gcc/gcc.c:5849
  0x40deb7 do_spec_1
  /home/hassy/gcc-master/gcc/gcc.c:5306
  0x40fd76 process_brace_body
  /home/hassy/gcc-master/gcc/gcc.c:5935
  0x40fd76 handle_braces
  /home/hassy/gcc-master/gcc/gcc.c:5849
  0x40deb7 do_spec_1
  /home/hassy/gcc-master/gcc/gcc.c:5306
  0x40fd76 process_brace_body
  /home/hassy/gcc-master/gcc/gcc.c:5935
  0x40fd76 handle_braces
  /home/hassy/gcc-master/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.

  $ x86_64-unknown-linux-gnu-gcc-4.10.0 -v
  Using built-in specs.
  COLLECT_GCC=x86_64-unknown-linux-gnu-gcc-4.10.0
 
COLLECT_LTO_WRAPPER=/usr/local/x86_64-tools/gcc-4.10.0/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
  Target: x86_64-unknown-linux-gnu
  Configured with: /home/hassy/gcc-master/configure
  --prefix=/usr/local/x86_64-tools/gcc-4.10.0/
  --with-gmp=/usr/local/gmp-5.1.1/ --with-mpfr=/usr/local/mpfr-3.1.2/
  --with-mpc=/usr/local/mpc-1.0.2/ --disable-multilib --disable-nls
  --enable-languages=c
  Thread model: posix
  gcc version 4.10.0 20140429 (experimental) (GCC)

  */

  int main (void)
  {
      int a = 0;
      unsigned b = (a * 64 & 192) | 63U;
      return 0;
  }

[Bug middle-end/61010] ICE in gcc.c

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-04-30
          Component|tree-optimization           |middle-end
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed:
#0  0x0000000000b909a2 in tree_strip_sign_nop_conversions (exp=0x7ffff6e51280)
at /home/pinskia/src/local/gcc/gcc/tree.c:11588
#1  0x0000000000777d87 in split_tree (in=in@entry=0x7ffff6e51280,
code=code@entry=BIT_AND_EXPR, 
    conp=conp@entry=0x7ffffbfff0e0, litp=litp@entry=0x7ffffbfff0e8,
minus_litp=minus_litp@entry=0x7ffffbfff0f0, 
    negate_p=negate_p@entry=0) at
/home/pinskia/src/local/gcc/gcc/fold-const.c:818
#2  0x00000000007405eb in fold_binary_loc (loc=loc@entry=551,
code=code@entry=BIT_AND_EXPR, type=type@entry=0x7ffff6d42738, 
    op0=op0@entry=0x7ffff6e5ea60, op1=op1@entry=0x7ffff6e5ea20) at
/home/pinskia/src/local/gcc/gcc/fold-const.c:10690
#3  0x0000000000761edb in fold_build2_stat_loc (loc=loc@entry=551,
code=code@entry=BIT_AND_EXPR, 
    type=type@entry=0x7ffff6d42738, op0=op0@entry=0x7ffff6e5ea60,
op1=0x7ffff6e5ea20)
    at /home/pinskia/src/local/gcc/gcc/fold-const.c:15170
#4  0x0000000000754ef8 in fold_binary_loc (loc=loc@entry=551,
code=code@entry=BIT_AND_EXPR, type=type@entry=0x7ffff6d42738, 
    op0=op0@entry=0x7ffff6e5ea60, op1=op1@entry=0x7ffff6d41a60) at
/home/pinskia/src/local/gcc/gcc/fold-const.c:11855
#5  0x0000000000761edb in fold_build2_stat_loc (loc=loc@entry=551,
code=code@entry=BIT_AND_EXPR, 
    type=type@entry=0x7ffff6d42738, op0=0x7ffff6e5ea60,
op1=op1@entry=0x7ffff6d41a60)
    at /home/pinskia/src/local/gcc/gcc/fold-const.c:15170
#6  0x000000000074f155 in fold_binary_loc (loc=loc@entry=551,
code=code@entry=BIT_IOR_EXPR, type=type@entry=0x7ffff6d42738, 
    op0=op0@entry=0x7ffff6619208, op1=op1@entry=0x7ffff6e5ea00) at
/home/pinskia/src/local/gcc/gcc/fold-const.c:11458
#7  0x0000000000761edb in fold_build2_stat_loc (loc=loc@entry=551,
code=code@entry=BIT_IOR_EXPR, 
    type=type@entry=0x7ffff6d42738, op0=0x7ffff6619208,
op1=op1@entry=0x7ffff6e5ea00)
    at /home/pinskia/src/local/gcc/gcc/fold-const.c:15170
#8  0x000000000074f172 in fold_binary_loc (loc=loc@entry=551,
code=code@entry=BIT_IOR_EXPR, type=type@entry=0x7ffff6d42738, 
    op0=op0@entry=0x7ffff66191e0, op1=op1@entry=0x7ffff6e5ea00) at
/home/pinskia/src/local/gcc/gcc/fold-const.c:11458
#9  0x0000000000761edb in fold_build2_stat_loc (loc=loc@entry=551,
code=code@entry=BIT_IOR_EXPR, 
    type=type@entry=0x7ffff6d42738, op0=0x7ffff66191e0,
op1=op1@entry=0x7ffff6e5ea00)
    at /home/pinskia/src/local/gcc/gcc/fold-const.c:15170
#10 0x000000000074f172 in fold_binary_loc (loc=loc@entry=551,
code=code@entry=BIT_IOR_EXPR, type=type@entry=0x7ffff6d42738, 
    op0=op0@entry=0x7ffff66191b8, op1=op1@entry=0x7ffff6e5ea00) at
/home/pinskia/src/local/gcc/gcc/fold-const.c:11458
#11 0x0000000000761edb in fold_build2_stat_loc (loc=loc@entry=551,
code=code@entry=BIT_IOR_EXPR, 
    type=type@entry=0x7ffff6d42738, op0=0x7ffff66191b8,
op1=op1@entry=0x7ffff6e5ea00)
    at /home/pinskia/src/local/gcc/gcc/fold-const.c:15170
#12 0x000000000074f172 in fold_binary_loc (loc=loc@entry=551,
code=code@entry=BIT_IOR_EXPR, type=type@entry=0x7ffff6d42738, 
    op0=op0@entry=0x7ffff6619190, op1=op1@entry=0x7ffff6e5ea00) at
/home/pinskia/src/local/gcc/gcc/fold-const.c:11458
#13 0x0000000000761edb in fold_build2_stat_loc (loc=loc@entry=551,
code=code@entry=BIT_IOR_EXPR, 
    type=type@entry=0x7ffff6d42738, op0=0x7ffff6619190,
op1=op1@entry=0x7ffff6e5ea00)
    at /home/pinskia/src/local/gcc/gcc/fold-const.c:15170
#14 0x000000000074f172 in fold_binary_loc (loc=loc@entry=551,
code=code@entry=BIT_IOR_EXPR, type=type@entry=0x7ffff6d42738, 
    op0=op0@entry=0x7ffff6619168, op1=op1@entry=0x7ffff6e5ea00) at
/home/pinskia/src/local/gcc/gcc/fold-const.c:11458
#15 0x0000000000761edb in fold_build2_stat_loc (loc=loc@entry=551,
code=code@entry=BIT_IOR_EXPR, 
    type=type@entry=0x7ffff6d42738, op0=0x7ffff6619168,
op1=op1@entry=0x7ffff6e5ea00)
    at /home/pinskia/src/local/gcc/gcc/fold-const.c:15170
#16 0x000000000074f172 in fold_binary_loc (loc=loc@entry=551,
code=code@entry=BIT_IOR_EXPR, type=type@entry=0x7ffff6d42738, 
    op0=op0@entry=0x7ffff6619140, op1=op1@entry=0x7ffff6e5ea00) at
/home/pinskia/src/local/gcc/gcc/fold-const.c:11458
#17 0x0000000000761edb in fold_build2_stat_loc (loc=loc@entry=551,
code=code@entry=BIT_IOR_EXPR, 
    type=type@entry=0x7ffff6d42738, op0=0x7ffff6619140,
op1=op1@entry=0x7ffff6e5ea00)
    at /home/pinskia/src/local/gcc/gcc/fold-const.c:15170


So an infinite loop dealing with AND and OR.

[Bug middle-end/61010] ICE in gcc.c

[mpolacek at gcc dot gnu.org]

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

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

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

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Seems to have started with r187280.

[Bug middle-end/61010] ICE in gcc.c

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Looks like a manifestation of PR 58088

[Bug middle-end/61010] ICE in gcc.c

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Hmmm...

  int main (void)
  {
      int a = 0;
      unsigned b = (a * 64 & 192) | 63;
      return 0;
  }
works (i.e. 63 without the U).
I suspect there's something dodgy with the implementation of
mask_with_tz (tree type, double_int x, double_int y) in fold-const.c that I
added with r202652.

Interestingly, the wide-int branch that rewrites that function to use the new
wide-int interface makes this ICE go away.

[Bug middle-end/61010] [4.8/4.9/4.10 Regression] Infinite recursion in fold

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.7.3
   Target Milestone|---                         |4.8.3
            Summary|ICE in gcc.c                |[4.8/4.9/4.10 Regression]
                   |                            |Infinite recursion in fold

[Bug middle-end/61010] [4.8/4.9/4.10 Regression] Infinite recursion in fold

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Indeed we iterate in /* Canonicalize (X & C1) | C2.  */ because we fold

 (unsigned int) (a * 64) & 255

to

 (unsigned int) (a * 64) & 192

in /* Fold (X * CST1) & CST2 to zero if we can, or drop known zero bits from
CST2.  */


The iterating input is

 ((unsigned int) (a * 64) & 192) | 63

where it seems to fail to "Minimize the number of bits set in C1"
because it hits the "unless" case.

One option is to apply the same "unless" case to the "drop known zero bits"
BIT_AND_EXPR folding.

[Bug middle-end/61010] [4.8/4.9/4.10 Regression] Infinite recursion in fold

[rguenth at gcc dot gnu.org]

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

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

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

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

          /* If X is a tree of the form (Y * K1) & K2, this might conflict
             with that optimization from the BIT_AND_EXPR optimizations.
             This could end up in an infinite recursion.  */

doesn't trigger because we have an intermediate cast to unsigned (which is
dropped) around the multiplication.

rev. 130635 which introduced that limitation on reducing the number of bits
suggests that we want to apply the same heuristic to the BIT_AND_EXPR
folding.  Jakub, any opinion?

[Bug middle-end/61010] [4.8/4.9/4.10 Regression] Infinite recursion in fold

[rguenth at gcc dot gnu.org]

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

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 #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine.

[Bug middle-end/61010] [4.8/4.9/4.10 Regression] Infinite recursion in fold

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Like

Index: gcc/fold-const.c
===================================================================
--- gcc/fold-const.c    (revision 209928)
+++ gcc/fold-const.c    (working copy)
@@ -11426,7 +11426,6 @@ fold_binary_loc (location_t loc,
        {
          double_int c1, c2, c3, msk;
          int width = TYPE_PRECISION (type), w;
-         bool try_simplify = true;

          c1 = tree_to_double_int (TREE_OPERAND (arg0, 1));
          c2 = tree_to_double_int (arg1);
@@ -11463,20 +11462,7 @@ fold_binary_loc (location_t loc,
                }
            }

-         /* If X is a tree of the form (Y * K1) & K2, this might conflict
-            with that optimization from the BIT_AND_EXPR optimizations.
-            This could end up in an infinite recursion.  */
-         if (TREE_CODE (TREE_OPERAND (arg0, 0)) == MULT_EXPR
-             && TREE_CODE (TREE_OPERAND (TREE_OPERAND (arg0, 0), 1))
-                           == INTEGER_CST)
-         {
-           tree t = TREE_OPERAND (TREE_OPERAND (arg0, 0), 1);
-           double_int masked = mask_with_tz (type, c3, tree_to_double_int
(t));
-
-           try_simplify = (masked != c1);
-         }
-
-         if (try_simplify && c3 != c1)
+         if (c3 != c1)
            return fold_build2_loc (loc, BIT_IOR_EXPR, type,
                                    fold_build2_loc (loc, BIT_AND_EXPR, type,
                                                     TREE_OPERAND (arg0, 0),
@@ -11866,16 +11852,25 @@ fold_binary_loc (location_t loc,
          && TREE_CODE (arg0) == MULT_EXPR
          && TREE_CODE (TREE_OPERAND (arg0, 1)) == INTEGER_CST)
        {
+         double_int darg1 = tree_to_double_int (arg1);
          double_int masked
-           = mask_with_tz (type, tree_to_double_int (arg1),
+           = mask_with_tz (type, darg1,
                            tree_to_double_int (TREE_OPERAND (arg0, 1)));

          if (masked.is_zero ())
            return omit_two_operands_loc (loc, type, build_zero_cst (type),
                                          arg0, arg1);
-         else if (masked != tree_to_double_int (arg1))
-           return fold_build2_loc (loc, code, type, op0,
-                                   double_int_to_tree (type, masked));
+         else if (masked != darg1)
+           {
+             /* Avoid the transform if arg1 is a mask of some
+                mode which allows further optimizations.  */
+             int pop = darg1.popcount ();
+             if (!(pop >= BITS_PER_UNIT
+                 && exact_log2 (pop) != -1
+                 && double_int::mask (pop) == darg1))
+               return fold_build2_loc (loc, code, type, op0,
+                                       double_int_to_tree (type, masked));
+           }
        }

       /* For constants M and N, if M == (1LL << cst) - 1 && (N & M) == M,

[Bug middle-end/61010] [4.8/4.9 Regression] Infinite recursion in fold

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.10.0
            Summary|[4.8/4.9/4.10 Regression]   |[4.8/4.9 Regression]
                   |Infinite recursion in fold  |Infinite recursion in fold
      Known to fail|                            |4.8.2, 4.9.0

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

[Bug middle-end/61010] [4.8/4.9 Regression] Infinite recursion in fold

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Mon May  5 09:23:31 2014
New Revision: 210066

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

    PR middle-end/61010
    * fold-const.c (fold_binary_loc): Consistently avoid
    canonicalizing X & CST away from a CST that is the mask
    of a mode.

    * gcc.dg/torture/pr61010.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/torture/pr61010.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/fold-const.c
    trunk/gcc/testsuite/ChangeLog

[Bug middle-end/61010] [4.8/4.9 Regression] Infinite recursion in fold

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.3                       |4.8.4

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 4.8.3 is being released, adjusting target milestone.

[Bug middle-end/61010] [4.8 Regression] Infinite recursion in fold

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Wed May 28 12:46:39 2014
New Revision: 211019

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

    Backport from mainline
    2014-05-28  Richard Biener  <rguenther@suse.de>

    PR middle-end/61045
    * fold-const.c (fold_comparison): When folding
    X +- C1 CMP Y +- C2 to X CMP Y +- C2 +- C1 also ensure
    the sign of the remaining constant operand stays the same.

    * gcc.dg/pr61045.c: New testcase.

    2014-05-05  Richard Biener  <rguenther@suse.de>

    PR middle-end/61010
    * fold-const.c (fold_binary_loc): Consistently avoid
    canonicalizing X & CST away from a CST that is the mask
    of a mode.

    * gcc.dg/torture/pr61010.c: New testcase.

    2014-04-28  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/60979
    * graphite-scop-detection.c (scopdet_basic_block_info): Reject
    SCOPs that end in a block with a successor with abnormal
    predecessors.

    * gcc.dg/graphite/pr60979.c: New testcase.

Added:
    branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/graphite/pr60979.c
    branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr61045.c
    branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr61010.c
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/fold-const.c
    branches/gcc-4_9-branch/gcc/graphite-scop-detection.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/61010] [4.8 Regression] Infinite recursion in fold

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to work|4.10.0                      |4.8.4, 5.0
         Resolution|---                         |FIXED
      Known to fail|4.8.2                       |4.8.3

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

[Bug middle-end/61010] [4.8 Regression] Infinite recursion in fold

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Tue Sep  9 13:17:51 2014
New Revision: 215073

URL: https://gcc.gnu.org/viewcvs?rev=215073&root=gcc&view=rev
Log:
2014-09-09  Richard Biener  <rguenther@suse.de>

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

    PR middle-end/61010
    * fold-const.c (fold_binary_loc): Consistently avoid
    canonicalizing X & CST away from a CST that is the mask
    of a mode.

    * gcc.dg/torture/pr61010.c: New testcase.

    2014-05-28  Richard Biener  <rguenther@suse.de>

    PR middle-end/61045
    * fold-const.c (fold_comparison): When folding
    X +- C1 CMP Y +- C2 to X CMP Y +- C2 +- C1 also ensure
    the sign of the remaining constant operand stays the same.

    * gcc.dg/pr61045.c: New testcase.

    2014-08-11  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/62075
    * tree-vect-slp.c (vect_detect_hybrid_slp_stmts): Properly
    handle uses in patterns.

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

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr61045.c
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr61010.c
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr62075.c
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/fold-const.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_8-branch/gcc/tree-vect-slp.c