[Bug rtl-optimization/61060] New: [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter

[Bug rtl-optimization/61060] New: [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter

[zsojka at seznam dot cz]

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

            Bug ID: 61060
           Summary: [4.9/4.10 Regression] ICE: in int_mode_for_mode, at
                    stor-layout.c:400 with -free-ter
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz

Created attachment 32733
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32733&action=edit
reduced testcase

Compiler output:
$ gcc -ftree-ter testcase.c 
testcase.c: In function 'foo':
testcase.c:6:3: internal compiler error: in int_mode_for_mode, at
stor-layout.c:400
   return __builtin_memset (dest, ch, len);
   ^
0xb2e513 int_mode_for_mode(machine_mode)
        /mnt/svn/gcc-trunk/gcc/stor-layout.c:400
0x84759e emit_move_via_integer
        /mnt/svn/gcc-trunk/gcc/expr.c:3198
0x85579c emit_move_insn_1(rtx_def*, rtx_def*)
        /mnt/svn/gcc-trunk/gcc/expr.c:3578
0x855b68 emit_move_insn(rtx_def*, rtx_def*)
        /mnt/svn/gcc-trunk/gcc/expr.c:3645
0x836ebc copy_to_mode_reg(machine_mode, rtx_def*)
        /mnt/svn/gcc-trunk/gcc/explow.c:656
0xe10960 ix86_expand_set_or_movmem(rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*, bool)
        /mnt/svn/gcc-trunk/gcc/config/i386/i386.c:24182
0xedd82e gen_setmemsi(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*, rtx_def*, rtx_def*)
        /mnt/svn/gcc-trunk/gcc/config/i386/i386.md:15539
0xa35452 insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*) const
        /mnt/svn/gcc-trunk/gcc/recog.h:291
0xa35452 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
        /mnt/svn/gcc-trunk/gcc/optabs.c:8322
0xa35a88 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
        /mnt/svn/gcc-trunk/gcc/optabs.c:8334
0x849eee set_storage_via_setmem(rtx_def*, rtx_def*, rtx_def*, unsigned int,
unsigned int, long, unsigned long, unsigned long, unsigned long)
        /mnt/svn/gcc-trunk/gcc/expr.c:3007
0x717197 expand_builtin_memset_args
        /mnt/svn/gcc-trunk/gcc/builtins.c:3731
0x7306c0 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
        /mnt/svn/gcc-trunk/gcc/builtins.c:6173
0x84f64d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        /mnt/svn/gcc-trunk/gcc/expr.c:10340
0x85eb17 store_expr(tree_node*, rtx_def*, int, bool)
        /mnt/svn/gcc-trunk/gcc/expr.c:5328
0x865f5e expand_assignment(tree_node*, tree_node*, bool)
        /mnt/svn/gcc-trunk/gcc/expr.c:5114
0x7573f6 expand_call_stmt
        /mnt/svn/gcc-trunk/gcc/cfgexpand.c:2273
0x7573f6 expand_gimple_stmt_1
        /mnt/svn/gcc-trunk/gcc/cfgexpand.c:3170
0x7573f6 expand_gimple_stmt
        /mnt/svn/gcc-trunk/gcc/cfgexpand.c:3322
0x758a37 expand_gimple_basic_block
        /mnt/svn/gcc-trunk/gcc/cfgexpand.c:5162
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.

$ gcc -v                    
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-210047-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-210047-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.10.0 20140504 (experimental) (GCC) 

Tested revisions:

Tested revisions:
r210047 - ICE
4.9 r209651 - ICE
4.8 r209342 - OK
4.7 r209345 - OK
4.6 r197894 - OK

[Bug target/61060] [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
          Component|rtl-optimization            |target
   Target Milestone|---                         |4.9.1

[Bug target/61060] [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

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

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
Confirmed, modeless (const_int 0) leaks to line 24181.

(gdb) f 7
#7  0x0000000000c4fc71 in ix86_expand_set_or_movmem (dst=0x7ffff19c5d50,
src=0x10048e0 <int_mode_for_mode(machine_mode)::__FUNCTION__>, src@entry=0x0,
count_exp=0x7ffff18a5470, val_exp=0x190, 
    val_exp@entry=0x7ffff18a5510, align_exp=0x64,
align_exp@entry=0x7ffff18a5480, expected_align_exp=0x7ff9fffff00,
expected_align_exp@entry=0x7ffff18a5480, expected_size_exp=0x7ffff18a5460, 
    min_size_exp=0x0, max_size_exp=0x190, max_size_exp@entry=0x7ffff18a5510,
probable_max_size_exp=0x10048e0
<int_mode_for_mode(machine_mode)::__FUNCTION__>,
probable_max_size_exp@entry=0x0, 
    issetmem=true) at /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:24182
24182       count_exp = copy_to_mode_reg (GET_MODE (count_exp), count_exp);
(gdb) p debug_rtx (count_exp)
(const_int 0 [0])
$9 = void
(gdb) list
24177        creating of promoted vector value is very cheap in this case.  */
24178     if (issetmem && alg == vector_loop && val_exp != const0_rtx)
24179       alg = unrolled_loop;
24180
24181     if (!count)
24182       count_exp = copy_to_mode_reg (GET_MODE (count_exp), count_exp);
24183     destreg = ix86_copy_addr_to_reg (XEXP (dst, 0));
24184     if (!issetmem)
24185       srcreg = ix86_copy_addr_to_reg (XEXP (src, 0));
24186
>From gcc-bugs-return-450607-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 05 18:18:34 2014
Return-Path: <gcc-bugs-return-450607-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20388 invoked by alias); 5 May 2014 18:18:34 -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 20366 invoked by uid 48); 5 May 2014 18:18:31 -0000
From: "gjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/61055] [avr] wrong test instruction after increment with -O1
Date: Mon, 05 May 2014 18:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: gjl at gcc dot gnu.org
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:
Message-ID: <bug-61055-4-oEKXoN4H7q@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61055-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61055-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/msg00299.txt.bz2
Content-length: 405

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

--- Comment #1 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
I see similar code with -fno-peephole2

What about the following that is also turned into a signed test and generates
an ADIW / BRGE sequence.  This is also wrong then when we start with 0x7ffe?

uint16_t fun_adiw (uint16_t c)
{
  c += 2;
  if (c >= 0x8000)
    c = 0x20;

  return c;
}

[Bug target/61060] [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at ucw dot cz

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
The code in ix86_expand_set_or_movmem assumes that !count implies non-const_int
count_exp:

  unsigned HOST_WIDE_INT count = 0;

...

  if (CONST_INT_P (count_exp))
    min_size = max_size = probable_max_size = count = expected_size
      = INTVAL (count_exp);
...

  if (!count)
    count_exp = copy_to_mode_reg (GET_MODE (count_exp), count_exp);

However, when count_exp is (const_int 0), the assumption breaks, and the code
tries to determine the mode of modeless (const_int 0) count_exp RTX.

CC author of the code.
>From gcc-bugs-return-450612-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 05 19:33:34 2014
Return-Path: <gcc-bugs-return-450612-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7954 invoked by alias); 5 May 2014 19:33:34 -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 7928 invoked by uid 48); 5 May 2014 19:33:30 -0000
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/61058] [4.7/4.8/4.9/4.10 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreachable()
Date: Mon, 05 May 2014 19:33:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords: ice-checking, ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: law at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-61058-4-juUKo8Lofn@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61058-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61058-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/msg00304.txt.bz2
Content-length: 1759

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

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

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

--- Comment #3 from Jeffrey A. Law <law at redhat dot com> ---
What do you need me to confirm?  I can confirm that you're not supposed to have
BARRIERS in the middle of a block.

THe RTL in question:

        .file   "j.c"
        .text
        .globl  foo
        .type   foo, @function
foo:
        pushq   %rbp
(note 1 0 3 NOTE_INSN_DELETED)

(note 3 1 9 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(insn/f 9 3 10 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0  S8 A8])
        (reg/f:DI 6 bp)) j.c:2 65 {*pushdi2_rex64}
     (nil))

(insn/f 10 9 5 2 (set (reg/f:DI 6 bp)
        (reg/f:DI 7 sp)) j.c:2 89 {*movdi_internal}
     (nil))

(barrier 5 10 11)

(note 11 5 2 2 NOTE_INSN_PROLOGUE_END)

(note 2 11 8 2 NOTE_INSN_FUNCTION_BEG)

(note 8 2 0 NOTE_INSN_DELETED)


We're in distance_agu_use_in_bb.  We're passing it insn 10 as INSN and the
BARRIER as START.   We try to look at BLOCK_FOR_INSN (start), after that, we're
well into undefined territory.

But this really looks like x86 backend breakage. Refer to the above RTL and
look at this call site:

17976     if (insn != BB_END (bb))
17977       distance = distance_agu_use_in_bb (regno0, insn, distance,
17978                                          NEXT_INSN (insn),
17979                                          &found, &redefined);

Clearly if NEXT_INSN (insn) is a BARRIER, then nothing good can happen.

[Bug target/61060] [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter

[hubicka at ucw dot cz]

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

--- Comment #3 from Jan Hubicka <hubicka at ucw dot cz> ---
> 
>   if (CONST_INT_P (count_exp))
>     min_size = max_size = probable_max_size = count = expected_size
>       = INTVAL (count_exp);
> ...
> 
>   if (!count)
>     count_exp = copy_to_mode_reg (GET_MODE (count_exp), count_exp);
> 
> However, when count_exp is (const_int 0), the assumption breaks, and the code
> tries to determine the mode of modeless (const_int 0) count_exp RTX.
> 
> CC author of the code.
I would say it is job of middle-end to not expand obviously pointless
stringops...

[Bug target/61060] [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
At -O0?  Well...  it seems the expander doesn't yet see it's zero:

  /* If the LEN parameter is zero, return DEST.  */
  if (integer_zerop (len))
    {
      /* Evaluate and ignore VAL in case it has side-effects.  */
      expand_expr (val, const0_rtx, VOIDmode, EXPAND_NORMAL);
      return expand_expr (dest, target, mode, EXPAND_NORMAL);

that is because len is len_5 at -O0 (no CCP), but it is TERed and thus
len_5 = 0 is expanded in-place.

I'd say the backend should better deal with this.  Or we have to
double-check (or delay) the zero-length check until after

  len_rtx = expand_normal (len);

sth like

Index: gcc/builtins.c
===================================================================
--- gcc/builtins.c      (revision 209890)
+++ gcc/builtins.c      (working copy)
@@ -3685,20 +3685,20 @@ expand_builtin_memset_args (tree dest, t
   if (expected_align < dest_align)
     expected_align = dest_align;

+  /* Stabilize the arguments in case we fail.  */
+  dest = builtin_save_expr (dest);
+  val = builtin_save_expr (val);
+  len = builtin_save_expr (len);
+
+  len_rtx = expand_normal (len);
   /* If the LEN parameter is zero, return DEST.  */
-  if (integer_zerop (len))
+  if (len_rtx == const0_rtx)
     {
       /* Evaluate and ignore VAL in case it has side-effects.  */
       expand_expr (val, const0_rtx, VOIDmode, EXPAND_NORMAL);
       return expand_expr (dest, target, mode, EXPAND_NORMAL);
     }

-  /* Stabilize the arguments in case we fail.  */
-  dest = builtin_save_expr (dest);
-  val = builtin_save_expr (val);
-  len = builtin_save_expr (len);
-
-  len_rtx = expand_normal (len);
   determine_block_size (len, len_rtx, &min_size, &max_size,
                        &probable_max_size);
   dest_mem = get_memory_rtx (dest, len);


probably applies to almost all builtin expansions.

But I'd say the backend should be more fault-tolerant here.  It can't
simply reserve len == 0 for itself.

[Bug target/61060] [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka <hubicka at ucw dot cz> ---
> I'd say the backend should better deal with this.  Or we have to
> double-check (or delay) the zero-length check until after
> 
>   len_rtx = expand_normal (len);
> 
> sth like

This looks good to me indeed. Thanks for explanation concerning TER.
> 
> Index: gcc/builtins.c
> ===================================================================
> --- gcc/builtins.c      (revision 209890)
> +++ gcc/builtins.c      (working copy)
> @@ -3685,20 +3685,20 @@ expand_builtin_memset_args (tree dest, t
>    if (expected_align < dest_align)
>      expected_align = dest_align;
> 
> +  /* Stabilize the arguments in case we fail.  */
> +  dest = builtin_save_expr (dest);
> +  val = builtin_save_expr (val);
> +  len = builtin_save_expr (len);
> +
> +  len_rtx = expand_normal (len);
>    /* If the LEN parameter is zero, return DEST.  */
> -  if (integer_zerop (len))
> +  if (len_rtx == const0_rtx)
>      {
>        /* Evaluate and ignore VAL in case it has side-effects.  */
>        expand_expr (val, const0_rtx, VOIDmode, EXPAND_NORMAL);
>        return expand_expr (dest, target, mode, EXPAND_NORMAL);
>      }
> 
> -  /* Stabilize the arguments in case we fail.  */
> -  dest = builtin_save_expr (dest);
> -  val = builtin_save_expr (val);
> -  len = builtin_save_expr (len);
> -
> -  len_rtx = expand_normal (len);
>    determine_block_size (len, len_rtx, &min_size, &max_size,
>                         &probable_max_size);
>    dest_mem = get_memory_rtx (dest, len);
> 
> 
> probably applies to almost all builtin expansions.
> 
> But I'd say the backend should be more fault-tolerant here.  It can't
> simply reserve len == 0 for itself.

OK, I think I can just add early return to the expander functions then (or an
assert - still it seems more like middle-end's bug as it only wastes time even
at -O0)

Honza

[Bug target/61060] [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter

[jakub at gcc dot gnu.org]

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

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

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

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

I agree the backend should be more tolerant, going to bootstrap/regtest this
later today.

[Bug target/61060] [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Tue May 13 08:28:53 2014
New Revision: 210352

URL: http://gcc.gnu.org/viewcvs?rev=210352&root=gcc&view=rev
Log:
    PR target/61060
    * config/i386/i386.c (ix86_expand_set_or_movmem): If count_exp
    is const0_rtx, return immediately.  Don't test count == 0 when
    it is always true.

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

Added:
    trunk/gcc/testsuite/gcc.dg/pr61060.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/testsuite/ChangeLog

[Bug target/61060] [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Tue May 13 08:31:29 2014
New Revision: 210353

URL: http://gcc.gnu.org/viewcvs?rev=210353&root=gcc&view=rev
Log:
    PR target/61060
    * config/i386/i386.c (ix86_expand_set_or_movmem): If count_exp
    is const0_rtx, return immediately.  Don't test count == 0 when
    it is always true.

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

Added:
    branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr61060.c
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/config/i386/i386.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/61060] [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -free-ter

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
      Known to work|                            |4.10.0, 4.9.1
         Resolution|---                         |FIXED
      Known to fail|4.10.0, 4.9.1               |4.9.0

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed now for 4.9.1+.