On Sep 6, 2012, at 5:47 PM, Aaron Ballman wrote: > MSDN documents that the __stdcall calling convention will be silently > ignored if it is used when compiling for x64 > (http://msdn.microsoft.com/en-us/library/zxk0tw93(v=vs.110).aspx). > This patch will mimic that behavior in clang as well by treating the > calling convention as C when generating code as well as when mangling > the convention. This is important for Win64 support because the Win32 > APIs are all prefixed with __stdcall, even when compiling for x64. > Currently, we cannot link against the Win64 APIs because of this > problem. > > The approach I am taking is a cautious one, so it only targets x64 in > Microsoft mode for __stdcall. However, I think it may make sense to > have a more generalized approach to handling calling conventions > because I suspect there will be other cases we wish to do this for > more than just MSVC compatibility. We cannot simply drop or modify > the attribute on the function because then we would be unable to > perform rewrites from the AST, and we don't want to foist the problem > off on the backend either. Thoughts are welcome as to a reasonable > approach -- I wasn't able to find a satisfactory way to express the > notion of a written calling convention that doesn't match what we > actually wish to emit. > > Thanks!
How ignored is it, exactly? Is it still checked syntactically? for redundancy? in the type system at all? Basically, I'm asking if we can #define it. :) John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
