https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |ASSIGNED --- Comment #60 from Richard Biener <rguenth at gcc dot gnu.org> --- Ok, I suppose lduh [%g3], %g4 ! MEM[base: ptr_110, offset: 0B], min_line is not an instruction that works with unaligned %g3. ;; min_line_106 = (int) _215; (insn 921 920 922 (set (reg:HI 482) (mem:HI (reg/v/f:SI 185 [ ptr ]) [0 MEM[base: ptr_110, offset: 0B]+0 S2 A8])) /vol/gcc/src/hg/trunk/local/gcc/java/jcf-parse.c:1622 -1 (nil)) a (mem:HI ...) with A8. I wonder if we should ICE somewhere if such kind of MEM is in the RTL instruction stream on a STRICT_ALIGNMENT platform? The TARGET_MEM_REF is created via #0 create_mem_ref_raw (type=type@entry=0x7ffff5401000, alias_ptr_type=alias_ptr_type@entry=<pointer_type 0x7ffff61e3c78>, addr=addr@entry=0x7fffffffd560, verify=verify@entry=true) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-address.c:401 #1 0x0000000000c3b464 in create_mem_ref (gsi=gsi@entry=0x7fffffffd600, type=<integer_type 0x7ffff5401000 short unsigned int>, addr=addr@entry=0x7fffffffd640, alias_ptr_type=<pointer_type 0x7ffff61e3c78>, iv_cand=iv_cand@entry=<ssa_name 0x7ffff66cc948>, base_hint=base_hint@entry=<ssa_name 0x7ffff66cc948>, speed=speed@entry=true) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-address.c:721 #2 0x0000000000c96f9a in rewrite_use_address (use=use@entry=0x18b8a10, cand=cand@entry=0x1a26f50, data=<optimized out>, data=<optimized out>) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6471 #3 0x0000000000c97513 in rewrite_use (cand=0x1a26f50, use=0x18b8a10, data=0x7fffffffd9c0) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6539 #4 rewrite_uses (data=data@entry=0x7fffffffd9c0) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6568 #5 0x0000000000c9cb35 in tree_ssa_iv_optimize_loop (loop=<optimized out>, data=0x7fffffffd9c0) at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6894 #6 tree_ssa_iv_optimize () at /space/rguenther/tramp3d/trunk/gcc/tree-ssa-loop-ivopts.c:6926 Ah, so the issue is that may_be_unaligned does 1706 unsigned int align = TYPE_ALIGN (TREE_TYPE (ref)); 1707 1708 unsigned HOST_WIDE_INT bitpos; 1709 unsigned int ref_align; 1710 get_object_alignment_1 (ref, &ref_align, &bitpos); 1711 if (ref_align < align 1712 || (bitpos % align) != 0 1713 || (bitpos % BITS_PER_UNIT) != 0) 1714 return true; thus it queries TYPE_ALIGN (TREE_TYPE (ref)) which is 8 - and _not_ mode alignment which is what matters on STRICT_ALIGNMENT targets. Fix: Index: gcc/tree-ssa-loop-ivopts.c =================================================================== --- gcc/tree-ssa-loop-ivopts.c (revision 213050) +++ gcc/tree-ssa-loop-ivopts.c (working copy) @@ -1704,6 +1704,8 @@ may_be_unaligned_p (tree ref, tree step) return false; unsigned int align = TYPE_ALIGN (TREE_TYPE (ref)); + if (GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))) > align) + align = GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))); unsigned HOST_WIDE_INT bitpos; unsigned int ref_align; can you test and apply that patch? Thx. With that patch I get ldub [%g3+1], %g2 ! MEM[(unsigned char *)ptr_110], MEM[(unsigned char *)ptr_110] ldub [%g3], %g1 ! MEM[(unsigned char *)ptr_110], MEM[(unsigned char *)ptr_110] sll %g1, 8, %g1 ! MEM[(unsigned char *)ptr_110],, tmp462 or %g2, %g1, %g1 ! MEM[(unsigned char *)ptr_110], tmp462, min_line