[type_traits] VC++ and vararg function/mmeber functions and varargs
After going back and for with Mr. Lavavej from Microsoft about how VC++ treats functions/member functions which have varargs parameters and calling conventions, I learned that VC++ always treats all these function types as if the calling convention is __cdecl, no matter what the end-user specifies. Therefore attempting to match function and member function types taking varargs, with VC++ and compatibles, by having to specify __cdecl, __fastcall, and __stdcall calling conventions for every function/member function declaration with varargs, is a waste since these are not potential new types being tested by templates but just the same type redeclared. These occur in type_traits/detail files is_mem_fun_pointer_tester.hpp and is_mem_fun_pointer_tester.hpp when BOOST_TT_TEST_MS_FUNC_SIGS ( essentially _MSC_EXTENSIONS) is defined. I would like to remove these redundant declarations from these files. I have made sure that my tests for VC++ pass. I will test Intel C++, if it also emulates VC++ in this way. Can I make the change on trunk to these files once I ascertain that Intel C++ tests with type_traits also pass with this change ? Are there any other VC++ emulation compilers that need to be tested ?
On 10/7/2013 6:50 PM, Edward Diener wrote:
After going back and for with Mr. Lavavej from Microsoft about how VC++ treats functions/member functions which have varargs parameters and calling conventions, I learned that VC++ always treats all these function types as if the calling convention is __cdecl, no matter what the end-user specifies.
Therefore attempting to match function and member function types taking varargs, with VC++ and compatibles, by having to specify __cdecl, __fastcall, and __stdcall calling conventions for every function/member function declaration with varargs, is a waste since these are not potential new types being tested by templates but just the same type redeclared. These occur in type_traits/detail files is_mem_fun_pointer_tester.hpp and is_mem_fun_pointer_tester.hpp
Correction. This should be "is_function_ptr_tester.hpp and is_mem_fun_pointer_tester.hpp".
when BOOST_TT_TEST_MS_FUNC_SIGS ( essentially _MSC_EXTENSIONS) is defined.
I would like to remove these redundant declarations from these files. I have made sure that my tests for VC++ pass. I will test Intel C++, if it also emulates VC++ in this way.
Can I make the change on trunk to these files once I ascertain that Intel C++ tests with type_traits also pass with this change ? Are there any other VC++ emulation compilers that need to be tested ?
Can I make the change on trunk to these files once I ascertain that Intel C++ tests with type_traits also pass with this change ? Are there any other VC++ emulation compilers that need to be tested ?
Yes please do go on ahead, thanks, John.
On 10/8/2013 3:22 AM, John Maddock wrote:
Can I make the change on trunk to these files once I ascertain that Intel C++ tests with type_traits also pass with this change ? Are there any other VC++ emulation compilers that need to be tested ?
Yes please do go on ahead, thanks, John.
I have checked this in to trunk. I will be watching the regression tests to make sure it is not breaking anything. Unfortunately Boost does not have a regression tester for Intel C++ for Windows and I suspect that the VC++ emulation with Intel only occurs for that product. I also don't own Intel C++ for Windows so there was no way of testing that my changes did not break anything in that compiler. If I hear from anyone that the changes affected that product I will fix the files I changed for Intel C++ when _MSC_EXTENSIONS is defined. I know that all versions of VC++ I tested ( 8, 9, 10, 11 ) worked properly with the changes.
Unfortunately Boost does not have a regression tester for Intel C++ for Windows and I suspect that the VC++ emulation with Intel only occurs for that product. I also don't own Intel C++ for Windows so there was no way of testing that my changes did not break anything in that compiler. If I hear from anyone that the changes affected that product I will fix the files I changed for Intel C++ when _MSC_EXTENSIONS is defined.
Intel-14.0 tests pass for me OK here. Thanks for this! John.
On 10/10/2013 5:31 AM, John Maddock wrote:
Unfortunately Boost does not have a regression tester for Intel C++ for Windows and I suspect that the VC++ emulation with Intel only occurs for that product. I also don't own Intel C++ for Windows so there was no way of testing that my changes did not break anything in that compiler. If I hear from anyone that the changes affected that product I will fix the files I changed for Intel C++ when _MSC_EXTENSIONS is defined.
Intel-14.0 tests pass for me OK here.
Thanks fot testing this out. I was able to get Intel for Linux free on a developer's license but not Intel for Windows.
Thanks for this! John.
You're very welcome.
On 8.10.2013. 0:50, Edward Diener wrote: <snip> ...somewhat related/FWIW: MSVC12 has added another calling convention __vectorcall so you can plan on supporting/handling that too... ps. "unfortunately&hopefully" they'll eventually introduce yet another convention to finally solve the MS x64 ABI embarrassment (https://connect.microsoft.com/VisualStudio/feedback/details/804577/msvc-impl...)... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
On 10/8/2013 6:25 AM, Domagoj Saric wrote:
On 8.10.2013. 0:50, Edward Diener wrote: <snip>
...somewhat related/FWIW: MSVC12 has added another calling convention __vectorcall so you can plan on supporting/handling that too...
Thanks for the information. It does look like __vectorcall should not be applied to member functions or varargs functions. I will look at how Boost config currently supports the VS2013 RC to see how these should be added.
On 10/9/2013 1:29 PM, Stephan T. Lavavej wrote:
[Edward Diener]
It does look like __vectorcall should not be applied to member functions or varargs functions.
__vectorcall can be applied to member functions.
http://msdn.microsoft.com/en-us/library/vstudio/dn375768%28v=vs.120%29.aspx "Using the /Gv compiler option causes each function in the module to compile as __vectorcall unless the function is a member function, is declared with a conflicting calling convention attribute, uses a vararg variable argument list, or has the name main."
[STL]
__vectorcall can be applied to member functions.
[Edward Diener]
http://msdn.microsoft.com/en-us/library/vstudio/dn375768%28v=vs.120%29.aspx "Using the /Gv compiler option causes each function in the module to compile as __vectorcall unless the function is a member function, is declared with a conflicting calling convention attribute, uses a vararg variable argument list, or has the name main."
That's different. What I said is that __vectorcall can be applied to member functions, i.e. directly. What MSDN is saying is that /Gv changes the default calling convention to __vectorcall for non-member functions, but doesn't affect member functions. As a library author, the behavior of the calling convention switches doesn't really matter. What a library needs to do is provide overloads/specializations for all possible calling conventions, whether they've been directly specified or are coming from a default. What the switches do force library authors to do is to explicitly mark *all* overloads/specializations - you can't leave one unmarked and then specify __stdcall/__fastcall/etc. for the others, because that'll result in duplicates under Gr/Gz/etc. (Except for varargs, which are completely immune to everything.) STL
On 10/9/2013 3:51 PM, Stephan T. Lavavej wrote:
[STL]
__vectorcall can be applied to member functions.
[Edward Diener]
http://msdn.microsoft.com/en-us/library/vstudio/dn375768%28v=vs.120%29.aspx "Using the /Gv compiler option causes each function in the module to compile as __vectorcall unless the function is a member function, is declared with a conflicting calling convention attribute, uses a vararg variable argument list, or has the name main."
That's different.
What I said is that __vectorcall can be applied to member functions, i.e. directly. What MSDN is saying is that /Gv changes the default calling convention to __vectorcall for non-member functions, but doesn't affect member functions.
OK. It does seem odd that __vectorcall can be applied to member functions but your compiler option for __vectorcall does not apply to member functions. Thanks for the clarification.
participants (4)
-
Domagoj Saric -
Edward Diener -
John Maddock -
Stephan T. Lavavej