https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100178
Bug ID: 100178
Summary: Should the “short” be promoted to “int” when use
inline asm？
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gengqi at linux dot alibaba.com
Target Milestone: ---
When use inline asm:
short MAX16_s(short *a, short *b)
{
short __result;
__asm__(
"maxw %0, %1, %2"
: "=r"(__result)
: "r"(*a), "r"(*b)
);
return __result;
}
It's expected to generate 'lh'(sign extend), but 'lhu' (zero extend) actually.
The same situation with the use of explicit conversions would not make this
mess.
Like this:
short MAX16_s(short *a, short *b)
{
short __result;
__asm__(
"maxw %0, %1, %2"
: "=r"(__result)
: "r"((int)*a), "r"((int)*b)
);
return __result;
}
I think the latter implementation is exact, while the first one is ambiguous
that it shouldn't be expected to generate 'lh'.
But my friends think the first one should be treat as well, and it does seem to
make some sense.
I have also read the reference manuals
（https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html），
but can find no basis for this.
Should this be treated as a bug? Or may be we should describe this situation
clearly in the documentation.
