https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #48 from Richard Biener <rguenth at gcc dot gnu.org> --- Please provide preprocessed source for jcf-parse.c and instructions on how to configure a cross compiler from x86_64-linux. Please also provide disassembly around the failing place with enough context to spot it in a cc1 generated output - best with an explanation what's wrong. >From what Thomas says in comment #46 it looks like for some unknown reason a HI load from a 1-byte aligned address is emitted: (insn 688 687 689 (set (reg:HI 482) (mem:HI (reg/v/f:SI 189 [ 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)) but as the bswap pass emits a plain MEM_REF with an aligned type we should go through the following path in expand: if (modifier != EXPAND_WRITE && modifier != EXPAND_MEMORY && !inner_reference_p && mode != BLKmode && align < GET_MODE_ALIGNMENT (mode)) { if ((icode = optab_handler (movmisalign_optab, mode)) != CODE_FOR_nothing) { struct expand_operand ops[2]; /* We've already validated the memory, and we're creating a new pseudo destination. The predicates really can't fail, nor can the generator. */ create_output_operand (&ops[0], NULL_RTX, mode); create_fixed_operand (&ops[1], temp); expand_insn (icode, 2, ops); temp = ops[0].value; } else if (SLOW_UNALIGNED_ACCESS (mode, align)) temp = extract_bit_field (temp, GET_MODE_BITSIZE (mode), 0, TYPE_UNSIGNED (TREE_TYPE (exp)), (modifier == EXPAND_STACK_PARM ? NULL_RTX : target), mode, mode); that is, go through extract_bit_field (supposed sparc doesn't have movmisalign and is SLOW_UNALIGNED_ACCESS for HImode and 8-bit align). So we need to figure out why we don't go the above path or why extract_bit_field gets things wrong.