[Bug c/100178] New: Should the “short” be promoted to “int” when use inline asm？

[Bug c/100178] New: Should the “short” be promoted to “int” when use inline asm？

[gengqi at linux dot alibaba.com]

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.

[Bug c/100178] Should the “short” be promoted to “int” when use inline asm？

[wilson at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100178

Jim Wilson <wilson at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu.org

--- Comment #1 from Jim Wilson <wilson at gcc dot gnu.org> ---
This looks similar to 85185.  Same problem with a short type not working
correctly as an operand to an asm, and RISC-V is not the only target that the
code fails for.  I would suggest avoiding using char/short with an asm until
someone figures out how to fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85185

[Bug inline-asm/100178] Should the “short” be promoted to “int” when use inline asm？

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100178

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |inline-asm
           Keywords|                            |documentation

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>It's expected to generate 'lh'(sign extend), but 'lhu' (zero extend) actually.

I don't see why, the mode used here is HI mode, so the upper 16bits of the
32bit (or 48bits of 64bits) is undefined.  This is just like doing a (subreg:SI
(reg:HI)).

This should be documented instead of changed.  It is useful sometimes not to
need the upper bits to be defined (mostly with bit inserts).

[Bug inline-asm/100178] Should the “short” be promoted to “int” when use inline asm？

[gengqi at linux dot alibaba.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100178

--- Comment #3 from GengQi <gengqi at linux dot alibaba.com> ---
Thanks for your replies, I have taken enough information from them.

I hope this is made clear in the documentation soon.