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...
