When I compile this simple code: void myfoo(void(__cdecl*)()){} void myfoo(void(__stdcall*)()){} int main(){} I get the following error: Assembler messages: Error: symbol `__Z5myfooPFvvE' is already defined Why the compiler treats theese two specificators as the same? Another example code work as expected: template<typename T, typename U> struct is_same { enum { value = 0 }; }; template<typename T> struct is_same<T, T> { enum { value = 1 }; }; int main() { typedef void(__stdcall* stdcall_func_ptr)(); typedef void(__cdecl* cdecl_func_ptr)(); return is_same<stdcall_func_ptr, cdecl_func_ptr>::value; } main returns 0
used i686-w64-mingw32
FWIW, this is not specific to 4.7 and goes back to at least 4.4.
Related to PR c++/2316. Those attributes are properly supported in C but not with fancy C++ features. I don't think they have a mangling, for instance.
This is most likely a duplicate of already fixed PR/55268.
(In reply to comment #4) > This is most likely a duplicate of already fixed PR/55268. I checked upon the 193725 revision. The first test gives the same result. The second test now gives the wrong result(1). Before this the result of the second test was right.
(In reply to comment #5) > (In reply to comment #4) > > This is most likely a duplicate of already fixed PR/55268. > > I checked upon the 193725 revision. > The first test gives the same result. The second test now gives the wrong > result(1). Before this the result of the second test was right. Well, the first test fails due the calling-convention isn't part of the signature in C++. For C you will get for this code simply a double-definition. Issue here is that we don't get an error for g++ as it detects that a types are different for both myfoo functions. The second case checks something different. That it now returns 1 is correct due types are different due different calling-convention used. So remaining testcase is the first one.
it is actual not a target issue. it is more a general c++ issue as calling-convention (call-abi attributes) aren't part of signature.
So it works everywhere? ;)
(In reply to comment #8) > So it works everywhere? ;) Well, it doesn't work for all targets providing different calling-conventions for functions. Eg functions with regparm, stdcall, etc That the sample is architecture specific, doesn't make it there for target specific, isn't it? ;)
I don't know, I'm still finding the "Known to work" field pretty weird, to be honest.
heh, oh duhh :}
This bug got partially fixed for x86 (32-bit) by PR/44282. For x64 we have the issue that there is made no difference between different calling-conventions, as all variants are treated as standard fastcall-convention under the hood.