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.
