https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115115
--- Comment #5 from Sergei Trofimovich <slyfox at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #2) > So from a point of view of float to int conversion, both are valid for out > of range values. Looking at CVTTPS2DQ instruction from https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html "Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4": """ Description ... When a conversion is inexact, a truncated (round toward zero) value is returned. If a converted result is larger than the maximum signed doubleword integer, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value (80000000H) is returned. """ It feels like 2^63 is an exact value and no truncation should happen. Thus 0x80000000 seems to be the correct value. Why 0x7fffffff would be a reasonable outcome as well? Is it because `_mm_cvttps_epi32()` semantics are not a 1-to-1 to CVTTPS2DQ instruction? Trying to understand the detail as I'm not yet sure if I should file a `highway` bug to be compatible with gcc's expectations. The exact test is at https://github.com/google/highway/blob/b7cff55896e36e6080909d35ef6fb3d0986b4cfa/hwy/tests/convert_test.cc#L1202
