From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 03D67395BC3B; Wed, 21 Apr 2021 11:48:01 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 03D67395BC3B
From: "gengqi at linux dot alibaba.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: =?UTF-8?B?W0J1ZyBjLzEwMDE3OF0gTmV3OiBTaG91bGQgdGhlIOKAnHNob3J0?=
 =?UTF-8?B?4oCdIGJlIHByb21vdGVkIHRvIOKAnGludOKAnSB3aGVuIHVzZSBpbmxpbmUg?=
 =?UTF-8?B?YXNt77yf?=
Date: Wed, 21 Apr 2021 11:48:00 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 11.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: gengqi at linux dot alibaba.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-100178-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Apr 2021 11:48:01 -0000

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

            Bug ID: 100178
           Summary: Should the =E2=80=9Cshort=E2=80=9D be promoted to =E2=
=80=9Cint=E2=80=9D when use
                    inline asm=EF=BC=9F
           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"
      : "=3Dr"(__result)
      : "r"(*a), "r"(*b)
  );
  return __result;
}

It's expected to generate 'lh'(sign extend), but 'lhu' (zero extend) actual=
ly.

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"
      : "=3Dr"(__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 see=
m to
make some sense.

I have also read the reference manuals
=EF=BC=88https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html=EF=BC=89=EF=
=BC=8C
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.=