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));
}

Reply via email to