[Bug c++/61094] New: -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[Bug c++/61094] New: -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[prsodk at gmail dot com]

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

            Bug ID: 61094
           Summary: -O3 insn Internal compiler error in
                    copyprop_hardreg_forward_1, at regcprop.c:775
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: prsodk at gmail dot com

Created attachment 32753
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32753&action=edit
-O3 ins Internal compiler error in copyprop_hardreg_forward_1, at
regcprop.c:775

Compiled with g++ 4.9.0 on Archlinux

make[2]: Entering directory '/home/user/projects/gmic/src'
g++ -o gmic gmic.cpp -Dgmic_build -I/usr/include -Wall -W -Dgmic_is_beta=1
-Dcimg_use_vt100 -Dgmic_check_image -Dgmic_is_parallel -Dcimg_display=1
-Dcimg_appname=\"gmic\" -I/usr/X11R6/include  -Dcimg_use_png -Dcimg_use_jpeg
-Dcimg_use_tiff -Dcimg_use_zlib -Dcimg_use_openexr -I/usr/include/OpenEXR
-Dcimg_use_fftw3  -O3 -fno-ipa-sra -mtune=generic  -Dgmic_float_only
-Dgmic_main -L/usr/lib -lm -lpthread -L/usr/X11R6/lib -lX11 -lpthread  -lpng
-lz -ljpeg -ltiff -lz -lIlmImf -lHalf -lfftw3 -lfftw3_threads 
In file included from gmic.h:70:0,
                 from gmic.cpp:1762:
./CImg.h: In member function ‘cimg_library::CImg<typename
cimg_library::CImg<T>::ucharT> cimg_library::CImg<T>::__get_select(const
cimg_library::CImgDisplay&, int, int, int, int) const [with T = float; typename
cimg_library::CImg<T>::ucharT = unsigned char]’:
./CImg.h:35001:5: error: insn does not satisfy its constraints:
     }
     ^
(insn 3134 2970 1739 248 (set (reg:DI 21 xmm0)
        (reg:DI 0 ax)) ./CImg.h:22643 89 {*movdi_internal}
     (nil))
./CImg.h:35001:5: internal compiler error: in copyprop_hardreg_forward_1, at
regcprop.c:775

Compiles ok with earlier versions of g++
Compiles ok with -O2

gmic.ii.gz attached 
Full source at:
git clone http://git.code.sf.net/p/gmic/source gmic
>From gcc-bugs-return-450787-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 07 10:48:07 2014
Return-Path: <gcc-bugs-return-450787-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7815 invoked by alias); 7 May 2014 10:48:03 -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 7694 invoked by uid 48); 7 May 2014 10:47:57 -0000
From: "hp at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/59584] [4.8/4.9/4.10 Regression]: regressions related to __builtin_stack_restore
Date: Wed, 07 May 2014 10:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.8.3
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hp at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P5
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.1
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59584-4-eza4IRUtBL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59584-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59584-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-05/txt/msg00479.txt.bz2
Content-length: 1989

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

--- Comment #15 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #14)
> Ok, but it's not clear to me what the bug is and why it's not a target bug
> fixed by your changes.

Ok, I'll try to explain my point without putting time I don't have into this:
the CRIS subtarget I'm most interested in now, requires that the stack-pointer
is valid at all times.  For this target, the fix I committed is enough to cover
the issue with no conceivable way to have such an insn validly split.

For another target, either maybe a completely different port, but there
actually *is* another CRIS subtarget, such a define_split makes sense: the
stack-pointer used at interrupts is different to the "user" stack-pointer
(another register).  For that subtarget the fix is (very very minor) suboptimal
cover-up in the absense of the other commits.  The actual commits here *may*
have made the case where the tweaked define_split would previously match
impossible, or they *may* have just made the issue latent.

The case here is where the stack-pointer is *set* (not just incremented or
decremented) from a variable, and IIRC that instruction sequence is very
unlikely except when __builtin_stack_restore is used, and nobody would use
that, so almost never (as I recall my analysis then and yes I considered
exceptions).  See also
<http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01847.html>, the patch message.

Thus, I'm fine with closing this for the regressions but not exactly for the
issue in comment #5 for which the bug was opened; "the combination of
expr.c:find_args_size_adjust and expr.c:fixup_args_size_notes can't handle a
define_split matching for the stack-adjustment assignment instruction emitted
by __builtin_stack_restore".  (In other words, a person investigating such an
issue in the future, would not be helped by searching the bugzilla and finding
this PR with the previous title as closed.)

[Bug c++/61094] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-05-07
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  Reducing.

[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-*
          Component|c++                         |rtl-optimization
      Known to work|                            |4.8.2
   Target Milestone|---                         |4.9.1
            Summary|-O3 insn Internal compiler  |[4.9/4.10 Regression] -O3
                   |error in                    |insn Internal compiler
                   |copyprop_hardreg_forward_1, |error in
                   |at regcprop.c:775           |copyprop_hardreg_forward_1,
                   |                            |at regcprop.c:775

[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[rguenth at gcc dot gnu.org]

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

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

I stopped reducing, it's very slow (because compiling the testcase is so slow).
Attached what I have sofar.

[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
template <typename> struct A {
  unsigned _width, _height, _depth, _spectrum;
  template <typename t> A(t p1) {
    int a = p1.size();
    if (a) {
      _width = p1._width;
      _depth = _height = _spectrum = p1._spectrum;
    }
  }
  long size() { return (long)_width * _height * _depth * _spectrum; }
};

int d;
void fn1(void *);
A<int> *fn2();
void fn3() {
  int b;
  for (;;) {
    A<char> c(*fn2());
    fn1(&c);
    if (d || !b)
      throw;
  }
}




a.ii: In function 'void fn3()':
a.ii:24:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 67 20 62 3 (set (reg:DI 21 xmm0)
        (reg:DI 2 cx)) 89 {*movdi_internal}
     (expr_list:REG_DEAD (reg:DI 2 cx)
        (nil)))
a.ii:24:1: internal compiler error: in copyprop_hardreg_forward_1, at
regcprop.c:775

[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
REE pass turns

(insn 8 6 9 2 (set (reg:SI 21 xmm0 [orig:94 p1 ] [94])
        (mem:SI (reg/f:DI 0 ax [orig:83 D.2426 ] [83]) [3 MEM[(const struct A
&)_4]+0 S4 A32])) 90 {*movsi_internal}
     (nil))
(insn 10 9 11 2 (set (reg:DI 2 cx [orig:102 D.2428 ] [102])
        (zero_extend:DI (reg:SI 21 xmm0 [orig:94 p1 ] [94]))) pr61094.cc:10 132
{*zero_extendsidi2}
     (nil))

into

(insn 8 6 64 2 (set (reg:DI 2 cx) 
        (zero_extend:DI (mem:SI (reg/f:DI 0 ax [orig:83 D.2426 ] [83]) [3
MEM[(const struct A &)_4]+0 S4 A32]))) 132 {*zero_extendsidi2}
     (nil))
(insn 64 8 9 2 (set (reg:DI 21 xmm0)
        (reg:DI 2 cx [orig:102 D.2428 ] [102])) -1
     (nil))

Unfortunately (set (reg:DI 21 xmm0) (reg:DI 2 cx)) is disabled for
-mtune=generic.

[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[steven at gcc dot gnu.org]

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

Steven Bosscher <steven at gcc dot gnu.org> changed:

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

--- Comment #6 from Steven Bosscher <steven at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> Started with r206418.

Would help if the pass validates that the insns it emits in find_and_remove_re
are valid.

[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That is too late, at that point we already have to perform those moves,
supposedly it has to be validated together with all the other related changes
in
apply_change_group () in combine_reaching_defs.
Just creating the copy insn in combine_reaching_defs, validating it there and
then passing it up to the caller, remembering it in reinsn_copy_list (instead
of def_insn or in addition to that?) and then just emitting the already
validated insn isn't probably enough, as further combine_reaching_defs calls
supposedly can widen the copy insn even more, so such changes would need to be
verified too.  Perhaps if reinsn_copy_list contained 3 insns instead of two,
curr_insn, def_insn and the currently prepared copy_insn, and let
combine_reaching_defs walk the array looking for triplets for the current
def_insn if we are widening them and adjusting those too?  Dunno if there can
be at most one or how to avoid the walk of the vector.  Jeff, will you have
time to look at this?

[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com
           Assignee|unassigned at gcc dot gnu.org      |law at redhat dot com

--- Comment #8 from Jeffrey A. Law <law at redhat dot com> ---
Mine :-)

[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Sure, there, or merge_def_and_ext, or combine_reaching_defs.
In any case, what I'm afraid of is that when there are two extensions, you in
the first round verify that a copy is suitable and so is the new extension
insn, but then you widen the extension insn even further, the widening
succeeds, but nothing verifies the copy insn that is now to be performed in the
even wider mode compared from what has been verified earlier.  And in the wider
mode it might be unsupported.

[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[law at redhat dot com]

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

--- Comment #11 from Jeffrey A. Law <law at redhat dot com> ---
Right, and that's the case I'm still pondering.

[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[law at redhat dot com]

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

--- Comment #12 from Jeffrey A. Law <law at redhat dot com> ---
I think the cascading problem can be pretty easily addressed.

The problematical sequence of insns would look something like this:

A (set (r0) (expression))
B (set (r1) (extend (r0))
C (set (r0) (extend (r0))

If we process B first, then we will set the modified flag for A as well as a
mode for A.  At that time we will verify that (set (r0) (r1)) in the desired
mode is valid.  We'll update A appropriately and queue B for removal and a copy
insn for insertion.

If we then process C, we may decide that we want an even wider mode for A. 
This will change A in the obvious ways.

At a later point we'll emit the queued copy insn which take the wider mode
which has not been verified and we lose.

The key realization is that we can store more than just "we modified A".   So
when processing B, we set A's state to "modifed, do not change its mode
further".  When we process C, we'd see that status on A and punt optimizing C.

I would expect this to be rare in practice, but I'll do some experiments to see
how often we have to suppress an optimization.

[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I vaguely remember it has been seen in the wild, not sure how often, but there
were several bugreports about that.

In any case, I'd say it is a pitty to stop optimizing this case for the
unlikely case there is no move insn, the needed pending moves should be around
and thus can be also verified in the wider mode, the question is if we want to
do a linear search for them, or have some faster way to find them.

[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[law at redhat dot com]

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

--- Comment #14 from Jeffrey A. Law <law at redhat dot com> ---
I'm not talking about restricting the general case where we've got cascaded
extensions.  Just the case where one of the insns in the cascade has a
source/dest that are not the same register.  Which is a case we didn't even try
to optimize until 4.9.

[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[law at gcc dot gnu.org]

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

--- Comment #15 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Author: law
Date: Mon Jun  2 19:12:08 2014
New Revision: 211142

URL: http://gcc.gnu.org/viewcvs?rev=211142&root=gcc&view=rev
Log:
    PR rtl-optimization/61094
    * ree.c (combine_reaching_defs): Do not reextend an insn if it
    was marked as do_no_reextend.  If a copy is needed to eliminate
    an extension, then mark it as do_not_reextend.

    PR rtl-optimization/61094
    * g++.dg/pr61094: New test.

Added:
    trunk/gcc/testsuite/g++.dg/pr61094.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ree.c
    trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/61094] [4.9 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[law at gcc dot gnu.org]

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

--- Comment #16 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Author: law
Date: Fri Jun 13 16:40:48 2014
New Revision: 211649

URL: https://gcc.gnu.org/viewcvs?rev=211649&root=gcc&view=rev
Log:
2014-06-13  Jeff Law  <law@redhat.com>

    PR rtl-optimization/61094
    PR rtl-optimization/61446
    * ree.c (combine_reaching_defs): Get the mode for the copy from
    the extension insn rather than the defining insn.

2014-06-13  Ilya Enkovich  <ilya.enkovich@intel.com>

    PR rtl-optimization/61094
    PR rtl-optimization/61446
    * gcc.target/i386/pr61446.c : New.

Added:
    trunk/gcc/testsuite/gcc.target/i386/pr61446.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ree.c
    trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/61094] [4.9 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[law at gcc dot gnu.org]

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

--- Comment #17 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Author: law
Date: Fri Jun 13 16:50:01 2014
New Revision: 211651

URL: https://gcc.gnu.org/viewcvs?rev=211651&root=gcc&view=rev
Log:
    PR rtl-optimization/61094
    * ree.c (combine_reaching_defs): Do not reextend an insn if it
    was marked as do_no_reextend.  If a copy is needed to eliminate
    an extension, then mark it as do_not_reextend.

    PR rtl-optimization/61094
    * g++.dg/pr61094: New test.

Added:
    branches/gcc-4_9-branch/gcc/testsuite/g++.dg/pr61094.C
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/ree.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/61094] [4.9 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[law at gcc dot gnu.org]

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

--- Comment #18 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Author: law
Date: Fri Jun 13 16:50:10 2014
New Revision: 211652

URL: https://gcc.gnu.org/viewcvs?rev=211652&root=gcc&view=rev
Log:
2014-06-13  Jeff Law  <law@redhat.com>

    PR rtl-optimization/61094
    PR rtl-optimization/61446
    * ree.c (combine_reaching_defs): Get the mode for the copy from
    the extension insn rather than the defining insn.

2014-06-13  Ilya Enkovich  <ilya.enkovich@intel.com>

    PR rtl-optimization/61094
    PR rtl-optimization/61446
    * gcc.target/i386/pr61446.c : New.

Added:
    branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr61446.c
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/ree.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/61094] [4.9 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

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

--- Comment #19 from Jeffrey A. Law <law at redhat dot com> ---
Resolved on branch & trunk.

[Bug rtl-optimization/61094] [4.9 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[uros at gcc dot gnu.org]

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

--- Comment #20 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Jun 18 20:01:37 2014
New Revision: 211803

URL: https://gcc.gnu.org/viewcvs?rev=211803&root=gcc&view=rev
Log:
    Backport from mainline
    2014-06-06  Uros Bizjak  <ubizjak@gmail.com>

    PR target/61423
    * config/i386/i386.md (*floatunssi<mode>2_i387_with_xmm): New
    define_insn_and_split pattern, merged from *floatunssi<mode>2_1
    and corresponding splitters.  Zero extend general register
    or memory input operand to XMM temporary.  Enable for
    TARGET_SSE2 and TARGET_INTER_UNIT_MOVES_TO_VEC only.
    (floatunssi<mode>2): Update expander predicate.

testsuite/ChangeLog:

    Backport from mainline
    2014-06-13  Ilya Enkovich  <ilya.enkovich@intel.com>

    PR rtl-optimization/61094
    PR rtl-optimization/61446
    * gcc.target/i386/pr61446.c : New.

    Backport from mainline
    2014-06-06  Uros Bizjak  <ubizjak@gmail.com>

    PR target/61423
    * gcc.target/i386/pr61423.c: New test.


Added:
    branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr61423.c
    branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr61446.c
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/config/i386/i386.md
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog