[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file

[rguenth at gcc dot gnu.org]

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.