[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

  Component|middle-end  |target

--- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org ---
The bug is in the backend, gen_reg_rtx shouldn't be called when init_emit has
not been called.

If one looks e.g. at tree-ssa-loop-ivopts.c or even
ix86_vectorize_vec_perm_const_ok, it avoids using gen_reg_rtx and instead uses
gen_raw_REG:
  d.target = gen_raw_REG (d.vmode, LAST_VIRTUAL_REGISTER + 1);
  d.op1 = d.op0 = gen_raw_REG (d.vmode, LAST_VIRTUAL_REGISTER + 2);
  if (!d.one_operand_p)
d.op1 = gen_raw_REG (d.vmode, LAST_VIRTUAL_REGISTER + 3);
So, we should avoid calling gen_reg_rtx if d-testing_p, we can create
gen_raw_REG instead if really needed.  Let me skim through the routines.

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org ---
So, from quick skim of relevant routines that do gen_reg_rtx, I see:

gen_reg_rtx called only after if (d-testing_p) return true;, thus ok:
expand_vec_perm_blend
expand_vec_perm_pshufb
expand_vec_perm_palignr
expand_vec_perm_vpermq_perm_1
expand_vec_perm_vperm2f128
expand_vec_perm_vperm2f128_vblend
expand_vec_perm_2vperm2f128_vshuf
expand_vec_perm_vpshufb2_vpermq
expand_vec_perm_vpshufb2_vpermq_even_odd
expand_vec_perm_vpshufb4_vpermq2

Does not look at testing_p at all, not ok:
expand_vec_perm_pshufb2
expand_vec_perm_even_odd_1

Not ok:
expand_vec_perm_interleave2
expand_vec_perm_broadcast_1

So, I think we want to fix those 4 routines.

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

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

--- Comment #21 from Uroš Bizjak ubizjak at gmail dot com ---
--cut here--
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 207935)
+++ config/i386/i386.c  (working copy)
@@ -40666,9 +40666,9 @@ ix86_vectorize_vec_perm_const_ok (enum machine_mod
   if (!d.one_operand_p)
 d.op1 = gen_raw_REG (d.vmode, LAST_VIRTUAL_REGISTER + 3);

-  start_sequence ();
+  init_dummy_function_start ();
   ret = ix86_expand_vec_perm_const_1 (d);
-  end_sequence ();
+  expand_dummy_function_end ();

   return ret;
 }
--cut here--

Jakub, what do you think about this patch?

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Uroš Bizjak from comment #21)
 --- config/i386/i386.c  (revision 207935)
 +++ config/i386/i386.c  (working copy)
 @@ -40666,9 +40666,9 @@ ix86_vectorize_vec_perm_const_ok (enum machine_mod
if (!d.one_operand_p)
  d.op1 = gen_raw_REG (d.vmode, LAST_VIRTUAL_REGISTER + 3);
  
 -  start_sequence ();
 +  init_dummy_function_start ();
ret = ix86_expand_vec_perm_const_1 (d);
 -  end_sequence ();
 +  expand_dummy_function_end ();
  
return ret;
  }
 --cut here--
 
 Jakub, what do you think about this patch?

IMHO that is way too expensive.

So, say expand_vec_perm_interleave2 is only called with d-testing_p from
ix86_vectorize_vec_perm_const_ok, and thus I'd say something like:
  if (!d-testing_p)
{
  dremap.target = gen_reg_rtx (dremap.vmode);
  dfinal.op0 = gen_lowpart (dfinal.vmode, dremap.target);
}
  dfinal.op1 = dfinal.op0;
should fix expand_vec_perm_interleave2.  I think dfinal.op0 should have
dfinal.vmode already from the caller (we can easily perhaps gcc_checking_assert
double check it when testing the patch).

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

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

--- Comment #23 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Jakub Jelinek from comment #22)

 IMHO that is way too expensive.

Agreed.

Anyway, it looks you got this problem under control ;)

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[mpolacek at gcc dot gnu.org]

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

Marek Polacek mpolacek at gcc dot gnu.org changed:

   What|Removed |Added

  Component|c   |target

--- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org ---
Not a C FE issue.

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Vittorio Zecca from comment #6)

 As an aside, in gcc 4.8.1 source code, before line 6995 of gcc/expr.c I put
  
 printf(\nexpr.c:6995 value-code=%d NUM_RTX_CODE=%d\n,(int)
 value-code,NUM_RTX_CODE);
 gcc_assert((int) value-code  NUM_RTX_CODE);
 
 and I get an ICE there because value-code is 34816 and NUM_RTX_CODE is 145
 
 Indeed at line 6995 ARITHMETIC_P (value) accesses rtx_class[(int)
 value-code]
 but the array rtx_class has only NUM_RTX_CODE elements.
 However, I do not know how this is relevant to this issue.

This one points to infrastructure problem.

Adding a debug patch:

--cut here--
Index: explow.c
===
--- explow.c(revision 207910)
+++ explow.c(working copy)
@@ -186,8 +186,13 @@ plus_constant (enum machine_mode mode, rtx x, HOST
 }

   if (c != 0)
-x = gen_rtx_PLUS (mode, x, GEN_INT (c));
+{
+  rtx z = GEN_INT (c);
+  printf (cc, %li\n, c);
+  debug_rtx (z);

+  x = gen_rtx_PLUS (mode, x, z);
+}
   if (GET_CODE (x) == SYMBOL_REF || GET_CODE (x) == LABEL_REF)
 return x;
   else if (all_constant)
--cut here--

~/gcc-build-48/gcc/cc1 pr57896.c

...
 __get_cpuidcc, -4
(const_int -4 [0xfffc])
cc, -16
(const_int -16 [0xfff0])
cc, -24
(const_int -24 [0xffe8])
cc, -32
(const_int -32 [0xffe0])
cc, -40
(??? bad code 47104
)

pr57896.c: In function ‘__get_cpuid’:
pr57896.c:5:5: internal compiler error: in emit_move_insn_1, at expr.c:3437
 int __get_cpuid (unsigned int __level, unsigned int *__eax, unsigned int
*__ebx, unsigned int *__ecx, unsigned int *__edx) {
 ^
0x62d74d emit_move_insn_1(rtx_def*, rtx_def*)
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/expr.c:3437
0x62d7b5 emit_move_insn(rtx_def*, rtx_def*)
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/expr.c:3535

Please note that the debug patch only encloses GEN_INT (...)

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Vittorio Zecca from comment #5)

 Adding option -m32 I get ICE in ix86_expand_prologue, at
 config/i386/i386.c:10559

I can confirm this with:

gcc version 4.8.3 20140219 (prerelease) [gcc-4_8-branch revision 207910] (GCC)

~/gcc-build-48/gcc/cc1 -m32 -march=x86-64 pr57896.c

pr57896.c: In function ‘__get_cpuid_max’:
pr57896.c:4:1: internal compiler error: in ix86_expand_prologue, at
config/i386/i386.c:10539
 }
 ^
0x98fdf5 ix86_expand_prologue()
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.c:10539
0xa1ce5a gen_prologue()
   
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.md:11829
0x673927 thread_prologue_and_epilogue_insns
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:5949
0x673927 rest_of_handle_thread_prologue_and_epilogue
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:6973

The output from the debug patch doesn't look suspicious, so this looks like a
real bug to me. Can someone please bisect which commit fixed/hid this bug?

[Bug target/57896] [4.8 Regression] ICE in expand_expr_real_2

[ubizjak at gmail dot com]

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

--- Comment #11 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Uroš Bizjak from comment #10)
 (In reply to Vittorio Zecca from comment #5)
 
  Adding option -m32 I get ICE in ix86_expand_prologue, at
  config/i386/i386.c:10559
 
 I can confirm this with:
 
 gcc version 4.8.3 20140219 (prerelease) [gcc-4_8-branch revision 207910]
 (GCC)
 
 ~/gcc-build-48/gcc/cc1 -m32 -march=x86-64 pr57896.c

This is the same problem, as confirmed by following debug patch:

--cut here--
Index: i386.c
===
--- i386.c  (revision 207912)
+++ i386.c  (working copy)
@@ -10449,8 +10449,12 @@ ix86_expand_prologue (void)
   else if (!ix86_target_stack_probe ()
   || frame.stack_pointer_offset  CHECK_STACK_LIMIT)
 {
+  rtx x = GEN_INT (-allocate);
+
+  printf (\nTestP1 %li\n, -allocate);
+  debug_rtx (x);
   pro_epilogue_adjust_stack (stack_pointer_rtx, stack_pointer_rtx,
-GEN_INT (-allocate), -1,
+x, -1,
 m-fs.cfa_reg == stack_pointer_rtx);
 }
   else
@@ -10536,6 +10540,7 @@ ix86_expand_prologue (void)
  gen_frame_mem (word_mode, t));
}
 }
+  printf (\nTestP2 %li %li\n, m-fs.sp_offset, frame.stack_pointer_offset);
   gcc_assert (m-fs.sp_offset == frame.stack_pointer_offset);

   /* If we havn't already set up the frame pointer, do so now.  */
--cut here--

GEN_INT (...) produces some non-sensical RTX, and INTVAL at the end of
pro_epilogue_adjust_stack chokes on it.

  m-fs.sp_offset = ooffset - INTVAL (offset);
  m-fs.sp_valid = valid;

~/gcc-build-48/gcc/cc1 -m32 -march=x86-64 pr57896.c

...

TestP1 -56
(??? bad code 42752
)

TestP2 -139787679344504 64

pr57896.c: In function ‘__get_cpuid_max’:
pr57896.c:4:1: internal compiler error: in ix86_expand_prologue, at
config/i386/i386.c:10544
 }
 ^
0x98fe35 ix86_expand_prologue()
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.c:10544
0xa1ce9a gen_prologue()
   
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/config/i386/i386.md:11829
0x673927 thread_prologue_and_epilogue_insns
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:5949
0x673927 rest_of_handle_thread_prologue_and_epilogue
/home/uros/gcc-svn/branches/gcc-4_8-branch/gcc/function.c:6973