[LLVMbugs] [Bug 5990] [x86, x86-64] MMX vectors trample on FP stack, breaking 80-bit floats

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.org/bugs/show_bug.cgi?id=5990


Matti Niemenmaa <matti.niemenmaa+llvmbugs at iki.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |




--- Comment #5 from Matti Niemenmaa <matti.niemenmaa+llvmbugs at iki.fi>  2010-01-11 13:27:08 ---
The compiler producing code using such vectors is my own. Does it have to be a
bug in llvm-gcc or clang to be a valid LLVM bug?!

It seems a reasonable expectation to me that if I emit such LLVM code I
shouldn't have to worry about the details of how it's codegenned. For some
operations, the <2 x i32> will be split into two separate operations on i32, in
which case the EMMS won't be needed. Putting such platform-specific logic into
my compiler really doesn't seem like the "right" thing to do here. I don't mind
if you leave this open with the admission that it probably won't be looked at,
but I honestly don't think INVALID is at all appropriate.

If you insist on C, here's something which makes clang behave the same way
(without optimizations). Judging from the codegen at http://www.llvm.org/demo/,
llvm-gcc does the same. Remove the line initializing 'vec b' to print 1.000000
instead of -nan:

#include <stdio.h>
typedef int vec __attribute__ ((vector_size (8)));
int main() {
        vec a;
        vec b = a + a;
        printf("%Lf\n", 1.0L);
}

GCC appears to refuse to emit MMX instructions, explaining why it doesn't break
the above code.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.