[Bug c++/53398] New: feature request: option for overloaded methods order in vtable compatibility with msc

[Bug c++/53398] New: feature request: option for overloaded methods order in vtable compatibility with msc

[sweetrommie at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53398

             Bug #: 53398
           Summary: feature request: option for overloaded methods order
                    in vtable compatibility with msc
    Classification: Unclassified
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: sweetrommie@gmail.com


The target of this topic is about mingw and ms compiler incompatibility.

GCC places overloaded virtual functions in order they appear in class
declaration.
In opposite msc reverts them.

Assuming we have a dll compiled in msc and such header for using the dll:

class A {
 virutal void overl(void) = 0;
 virutal void fun1(void) = 0;
 virutal void overl(int i) = 0;
 virutal void overl(double d) = 0;
 virutal void fun2(void) = 0;
 virutal void overl(char *c) = 0;
};

to use it with mingw compiler we need to change it to

class A {
 virutal void overl(char *c) = 0;
 virutal void fun1(void) = 0;
 virutal void overl(double d) = 0;
 virutal void overl(int i) = 0;
 virutal void fun2(void) = 0;
 virutal void overl(void) = 0;
};

or to portable version, which removes overloading (behave gcc ordering)

class A {
 virutal void overlC(char *c) = 0;
 virutal void fun1(void) = 0;
 virutal void overlD(double d) = 0;
 virutal void overlI(int i) = 0;
 virutal void fun2(void) = 0;
 virutal void overlV(void) = 0;
};

It would be nice to have some option to just say the compiler to use different
order.
We could have an option added to a compiler like -fvisibility-ms-compat or
-fabi-version=n.
Or maybe better by something like pragma pack push, so we can do:

#pragma vtorder(push, reverted)
#include "dll_header.h"
#pragma vtorder(pop)

[Bug c++/53398] feature request: option for overloaded methods order in vtable compatibility with msc

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53398

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-05-20 19:14:09 UTC ---
This is defined by the ABI.  I think if we provide an option for this, we are
going to have people abuse this.

Also I think the C++ ABIs between MS and GCC not compatible at all since they
use different mangling.  MS does not follow the cross target/compiler ABI (IA64
C++ ABI).

[Bug c++/53398] feature request: option for overloaded methods order in vtable compatibility with msc

[sweetrommie at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53398

--- Comment #2 from Roman Wieczorek <sweetrommie at gmail dot com> 2012-05-21 10:18:35 UTC ---
(In reply to comment #1)
> I think if we provide an option for this, we are
> going to have people abuse this.

The risk i see here is about compatibility of gcc compiled libraries with other
object files. 
That's why i suggest changing vtable order only for a block of code, or for
single class, like "__attribute__ ((__packed__)))" does.

> Also I think the C++ ABIs between MS and GCC not compatible at all since they
> use different mangling.

Dynamic libraries (for windows) which follow COM spec, uses only pure virtual
class. They do not export class them in the dll, but provides an ansi C
function for creating an object.
In such cases the only exported objects are C functions.
It also avoids C++ name mangling problems.

As it goes for dll i met, it works. Probably because COM was well documented.
The only problem I found, is the order of overloaded functions. COM does not
allow overloading.
Here the method i showed helps and library becomes compatible.

> MS does not follow the cross target/compiler ABI (IA64
> C++ ABI).
The docs shows it is in section 2.5.3.1
http://sourcery.mentor.com/public/cxx-abi/abi.html#vtable
It is similar in COM spec (chapter 3)
http://www.daimi.au.dk/~datpete/COT/COM_SPEC/pdf/com_spec.pdf
No idea why msc behaves overloaded functions different.

[Bug c++/53398] feature request: option for overloaded methods order in vtable compatibility with msc

[sweetrommie at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53398

--- Comment #3 from Roman Wieczorek <sweetrommie at gmail dot com> 2012-05-23 08:11:43 UTC ---
Just to clarify, the exact way msc places methods in vtable is: 
Grouping the overloaded methods.
Placing them in reverted order in starting where first of those overload group
occur.

So the gcc header for the example i showed is:

class A {
 virutal void overl(char *c) = 0;
 virutal void overl(double d) = 0;
 virutal void overl(int i) = 0;
 virutal void overl(void) = 0;
 virutal void fun1(void) = 0;
 virutal void fun2(void) = 0;
};

And the independent one:

class A {
 virutal void overlC(char *c) = 0;
 virutal void overlD(double d) = 0;
 virutal void overlI(int i) = 0;
 virutal void overlV(void) = 0;
 virutal void fun1(void) = 0;
 virutal void fun2(void) = 0;
};

[Bug c++/53398] feature request: option for overloaded methods order in vtable compatibility with msc

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53398

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ktietz at gcc dot gnu.org

--- Comment #4 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-05-25 13:14:57 UTC ---
Is there any good specification about that vtable (and vbtable) layout of msc? 
I assume there might be more things needed to be adjusted so that here
binary-compatibility can be achieved.

[Bug c++/53398] feature request: option for overloaded methods order in vtable compatibility with msc

[sweetrommie at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53398

--- Comment #5 from Roman Wieczorek <sweetrommie at gmail dot com> 2012-05-28 15:50:30 UTC ---
As it goes for Leaf classes (IA64 C++ ABI - Category 1: Leaf),
vtables are binary defined in com document (only virtual functions, no
constructor, no destructor, no overloades). 
And this one works with mingw.

The overloads are not defined, or i have not found it.
Some one has made disasembly:
http://old.nabble.com/Incorrect-vtable-generation-in-MinGW--td15781052.html
I found it works for some people, and i see it works for dll's i use.

I hadn't mention about compatibility for Category 3(Virtual Bases Only ) or
Category 4 (Complex).
They are to far from any specs.