rsmith added a comment.
The test failure in test/CodeGen/microsoft-call-conv-x64.c definitely indicates
a problem. The code has defined behavior, but the IR you say we now produce has
undefined behavior due to a type mismatch between the call and the callee.
It looks to me like unprototyped `__stdcall` lowering is broken (prior to your
change). Consider:
void __stdcall g(int n) {}
void __stdcall (*p)() = g;
void f() { p(0); }
The types of `p` and `g` are compatible (`g`'s parameter type list does not end
in an ellipsis and its parameter type `int` is a promoted type, so it is
compatible with an unprototyped function), so the above program is valid, and a
call to `f` has defined behavior.
And yet we lower the definition of `g` to `define void @g(i32 %n) ` and the
call to
%0 = load void (...)*, void (...)** @p, align 8
%callee.knr.cast = bitcast void (...)* %0 to void (i64)*
call void %callee.knr.cast(i64 0)
... resulting in undefined behavior.
https://reviews.llvm.org/D28166
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
