--- Comment #3 from Sagar Patel <sapatel at redhat dot com> ---
The root issue is that the immediate values carried by instructions only
support 32-bit integers, and the compiler performs some problematic fixups.
When strings are rolled into their byte representations, a generic value struct
is used. This struct holds an int64_t immediate value which represents the
string and is used as the src1 register in the insn struct. However, the insn
struct only supports 32-bit integers in its src1 registers.
There is a check in fixup_operands that checks for these mismatches:
s1->imm() != (int32_t) s1->imm()
Normally, the first bit of a character would just be 0, since ASCII only goes
upto 127. Consequently, when strings with plain ASCII characters get converted
to an immediate value, the most significant bit is not set and no fixups are
done because the above check is satisfied.
However, for UTF-8 characters, the most significant bit may be set causing the
compiler to perform some fixups. In the fixups, an intermediate register is
used to store and load and the string bytes. The original insn that was
generated for the strings uses the 0x62 opcode: stw [dst+off], imm. But, since
we have an intermediate register holding the data, we need to use the 0x63
opcode instead: stxw [dst+off], src.
The changing of the opcode from 0x62 to 0x63 was missing, and with that change,
it seems that all UTF-8 characters can be printed.
You are receiving this mail because:
You are the assignee for the bug.