[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c

[ramana at gcc dot gnu.org]

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

--- Comment #2 from Ramana Radhakrishnan  2011-05-06 
11:09:45 UTC ---
(In reply to comment #1)
> Looking at this in a gdb session . 

I should say this was on trunk.

Ramana

[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.06 11:08:38
 Ever Confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  2011-05-06 
11:08:38 UTC ---
Looking at this in a gdb session . 

 0x08296944 in expand_expr_addr_expr_1 (exp=0xb7b9cd20, target=, tmode=, modifier=EXPAND_NORMAL, as=0 '\000') at
/home/ramrad01/sources/fsf/trunk/gcc/expr.c:6917

  result = expand_expr (exp, target, tmode,
modifier == EXPAND_INITIALIZER
? EXPAND_INITIALIZER : EXPAND_CONST_ADDRESS);

  /* If the DECL isn't in memory, then the DECL wasn't properly
 marked TREE_ADDRESSABLE, which will be either a front-end
 or a tree optimizer bug.  */
  gcc_assert (MEM_P (result));
  result = XEXP (result, 0);

(gdb) p result
$3 = (rtx) 0xb7b9d588

(gdb) pr
(concat:SC (reg/v:SF 134 [ s ])
(reg/v:SF 135 [ s+4 ]))



That shouldn't result in a concat expression. 

Ramana

[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c

[michael.hope at linaro dot org]

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

Michael Hope  changed:

   What|Removed |Added

 CC||michael.hope at linaro dot
   ||org

--- Comment #3 from Michael Hope  2011-05-17 
22:05:00 UTC ---
I see the same thing in trunk and 4.6.0.  4.5.2 is fine.

michaelh@ursa1:~$
/scratch/michaelh/toolchains/gcc-4.6.0-armv7l-maverick-cbuild102-ursa1-cortexa9r1/bin/gcc
-O2 pr48335-2.c 
pr48335-2.c: In function 'f1':
pr48335-2.c:19:30: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:6918
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

michaelh@ursa1:~$
/scratch/michaelh/toolchains/gcc-4.6+svn173722-armv7l-maverick-cbuild114-ursa4-cortexa9r1/bin/gcc
-O2 pr48335-2.c 
pr48335-2.c: In function 'f1':
pr48335-2.c:19:30: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:6949
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

michaelh@ursa1:~$
/tools/toolchains/gcc-4.5.2-armv7l-maverick-cbuild93-ursa1-cortexa8r1/bin/gcc
-O2 -c pr48335-2.c

See also:
 http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg01661.html

[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se,
   ||rguenth at gcc dot gnu.org

--- Comment #4 from Mikael Pettersson  2011-06-21 
09:04:00 UTC ---
It's triggered by the big MEM-REF merge in r161655:

Author: rguenth
Date: Thu Jul  1 08:49:19 2010
New Revision: 161655

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161655
Log:
2010-07-01  Richard Guenther  

PR middle-end/42834
PR middle-end/44468
* doc/gimple.texi (is_gimple_mem_ref_addr): Document.
* doc/generic.texi (References to storage): Document MEM_REF.
* tree-pretty-print.c (dump_generic_node): Handle MEM_REF.
...

[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-06-21 
10:45:20 UTC ---
Of course it was.  The branch merge allows s to be allocated in registers
so we expand from

  MEM[(T * {ref-all})&s + 1B] = x_2(D);

and we run into the movmisalign_optab code in expand_assignment which
is supported for DImode with the commandline args.  But we probably
shouldn't try the movmisalign path when the destination is a CONCAT.

So something like the following might work (fixes the testcase, otehrwise
completely untested)

Index: expr.c
===
--- expr.c  (revision 175138)
+++ expr.c  (working copy)
@@ -4122,6 +4122,12 @@ expand_assignment (tree to, tree from, b
   rtx result;
   enum machine_mode mode;
   int align, icode;
+  enum machine_mode mode1;
+  HOST_WIDE_INT bitsize, bitpos;
+  tree offset;
+  int unsignedp;
+  int volatilep = 0;
+  tree tem;

   /* Don't crash if the lhs of the assignment was erroneous.  */
   if (TREE_CODE (to) == ERROR_MARK)
@@ -4134,9 +4140,18 @@ expand_assignment (tree to, tree from, b
   if (operand_equal_p (to, from, 0))
 return;

+  tem = get_inner_reference (to, &bitsize, &bitpos, &offset, &mode1,
+&unsignedp, &volatilep, true);
+
+  /* If we are going to use store_bit_field and extract_bit_field,
+ make sure to_rtx will be safe for multiple use.  */
+
+  to_rtx = expand_normal (tem);
+
   mode = TYPE_MODE (TREE_TYPE (to));
-  if ((TREE_CODE (to) == MEM_REF
-   || TREE_CODE (to) == TARGET_MEM_REF)
+  if (MEM_P (to_rtx)
+  && (TREE_CODE (to) == MEM_REF
+ || TREE_CODE (to) == TARGET_MEM_REF)
   && mode != BLKmode
   && ((align = MAX (TYPE_ALIGN (TREE_TYPE (to)),
get_object_alignment (to, BIGGEST_ALIGNMENT)))
@@ -4150,39 +4165,7 @@ expand_assignment (tree to, tree from, b
   reg = expand_expr (from, NULL_RTX, VOIDmode, EXPAND_NORMAL);
   reg = force_not_mem (reg);

-  if (TREE_CODE (to) == MEM_REF)
-   {
- addr_space_t as
- = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (to, 1;
- tree base = TREE_OPERAND (to, 0);
- address_mode = targetm.addr_space.address_mode (as);
- op0 = expand_expr (base, NULL_RTX, VOIDmode, EXPAND_NORMAL);
- op0 = convert_memory_address_addr_space (address_mode, op0, as);
- if (!integer_zerop (TREE_OPERAND (to, 1)))
-   {
- rtx off
- = immed_double_int_const (mem_ref_offset (to), address_mode);
- op0 = simplify_gen_binary (PLUS, address_mode, op0, off);
-   }
- op0 = memory_address_addr_space (mode, op0, as);
- mem = gen_rtx_MEM (mode, op0);
- set_mem_attributes (mem, to, 0);
- set_mem_addr_space (mem, as);
-   }
-  else if (TREE_CODE (to) == TARGET_MEM_REF)
-   {
- addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (to));
- struct mem_address addr;
-
- get_address_description (to, &addr);
- op0 = addr_for_mem_ref (&addr, as, true);
- op0 = memory_address_addr_space (mode, op0, as);
- mem = gen_rtx_MEM (mode, op0);
- set_mem_attributes (mem, to, 0);
- set_mem_addr_space (mem, as);
-   }
-  else
-   gcc_unreachable ();
+  mem = to_rtx;
   if (TREE_THIS_VOLATILE (to))
MEM_VOLATILE_P (mem) = 1;

@@ -4211,21 +4194,7 @@ expand_assignment (tree to, tree from, b
  && TREE_CODE (TREE_OPERAND (to, 0)) == ADDR_EXPR)
   || TREE_CODE (TREE_TYPE (to)) == ARRAY_TYPE)
 {
-  enum machine_mode mode1;
-  HOST_WIDE_INT bitsize, bitpos;
-  tree offset;
-  int unsignedp;
-  int volatilep = 0;
-  tree tem;
-
   push_temp_slots ();
-  tem = get_inner_reference (to, &bitsize, &bitpos, &offset, &mode1,
-&unsignedp, &volatilep, true);
-
-  /* If we are going to use store_bit_field and extract_bit_field,
-make sure to_rtx will be safe for multiple use.  */
-
-  to_rtx = expand_normal (tem);

   /* If the bitfield is volatile, we want to access it in the
 field's mode, not the computed mode.

[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c

[mikpe at it dot uu.se]

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

--- Comment #6 from Mikael Pettersson  2011-06-21 
11:24:39 UTC ---
I can do a bootstrap and regtest with Richard's patch in #c5 tomorrow, but as
my HW is armv5te I can't catch any neon-related runtime regressions.  Does
anyone else want to do the bootstrap+regtest on more modern HW?

[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  
2011-06-21 11:40:18 UTC ---
On Tue, 21 Jun 2011, mikpe at it dot uu.se wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48493
> 
> --- Comment #6 from Mikael Pettersson  2011-06-21 
> 11:24:39 UTC ---
> I can do a bootstrap and regtest with Richard's patch in #c5 tomorrow, but as
> my HW is armv5te I can't catch any neon-related runtime regressions.  Does
> anyone else want to do the bootstrap+regtest on more modern HW?

The patch probably breaks the movmisalign path

[Bug middle-end/48493] [ICE] [ARM] in expand_expr_addr_expr_1, at expr.c

[mikpe at it dot uu.se]

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

--- Comment #8 from Mikael Pettersson  2011-06-24 
09:59:58 UTC ---
I've now bootstrapped and regtested the patch in #c5 on top of gcc-4.6-20110610
on an armv5tel-linux-gnueabi machine.  (I couldn't get it to apply to trunk.) 
There were no build problems, it solved the test case, but there were a few
testsuite regressions:

+FAIL: gcc.dg/vect/nodump-pr23073.c (internal compiler error)
+FAIL: gcc.dg/vect/nodump-pr23073.c (test for excess errors)

/mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/nodump-pr23073.c: In
function 'C':
/mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/nodump-pr23073.c:19:1:
error: unrecognizable insn:
(insn 7 6 8 3 (set (mem/s/c:BLK (reg/f:SI 134) [3 d+0 S16 A32])
(unspec:V2SI [
(reg:V2SI 135)
] 205))
/mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/nodump-pr23073.c:16 -1
 (nil))
/mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/nodump-pr23073.c:19:1:
internal compiler error: in extract_insn, at recog.c:2109

+FAIL: gcc.dg/vect/vect-34.c (internal compiler error)
+FAIL: gcc.dg/vect/vect-34.c (test for excess errors)

/mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/vect-34.c: In function
'main1':
/mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/vect-34.c:31:1: error:
unrecognizable insn:
(insn 41 40 42 3 (set (mem/s/c:BLK (reg/f:SI 173) [3 s+0 S16 A32])
(unspec:V8QI [
(reg:V8QI 175)
] 205))
/mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/vect-34.c:20 -1
 (nil))
/mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/vect-34.c:31:1:
internal compiler error: in extract_insn, at recog.c:2109

+FAIL: gcc.dg/vect/bb-slp-10.c (internal compiler error)
+FAIL: gcc.dg/vect/bb-slp-10.c (test for excess errors)

/mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/bb-slp-10.c: In
function 'main1':
/mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/bb-slp-10.c:41:1:
error: unrecognizable insn:
(insn 24 23 25 3 (set (mem/s/c:BLK (reg/f:SI 168) [2 out+0 S64 A64])
(unspec:V2SI [
(reg:V2SI 174)
] 205))
/mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/bb-slp-10.c:28 -1
 (nil))
/mnt/scratch/gcc-4.6-20110610/gcc/testsuite/gcc.dg/vect/bb-slp-10.c:41:1:
internal compiler error: in extract_insn, at recog.c:2109

+FAIL: gcc.target/arm/frame-pointer-1.c execution test

The runtime test in foo() fails because p4 is 0xdeadbeef rather than 4.