It seems that gcc 4.x.x for OS/2 causes functions to be declared using extern "C" semantics when they have __attribute__((__cdecl__)) attached to them. E.g. for this declaration in C++ context
void __attribute__((__cdecl__)) foo (void **v);
the resulting assembler name (signature) will be _foo instead of __Z3fooPPv (which is the case if _cdecl gets removed). This is not the case with gcc 3.x.x for OS/2 or with gcc 4.x.x on other platforms (e.g. OS X) and looks like a regression of my change that made functions declared as _System in C++ context imply extern "C" (for compatibility with IBM VAC).
Frankly saying there are not many places where it breaks things, but one known case is VirtualBox. The RTCALL calling convention there is defined as __cdecl on OS/2 which causes all functions declared with RTCALL (and with RTDECL which implicitly uses it) to get C signatures instead of C++ ones. For some functions defined in C++ context this brings obvious problems, e.g. for overloaded operators that have the same name by definition (like operator+) but different sets of arguments. This eventually results in several functions with the same signature and the following compiler error:
It seems that gcc 4.x.x for OS/2 causes functions to be declared using
extern "C"
semantics when they have__attribute__((__cdecl__))
attached to them. E.g. for this declaration in C++ contextthe resulting assembler name (signature) will be
_foo
instead of__Z3fooPPv
(which is the case if_cdecl
gets removed). This is not the case with gcc 3.x.x for OS/2 or with gcc 4.x.x on other platforms (e.g. OS X) and looks like a regression of my change that made functions declared as_System
in C++ context implyextern "C"
(for compatibility with IBM VAC).Frankly saying there are not many places where it breaks things, but one known case is VirtualBox. The RTCALL calling convention there is defined as
__cdecl
on OS/2 which causes all functions declared with RTCALL (and with RTDECL which implicitly uses it) to get C signatures instead of C++ ones. For some functions defined in C++ context this brings obvious problems, e.g. for overloaded operators that have the same name by definition (likeoperator+
) but different sets of arguments. This eventually results in several functions with the same signature and the following compiler error: