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 1953A384F6E8; Fri, 18 Nov 2022 10:10:59 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1953A384F6E8
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1668766259;
	bh=cg9qlzNSgPcxCdkuUBTciEl1oxt52DOPM+Jm+H3ySNs=;
	h=From:To:Subject:Date:From;
	b=kv4U4eW+0ROtrvU8wytHd+FpvxckiG5NKhX45xuvzJuPrD19f+0VeGWwPGsjtuK0x
	 G5UdUQRxBf+xbH6BR4/ZqjGHDiWLcD2Sm9JIvjTPnGkSjTMUPtcahh2xq5anA5aTY2
	 Pq/GVKIo3534WA1/PDdaNgwXfuz/j1EgJJ5uT9iY=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/107748] New: [13 Regression] Isn't _mm_cvtsbh_ss
 incorrect?
Date: Fri, 18 Nov 2022 10:10:58 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
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-107748-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
List-Id: <gcc-bugs.sourceware.org>

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

            Bug ID: 107748
           Summary: [13 Regression] Isn't _mm_cvtsbh_ss incorrect?
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

The implementation:

/* Convert One BF16 Data to One Single Float Data.  */
extern __inline float
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
_mm_cvtsbh_ss (__bf16 __A)
{
  union{ float a; unsigned int b;} __tmp;
  __tmp.b =3D ((unsigned int)(__A)) << 16;
  return __tmp.a;
}

except for the __bfloat16 -> __bf16 change used to be correct in GCC 12,
if one can ignore sNaN (and I presume the builtin is ok with that), then wh=
en
__A argument was actually unsigned or signed short, the above did the right
thing.
But now it certainly doesn't, because it converts the floating point BFmode
__A to integer, then shifts the integer 16 bits up and then VIEW_CONVERT_EX=
PRs
it into float.  So, instead of -ffinite-math-only BF -> SF conversion it
actually
does BF -> SF -> USI conversions, then multiplies by 65536 and then VCE to =
SF.
So, either it can just do return __A; but that will emit a library call unl=
ess
-ffinite-math-only/-ffast-math, or it could be e.g.
  unsigned short int __b;
  unsigned int __c;
  float __ret;
  __builtin_memcpy (&__b, &__A, sizeof (__b));
  __c =3D __b << 16;
  __builtin_memcpy (&__ret, &__c, sizeof (__ret));
  return __ret;
Note, the a and b identifiers in the union look bad as well, a and b aren't
reserved identifiers...=