https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #61 from Eric Botcazou <ebotcazou 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. Right, every load must be aligned. > ;; 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? No, it's undefined behavior at run time only. > 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. Yes, and that's what the original implementation actually did, see: https://gcc.gnu.org/ml/gcc-patches/2014-01/msg00717.html > 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? I think that it needs to be applied on both mainline and 4.9 branch then.