[Bug middle-end/56548] New: [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[Bug middle-end/56548] New: [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[d.g.gorbachev at gmail dot com]

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

             Bug #: 56548
           Summary: [4.8 Regression] ICE in emit_move_insn, at expr.c:3486
                    with -march=pentium{pro,2,3} -O3
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: d.g.gorbachev@gmail.com


GCC 4.8.0 20130303 (experimental).

$ cat > bug.c
short foo(short x)
{
  int i;

  for (i = 0; i < 3; i++)
    if (x > 0)
      x--;

  return x;
}
^D
$ gcc -S -O3 -march=pentium3 bug.c
bug.c: In function 'foo':
bug.c:9:3: internal compiler error: in emit_move_insn, at expr.c:3486
   return x;
   ^
0x834eaa1 emit_move_insn(rtx_def*, rtx_def*)
    ../../gcc-4.8/gcc/expr.c:3485
0x8600ef9 expand_value_return
    ../../gcc-4.8/gcc/stmt.c:1461
0x86068d8 expand_return(tree_node*)
    ../../gcc-4.8/gcc/stmt.c:1547
0x825eefc expand_gimple_stmt_1
    ../../gcc-4.8/gcc/cfgexpand.c:2182
0x825f82c expand_gimple_stmt
    ../../gcc-4.8/gcc/cfgexpand.c:2304
0x8262484 expand_gimple_basic_block
    ../../gcc-4.8/gcc/cfgexpand.c:4083
0x82648c8 gimple_expand_cfg
    ../../gcc-4.8/gcc/cfgexpand.c:4602

GCC 20121118 (r193607) - fails, 20121111 (r193417) - works.

[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-03-06
                 CC|                            |jakub at gcc dot gnu.org
   Target Milestone|---                         |4.8.0
     Ever Confirmed|0                           |1

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-06 09:58:31 UTC ---
Broken by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193539

[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |jakub at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-06 10:22:44 UTC ---
Created attachment 29595
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29595
gcc48-pr56548.patch

Untested fix.  Note I have no idea what performance issue on MIPS the patch
that regressed this was fixing and whether this fix doesn't undo that (or parts
thereof).  On the other side, unexpectedly returning a rtx in different mode
from what has been requested is a sure way to ICEs or miscompilations.

[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-06 17:18:53 UTC ---
Author: jakub
Date: Wed Mar  6 17:18:46 2013
New Revision: 196498

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196498
Log:
    PR middle-end/56548
    * expr.c (expand_cond_expr_using_cmove): When expanding cmove in
    promoted mode, convert the result back to the original mode.

    * gcc.dg/pr56548.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr56548.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/expr.c
    trunk/gcc/testsuite/ChangeLog

[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-06 17:22:48 UTC ---
Fixed.

[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[sje at gcc dot gnu.org]

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

--- Comment #5 from Steve Ellcey <sje at gcc dot gnu.org> 2013-03-06 18:04:30 UTC ---
For the record, this does undo the performance regression fix on MIPS.  I will
submit a new bug for that issue.  The problem (on mips) is that we want to do a
conditional move of a short to a destination that already contains a short.
Since we don't have a short conditional move we use an int conditional move,
but we shouldn't need to 'reconvert' the moved integer back to a short by
masking off the upper bits.  They are already zero because the source and dest
of the conditional move were both shorts.

[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-06 18:18:52 UTC ---
But you can't achieve that through generation of invalid RTL.

Anyway, I wonder why nonzero_bits during combine doesn't figure out that the
upper bits are already all zero and optimize away the masking.

[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[sje at gcc dot gnu.org]

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

--- Comment #7 from Steve Ellcey <sje at gcc dot gnu.org> 2013-03-06 18:22:44 UTC ---
(In reply to comment #6)
> But you can't achieve that through generation of invalid RTL.

Agreed.

> Anyway, I wonder why nonzero_bits during combine doesn't figure out that the
> upper bits are already all zero and optimize away the masking.

That I don't know.  I have opened bug 56552 to track the issue.

[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[ralf@linux-mips.org]

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

Ralf Baechle <ralf@linux-mips.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ralf@linux-mips.org

--- Comment #8 from Ralf Baechle <ralf@linux-mips.org> ---
FWIW, I'm also hitting the same compiler bug with vanilla GCC 4.7.2 and 4.8.0
compiling a heavily patched 3.4 kernel with LTO for a mips64-linux target.

The error messages for gcc 4.7.2:

  LDFINAL  .tmp_vmlinux1
In file included from include/net/sock.h:2119:0,
                 from net/sunrpc/svcsock.c:1041,
                 from :3662:
net/sunrpc/svcsock.c: In function ‘svc_tcp_recvfrom’:
net/sunrpc/svcsock.c:935:37: internal compiler error: in emit_move_insn, at
expr.c:3435
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [/tmp/ccaNAG6q.ltrans1.ltrans.o] Error 1
make[1]: *** Waiting for unfinished jobs....
lto1: internal compiler error: in output_constructor_regular_field, at
varasm.c:4821
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [/tmp/ccaNAG6q.ltrans0.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
/usr/lib64/gcc/mips64-lto-linux/4.7.2/../../../../mips64-lto-linux/bin/ld:
lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [.tmp_vmlinux1] Error 1

The error messages for gcc 4.8.0:

  LDFINAL  .tmp_vmlinux1
net/sunrpc/svcsock.c: In function ‘svc_tcp_recvfrom’:
net/sunrpc/svcsock.c:1104:0: internal compiler error: in emit_move_insn, at
expr.c:3486
 static int svc_tcp_recvfrom(struct svc_rqst *rqstp)
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [/tmp/ccehFRUG.ltrans0.ltrans.o] Error 1
make[1]: *** Waiting for unfinished jobs....
net/unix/garbage.c: In function ‘scan_inflight’:
net/unix/garbage.c:156:13: internal compiler error: in copy_to_mode_reg, at
explow.c:641
 static void scan_inflight(struct sock *x, void (*func)(struct unix_sock *),
             ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [/tmp/ccehFRUG.ltrans1.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
/usr/lib64/gcc/mips64-lto-linux/4.8.0/../../../../mips64-lto-linux/bin/ld:
lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [.tmp_vmlinux1] Error 1

I'm still working under the assumption that the builds are attempting to do
something stupid but even if so, an ICE is not the proper way to bail out.
>From gcc-bugs-return-422435-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu May 16 12:40:47 2013
Return-Path: <gcc-bugs-return-422435-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24629 invoked by alias); 16 May 2013 12:40:46 -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 24571 invoked by uid 48); 16 May 2013 12:40:42 -0000
From: "mikpe at it dot uu.se" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3
Date: Thu, 16 May 2013 12:40: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.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mikpe at it dot uu.se
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56548-4-wIHsftbPa8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56548-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56548-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-05/txt/msg01108.txt.bz2
Content-length: 532

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

--- Comment #9 from Mikael Pettersson <mikpe at it dot uu.se> ---
(In reply to Ralf Baechle from comment #8)
> FWIW, I'm also hitting the same compiler bug with vanilla GCC 4.7.2 and
> 4.8.0 compiling a heavily patched 3.4 kernel with LTO for a mips64-linux
> target.

Please upload a pre-processed test case.  Since you're getting this with
gcc-4.7.2 it's presumably not caused by r193539 as comment #1 indicated.

Have you tried gcc trunk, just to see if it's been fixed there?

[Bug middle-end/56548] [4.8 Regression] ICE in emit_move_insn, at expr.c:3486 with -march=pentium{pro,2,3} -O3

[ralf@linux-mips.org]

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

--- Comment #10 from Ralf Baechle <ralf@linux-mips.org> ---
As I'm hitting this with LTO on a large test case it's non-trivial to extract a
test case but I will try.