Date: Wed, 17 Apr 2024 22:02:26 +0000 From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 278417] The _cvtsh_ss() intrinsic function generates illegal instructions Message-ID: <bug-278417-29464-g7lLXuQgPS@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-278417-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-278417-29464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278417 --- Comment #4 from Dimitry Andric <dim@FreeBSD.org> --- (In reply to Yuri Victorovich from comment #2) > But this should be covered by the CPUTYPE setting. That seems to be unimplemented at this point. The llvm getHostCPUFeatures() function has support for detecting the feature from CPUID bits, but it looks like that is only used for e.g. -march=3Dnative. I don't maintain share/mk/bsd.cpu.mk, but it seems logical to have some sup= port added there? > clang should know that this CPU doesn't support such instructions and sho= uld emit a generic replacement. There is a note in f16cintrin.h about this: /* NOTE: Intel documents the 128-bit versions of these as being in emmintri= n.h, * but that's because icc can emulate these without f16c using a library ca= ll. * Since we don't do that let's leave these in f16cintrin.h. */ so apparently it is not implemented. I guess you simply have to avoid relyi= ng on these intrinsics if your CPU does not support them. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-278417-29464-g7lLXuQgPS>