https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102584
Stafford Horne <shorne at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |shorne at gcc dot gnu.org Last reconfirmed| |2022-02-02 Assignee|unassigned at gcc dot gnu.org |shorne at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #2 from Stafford Horne <shorne at gcc dot gnu.org> --- I confirm this looks strange. It seems to be due to not handling some case for HImode in or1k_expand_move, see below. Is this causing any actual issue? As I see it the result is that the registers will be loaded with fffff123 instead of 0000f123, but if using HImode only the lower 16-bits will be used. I confirmed with some simple tests. void or1k_expand_move (machine_mode mode, rtx op0, rtx op1) { if (MEM_P (op0)) { if (!const0_operand (op1, mode)) op1 = force_reg (mode, op1); } else if (mode == QImode || mode == HImode) { /* ??? Maybe promote MEMs and CONST_INT to SImode, and then squish back with gen_lowpart. */ } else { ... } // NOTE at this point op0 and op1 are, checked using print_rtl() // (reg:HI 3 r3) // (const_int -3805 [0xfffffffffffff123]) emit_insn (gen_rtx_SET (op0, op1)); }