http://llvm.org/bugs/show_bug.cgi?id=5990
Matti Niemenmaa <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #5 from Matti Niemenmaa <[email protected]> 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. _______________________________________________ LLVMbugs mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
