https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91841
Bernard B <b-gccbugzilla at largestprime dot net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |b-gccbugzilla@largestprime. | |net --- Comment #7 from Bernard B <b-gccbugzilla at largestprime dot net> --- The resolution of this bug should be at least WONTFIX, not INVALID, because as the OP reports, this is perfectly valid portable code that works on 64-bit x86 and other non-x86 architectures supported by GCC. I have just encountered this issue myself when supporting an in-house library which heavily uses vector types. It makes compilation of 32-bit x86 code with vector types pretty much unusable. A library author cannot control what users of the library will do after calling the library's functions. It's unreasonable to expect all users to put _mm_empty() in all the right places and only on x86-32. And the current failure mode of silent corruption is the worst. Even if the ABI of __m64 types is unusable as currently specified, could gcc implement a workaround? Either (1) emit the emms instruction (between a callee return with vector type and a subsequent FPU operation or the end of the function); or (2) simply not use the __m64 type for passing 64-bit vector types at all? The latter is an ABI break, but the ABI was broken anyway!