[Bug target/107748] New: [13 Regression] Isn't _mm_cvtsbh_ss incorrect?

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

            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 = ((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 when
__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_EXPRs
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 unless
-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 = __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...