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!
